Learn

👨‍🏫 Context Mapping for Better Collaboration

Story Time: From My Deep Context to Their Confusion

I remember a time when I was deep in the trenches, responsible for driving the remediation of compliance and security gaps across hundreds of repositories spanning several different products.

I was extremely familiar with the nuances of these gaps from a technical perspective and a compliance control perspective.

I was living, breathing, and dreaming of those nuances. My closest collaborators, the ones working alongside me day in and day out, were in the same boat. Our context was crystal clear.

But…this wasn’t the case for everyone who needed to be involved.

When we scaled this work beyond our core group and began pulling in hundreds of other engineers, that consistent context simply wasn't shared across everyone. (surprised, surprise!)

The request we made to these teams for remediation was, on the surface, trivial. It would probably take a single engineer a couple of hours, a single pull request, and boom! the compliance gap would be closed.

However, despite our best efforts to communicate context clearly, there were challenges. What we saw was a huge variety of engagement, directly correlating with how much context the repository owner had on the problem.

On one end, our infrastructure engineering teams ran with it immediately, often closing gaps quickly because their context already aligned closely with the problem's criticality.

On the other, some marketing analytics teams needed a truly "white glove" approach, requiring us to walk them through the context step-by-step, patiently explaining the "why" and guiding them through the "how."

This is a context gap.

A context gap is a major risk to program or project momentum. As Technical Program Managers, we are accountable for driving momentum towards outcomes, which means we must be keenly aware of these gaps and how they impact our work.

The Context Gap: It's Not What You Think

The context gap isn't about intelligence or dedication. It's simply a function of different roles and responsibilities.

While you're knee-deep in the problem, your engineering leads might be focused on architectural decisions, your product managers on market fit, and your stakeholders on business outcomes. They have their own critical contexts, which means they won't always have the same granular understanding of the problem domain that you do.

Ignoring this gap leads to problems. So many problems. But it is a good thing you are a skilled Technical Program Manager that can help bridge the context gap!

Bridging the Gap: Your Superpower

This is where context mapping becomes your superpower.

In fact, I believe this is one of the major value propositions of the TPM role! There are not many roles that are juggling so many different contexts and can paint the full picture of the context for everyone to understand.

Context mapping is the conscious effort to understand how much context each of your collaborators has on the problem domain and then adapting your collaboration style accordingly. It's about meeting people where they are, not expecting them to instantly absorb your entire understanding.

Visualizing the Context Gap: Your Concentric Circles

To truly grasp this, think of context as a concentric circle map, with you, the TPM, at the very center. In that innermost circle is your deep, nuanced understanding of the problem domain. You have the context.

Around you are layers of collaborators, each residing in rings with varying degrees of shared context regarding your specific problem:

• Your Core Team (Inner Ring): These are your closest collaborators! Your immediate engineering leads, key architects, or the few individuals that are living and breathing the nuances of a problem like security gaps alongside you. Their context level is high, often mirroring yours.

• Wider Engineering Teams (Mid Ring): This layer includes teams like the infrastructure engineers from our story. They possess a solid technical foundation and may quickly grasp technical requests, but they might not have the same daily immersion in your specific problem's strategic importance or intricate history. They need clear "what" and "why," but less hand-holding.

• Cross-Functional Partners & Broader Stakeholders (Outer Rings): This extends to teams like the marketing analytics group, product managers, legal teams, or executives. Their primary context lies in their own distinct domains, making your problem more tangential to their immediate priorities. They require explicit context-setting, simplified explanations, and a clear articulation of impact, often needing that "white glove" approach.

Your role as a TPM is to appreciate and navigate these concentric circles.

Recognizing where each person or team sits on this map instantly informs how you should communicate, what level of detail to provide, and what expectations you should set. It's about bridging the distances between these circles, rather than assuming everyone lives in your central sphere of understanding.

Context Mapping in Practice

1. Assess the Current Context Level

Before any significant interaction, take a moment to consider:

• Empathize with their domain: Take a moment to truly appreciate the distinct world your collaborators operate in. What are their priorities? What metrics are they accountable for? How do they measure success? Understanding their constant context helps you frame your information in a way that resonates with their immediate concerns and challenges, fostering greater empathy and more productive interactions.

• Evaluate Context Exposure: Have they been involved since day one, or are they just getting looped in? This will change your approach in a pretty drastic way. For many scaled efforts, context is lacking for most of teams initially.

• Consider Their Seniority: Are you communicating with a junior IC engineer? Or the Chief Product Officer? These roles have very different spheres of influence and focus. Understanding this can help you tailor your approach for the best collaboration style.

For example, when discussing a critical technical dependency with an executive, they likely need the "what" and the "why it matters," not necessarily the intricate "how" of the implementation. Conversely, a new engineer on the team will need a much deeper dive into the technical nuances.

2. Tailor Your Communication

Once you've assessed the current context, adjust your communication style:

• Be explicit, not implicit: What's obvious to you may be completely new to someone else. Don't assume shared understanding. Clearly state the problem, the proposed solution, and the impact.

• Vary your level of detail: Provide just enough information to enable understanding and decision-making for that specific audience. For those with less context, start with the high-level overview and gradually add details as needed. For those with more, you can dive straight into the specifics.

• Pre-wire and follow up: For crucial discussions, consider pre-reading materials or quick syncs to bring people up to speed before the main meeting. After a discussion, summarize key decisions and action items, reinforcing the shared understanding.

3. Adjust Your Expectations and Appreciate Their World

This is perhaps the most crucial part of context mapping. When you understand someone's context level, you can set realistic expectations for their contributions and their speed of understanding:

• Anticipate questions: If someone has limited context, they're likely to have more questions. Welcome them as opportunities to clarify and reinforce understanding.

• Don't mistake lack of context for lack of engagement: Just because someone doesn't immediately grasp the nuances doesn't mean they aren't invested. They simply need you to help them build that understanding.

• Tailor the Approach: Finally, determine how high-touch your collaboration needs to be with this team to support them receiving and grasping the full context. Ultimately, you want to empower them to be self-sufficient with all the necessary context but what it means to deliver that looks different based on all the previous steps.

A Word of Caution: Not a One-Time Fix

It's vital to remember that context mapping isn't a "one-and-done" activity. Organizations are dynamic ecosystems. Strategies shift, team structures evolve, and people constantly come and go.

The context you painstakingly build today might be outdated next week. Treat context mapping as an ongoing practice (a regular check-in with your collaborators' understanding) to ensure you maintain momentum and mitigate future context gaps.

The Payoff: Tight Collaboration

You want to keep your program locked in? Always consider the context gaps.

By actively mapping context and adjusting your approach, you'll find that collaboration becomes smoother, decisions are made more efficiently, and your programs move forward with less friction.

It's a fundamental shift in how you lead and interact to become a High Impact Technical Program Manager.

Happy TPM’ing!

Resources

🎧️ The TPM Ridge Podcast

Doron Katz has been leading the charge in creating a top-notch podcast for TPM’s, by TPM’s. Doron, Josh Teter, Michael Götz, and myself are co-hosting to provide a panel-style podcast experience with frequent guests in the industry.

• The latest episode was with David Rifkind to dive into The State of TPMs.

• In June, we had a season launch episode where we shared our path’s to becoming TPM’s and thoughts on AI as TPM’s.