Thank you for the enthusiastic engagement with the second edition. Within the first 24 hours, 60% of you opened it, and a handful of you emailed back to share how well it resonated. I’m grateful for your continued support. Let’s get into today’s topic.
Imagine this: you pick up a project that is genuinely impactful. You understand the complexity involved in designing, implementing, deploying, and making sure it works in production.
But later, when you describe it in a performance review, promotion packet, resume, or behavioral interview, it somehow sounds small or ordinary.
It sounds like a task you completed rather than a meaningful contribution.
This happened to me many times in my career. I did complex, important work, but when I tried to explain it, it seemed to lose its weight. Over time, that made it harder for me to value my own contributions and feel ready for higher-leverage opportunities.
It kept me stuck for longer than I needed to be.
In the first edition, we looked at how missing context keeps strong engineers stuck. In the second, we explored how seniority is not just harder work, but higher-stakes decision-making with broader consequences.
Together, they point to today’s idea:
Work is what you did.
Context is why it mattered.
Value is what others can understand, trust, and act on.
In practice, the perceived value of your work is often shaped by this equation:
Value = Work × Context
Without context, strong work can look like ordinary execution.
With context, the same work can reveal judgment, risk reduction, leverage, leadership, and seniority.
Why the same work can mean different things
Let’s take a simple example.
A low-context version of a project might sound like this:
“I built an API to track notifications sent by our new service.”
That may be excellent work involving thoughtful design, careful implementation, testing, production hardening, and coordination with other engineers.
But from the outside, it still sounds like an API.
Now compare that with a higher-context version:
“I built an API that allowed product teams to track notifications using the company’s standard analytics table. This removed an adoption blocker for a new notifications platform, reduced cross-team duplication, lowered migration risk, and created a golden path for future product integrations.”
The work is the same in both versions, but the meaning is not.
The first version describes the facts. The second version helps people understand why the API mattered, who could use it, what risk it reduced, and what it made possible.
This is what context does.
Context gives meaning to facts.
It can completely change how your work is understood.
This is also why, when you provide no context, the perceived value of your work can approach zero.
So the key question becomes: how do you build context around your work?
The two types of context
It’s useful to differentiate between factual context and strategic context.
Factual context explains what happened: who was involved, what was built, when it happened, where it ran, and what constraints or dependencies shaped the work. It gives people the basic shape of the work.
But the deeper value often comes from strategic context.
Strategic context explains why the work mattered. It includes scale, stakes, risk, urgency, tradeoffs, and the cost of inaction.
- What problem made this work necessary?
- Why did it matter now?
- What risk did it reduce?
- What future work did it unlock?
- What decision, launch, migration, adoption path, or business outcome depended on it?
- What would have happened if nobody solved it?
This is where work begins to signal judgment.
Three ways to uncover strategic context
There are many ways to build strategic context, but three lenses are especially useful.
1. Ask why five times, also known as the 5 Whys
When you inherit a task or project, the first explanation is often not the full context.
“We need to build this API.”
Why?
“Because product teams need it.”
Why do they need it?
“Because they cannot track the notifications our service sends on their behalf.”
Why does that matter?
“Because without tracking, they do not trust the service enough to adopt it.”
Why do we need them to adopt the service?
“Because the legacy service cannot reliably handle the volume of emails we need to send.”
Why does that volume matter?
“Because emails bring customers back to the product, and that activity drives revenue.”
Now the work is no longer ‘just an API.’ It is connected to adoption, trust, migration, reliability, customer engagement, and revenue.
The 5 Whys help you move from “what needs to be built?” to “what important problem does this work solve?”
2. Ask why this was challenging
Many engineers describe difficulty through technical details alone: the system was complex, the migration was hard, the architecture had edge cases, or the codebase was old. That may all be true.
But Senior+ work often becomes valuable because of the constraints around the technical work.
In the tracking API example, implementing the API was not the hard part. The new API had to create enough confidence for product teams to adopt the new service, and migration required careful support as teams moved away from their legacy integrations.
Asking why the work was challenging helps separate ordinary effort from meaningful complexity.
3. Ask about the cost of inaction
This is often the least used question: What would have happened if this work had not been done?
- Would operational burden or risk have continued?
- Would teams have kept duplicating effort?
- Would a launch, migration, or business opportunity have been delayed?
The cost of inaction reveals stakes. It helps you see why the work was worth doing, not just how it was done.
When you combine these three lenses, strategic context starts to emerge. You can see the work not only as a technical artifact, but as part of a larger system of decisions, risks, people, and outcomes.
Strategic context and the execution trap
This is also how context helps you break out of the execution trap we introduced in the second edition.
When you focus only on deep technical work and gnarly problem-solving, it is easy to develop tunnel vision. You can stay busy, useful, and technically impressive while still failing to move the needle on what matters.
That’s why understanding context is more than a communication skill. It is a career growth skill.
The Staff+ shift most engineers miss
Many engineers think about context only when they need to explain their work later: in a performance review, promotion packet, resume, or interview.
That is useful, but incomplete.
At Senior+ levels, context is part of the work itself. It helps you make better decisions before you commit to an execution path.
A mid-level engineer may be expected to execute within a context someone else has clarified.
A Senior engineer is increasingly expected to understand and communicate that context.
A Staff engineer is expected to uncover missing context and use it to shape direction.
A Principal engineer may need to help the organization see context it has been missing entirely.
This is the deeper shift:
Context is more than a communication tool.
It is a judgment tool.
Context helps you see where the real value is created: which decisions matter, which risks deserve attention, and what success should actually mean.
Without it, you may stay downstream from the decisions that determine value. With it, you are closer to the field of play.
Why strong engineers often miss context
If context matters so much, why do so many strong engineers miss it?
1. Execution feels more validating than inquiry
Technical execution gives engineers something concrete to do. It feels useful, measurable, and familiar. We looked at this mindset blocker in depth in the second edition.
2. They inherit the problem statement too quickly
I once worked with a Senior engineer who came into a coaching session with a long list of technical tasks. His Staff engineer had told him those things needed to be done, and he was feeling overwhelmed.
When I asked why the tasks mattered, he realized he did not really know.
This is very human. A meaty technical problem can feel validating, and that excitement can pull strong engineers straight into execution. Asking why may feel like slowing things down, challenging authority, or exposing that they do not yet understand the bigger picture.
3. They lack the relationships that reveal context
Context often lives with other people: partner teams, product managers, Staff+ engineers, customers, and leaders.
But when technical work carries higher importance, many engineers do not spend enough time learning what other teams need, what problems they are solving, or how their own work connects to organizational and business priorities.
So they get caught doing technical work alone, and over time, they keep getting more of the same kind of work.
Ironically, these patterns pull engineers deeper into the 'Stuck Tactical Executor' Spiral.
When they cannot see the value of their work clearly, they struggle to pursue higher-leverage opportunities, build the relationships those opportunities require, and practice the higher-order skills that create leverage.
Context breaks this cycle by helping you see your work more accurately, so others can see it too.