You’re receiving this email because we connected in some way: through coaching, a discovery or complimentary call, a 1:1 conversation in a community, a talk, or resources and workshops I’ve shared on behavioral interviews, career growth, and technical leadership. You can unsubscribe at any time.

~10 minute read | Read in browser​

By Shine Garg

Staff+ Career Coach | Former Staff Engineer

Over the first three editions, we looked at why your career can feel stuck despite strong work: limited influence, the execution trap, and work that sounds smaller than it is when the context around it is missing.

Together, these patterns point to a deeper question:

So what actually helps your work become trusted, adopted, and valued at a broader level?

Some of those capabilities are obvious: technical depth, strong execution, and reliability. But others are easier to overlook.

One of the most important is contextual range: the ability to understand the technical, organizational, and business context around your work.

From the last edition, we know that context changes the perceived value of your work. This edition goes one layer deeper:

Where does strategic context usually live?

Most of the time, it is scattered across people, teams, systems, incentives, and priorities. You have to uncover it.

The three types of strategic context

Most organizations have three types of strategic context:

1. Technical context
2. Team or organizational context
3. Business context

Technical context is the context software engineers are usually most familiar with. This includes the codebase, system architecture, tools, infrastructure, technical constraints, and technical vision and strategy.

Team and organizational context is how work moves through people and teams. This includes team goals and dynamics, cross-functional dependencies, collaboration patterns, ownership boundaries, deliverables across departments, and alignment with company priorities.

Business context is about the business itself. This includes customer needs, product direction, revenue targets, market competition, profitability, board or shareholder expectations, and the risks or opportunities the company is trying to manage.

Each context answers a different question:

Here’s one way to represent these contexts:

Needless to say, these are default starting points rather than rigid boundaries. Strong engineers, managers, and leaders can all operate across all three contexts.

But different job functions tend to enter the same problem through different default focuses.

Engineers may start with system design and code correctness, reliability, and maintainability. Managers may start with team capacity, ownership, coordination, and adoption. Leaders may start with business risk, investment, opportunity cost, and long-term leverage.

This is also why “it depends” is such a common answer in software engineering. At its best, “it depends” is a signal that the answer depends on context rather than a universal truth.

The more mature move is to ask: What context are we missing?

That question becomes even more important as your scope grows.

The problem statement is where the work begins

A few months after I joined a new organization as a Staff Engineer on the platform team, I was given a classic one-line problem statement:

Build a Pub/Sub system for the company.

On the surface, this can sound like a technical infrastructure project. Choose the right messaging pattern. Evaluate the right technology. Design the system. Build it. Get teams to use it.

But the one-line problem statement was only the beginning.

At the time, the organization had ~200 engineers and was primarily a Ruby shop, with some greenfield projects beginning to adopt Golang and limited use of Python in the Data org.

Different teams had already found bespoke ways to solve their asynchronous service-to-service communication needs.

Some had adapted Sidekiq as a de facto Pub/Sub system. Others were using Twilio Segment, a customer data platform system, in ways that looked more like internal event distribution.

These choices made sense locally. Teams had problems to solve, and they used the tools available to them.

But across the company, the lack of a golden path was creating fragmentation, duplicated effort, and architectural debt. Anti-patterns were proliferating. New features took longer to ship, and production debugging became harder. Leadership was concerned that existing tools were being stretched beyond their intended purpose.

So, the deeper question became:

What kind of shared communication layer can this company adopt, operate, trust, and grow on top of?

This question required all three kinds of context.

Technical context: What can work here?

The technical question could easily have turned into a technology debate.

Some engineers wanted Kafka for its low latency and high throughput. That preference was understandable. Kafka is powerful and widely used for event streaming.

But at the time, Kafka’s Ruby bindings were weak. The company also had limited in-house Kafka operational expertise, and leadership was hesitant to take on the burden of running a Kafka cluster ourselves.

We also evaluated Amazon Kinesis. It came with its own constraints, including weaker Ruby bindings and ongoing operational complexity around managing and scaling shards.

The technical context made the decision criteria clearer:

• What would work well in a Ruby-heavy environment?
• What could teams integrate with safely?
• What could the company operate with confidence?
• What would support a broad set of asynchronous communication use cases without creating unnecessary operational drag?

This clarity was important because a technically impressive solution that the company cannot operate, support, or integrate well becomes a future burden.

Technical context helps you understand what can work in the system you actually have.

Team and organizational context: What can become real?

The organizational problem was just as important.

Some teams were already considering building their own Pub/Sub systems. A few were willing to host something for the entire company. In some cases, their management was supportive. In others, alignment was less clear.

That created a second layer of questions:

• Who needed this first?
• Which teams would be willing to adopt it early?
• What use cases must the MVP support?
• What would make teams trust this system in production?
• What migration support would they need?

The company needed a shared golden path, but a golden path only matters when teams actually walk it.

A platform system becomes real when teams can adopt it, trust it in production, and stop solving the same problem on their own.

Team and organizational context helps you understand what has to change for the system to become real.

Business context: What is worth pursuing?

The business context gave the work its broader weight.

The cost was not just fragmented infrastructure. It was fragmented engineering capacity.

When every team solved asynchronous communication in its own way, engineering time went into rebuilding the same foundation instead of building product capabilities on top of it. Each custom path also made the company harder to operate, debug, and scale.

The value of a shared Pub/Sub system was that it turned a repeated engineering problem into common infrastructure, so teams could spend more of their time on differentiated product work.

Given the technical constraints, organizational adoption needs, and business priorities, we eventually chose SNS plus SQS.

Some engineers were disappointed because it was not the flashiest answer. But it fit the company’s technical reality, had support from technical and business leadership, and gave teams a shared foundation they could actually adopt.

The simplicity of the solution paid off. Unlike Kafka or Kinesis, it required almost no ongoing operational maintenance from our team. The only significant operational issues we saw came from AWS outages, not from our own need to manage clusters, shards, or specialized infrastructure.

By the time I left the company 3.5 years later, the system our team built had been adopted broadly and had become the backbone for asynchronous inter-service communication across the organization. It was handling 740 million messages per day.

A few key parts of the system also led to a patent, where I was the lead inventor.

The patent mattered to me because it showed that the technical depth was real. Expanding into organizational and business context made the technical work more valuable than it would have been in a vacuum.

Together, these three contexts determine whether your work stays local to one team or becomes a company-wide investment that creates broader technical leverage.

The Staff+ operating range

Looking back, the Pub/Sub project started with a clear company need: services needed a reliable way to communicate asynchronously.

But the problem statement only clarified the need. It did not define the full range of judgment required to solve it well.

The actual work sat at the intersection of three contexts at once. That is the part many engineers miss when they think about Staff+ work.

And that is also the Staff+ Operating Range.

To operate successfully at Staff+ levels, your goal is to expand your operating range so your technical judgment can account for organizational reality and business value, without needing to maximize every dimension.

When your work sits only in technical context, it may be strong, but it can stay too narrow.

But when it connects technical, organizational, and business contexts, it becomes easier for others to understand why it matters, support it, and build on it.

This is how strong technical work starts translating into real value for the organization.

Put This Into Action

Take one project you are currently working on and write down the one-line problem statement.

Then ask yourself:

• What technical context do I understand clearly?
• What team or organizational context is still missing?
• What business context would help me understand why this work matters now?
• Who has the missing context?
• If the work succeeds, what changes beyond “the project shipped”?

The goal is to notice where your understanding is still too narrow.

For Senior+ engineers, context is something you uncover so you can shape the work more wisely from the beginning. It is a judgment tool, and understanding context is a career growth skill.

How Can I Help?

If this edition resonated, I help engineers navigate these exact challenges through 1:1 coaching and a live course on behavioral interviews.

• If you’re interested in exploring whether structured coaching support would be a good fit, reply to this email to ask about a 60-minute Clarity & Strategy Session. I’ll follow up with next steps.
• Join the waitlist for Master the Behavioral Interview as a Senior Engineer to be notified when the next cohort opens.

If you’d like more essays like this, you can read past editions here.