Concentrated Problems and Diffuse Benefits
Not all engineering work creates value in the same way.
Some work fixes a concentrated problem. One broken alert. One painful query. One bug a customer keeps hitting.
Other work creates diffuse benefits. It shortens review time, improves a handoff, makes stories clearer, or removes friction from a workflow.
Both matter. But they do not get perceived the same way.
Solving Concentrated Problems is More Visible
When a problem is concentrated, it is easier to see what is wrong. There is usually a clear symptom. A clear owner. A clear fix.
That makes the work feel important right away. You can point to the alert that stopped firing. You can show the improvement in response time. You can explain exactly what changed and why it mattered.
This is one reason concentrated problems get attention so quickly. They are concrete. They fit the shape of the work we are trained to do: identify a problem, isolate it, solve it. Repeat. That pattern works.
But it also shapes what we notice and what we overlook.
The Challenge with Diffuse Improvements
Diffuse improvements do not usually feel dramatic in the moment. A better review process does not look as impressive as fixing a bug. Clearer acceptance criteria do not feel as technical as tracking down a performance issue. Better handoffs between engineering, QA, and product are harder to demonstrate than a single visible fix.
But that does not make them less valuable.
A lot of team drag comes from small friction spread across many steps. Work waits too long for review. Requirements shift late. Work keeps coming back for another round because the expectations were unclear. People lose time resetting after interruptions.
None of those improvements looks huge on their own. Together, they shape how well a team actually moves. Microsoft Research found that developers spend roughly 12 percent of their week on communication and meetings, 11 percent on coding, and 9 percent on debugging. The places where teams most often experience drag—reviews, handoffs, clarifying requirements—live in those gaps. A slow review queue does not show up as an incident. It shows up as work sitting blocked, repeated context switching, and a team that feels it is moving slower than it should.
That accumulation is the difference between a busy team and an effective team.
|
|
Where can AI save you time?
My friends at Big Creek Growth put together a quick survey to spot the repetitive work you can hand off to automation.
|
|
Why Visibility Shapes What Gets Prioritized
Research on decision-making shows a clear pattern. People estimate importance based on how easily examples come to mind. The alert that fired five times today dominates the conversation, even if the aggregate cost of context switching across the team is larger. That is not a flaw in judgment. It is how attention works.
There is also an organizational layer. Systems of recognition and measurement highlight areas for concentrated improvement. You can demo a faster endpoint in a standup. You can write an incident postmortem about a reliability issue. Diffuse improvements—a review queue that moves faster, fewer interruptions, fewer times a story gets reopened—are harder to own and harder to show. That makes them easier to overlook, even when they cost more.
The result is predictable: concentrated problems are often easier to show direct value from. Not because they are always the highest-leverage, but because they are easier to see and measure.
Identifying What Actually Matters
Concentrated work often looks more valuable because the result is easier to see. Diffuse work is often undervalued because the benefits are spread out and harder to measure.
That does not mean concentrated work is the wrong choice. Sometimes it is clearly the right one. A production issue, a reliability risk, or a customer-facing failure deserves attention. The point is not to ignore sharp problems.
The point is to stop assuming that visible pain automatically equals the highest impact. Instead, build the judgment to choose based on what actually moves the needle for your team.
How to Balance What You Focus On
Early in your career, you get rewarded for solving the problem in front of you. That skill matters. But as you grow—whether as an individual contributor with more scope or as a leader allocating a team’s time—the expectation changes. You are expected to make better calls about where effort goes. Not just what is broken, but what is worth fixing first.
That usually means learning to see diffuse impacts before they become so large that they turn into a crisis. Context switching is stealing time every day. Unclear requirements send work back for another round. A review queue that moves slowly compounds across hundreds of decisions. These are not one-time problems. They are daily taxes that add up very quickly.
The catch is that by the time diffuse impact becomes obvious enough to fix, you have usually been paying for it for a long time. Understanding all the systems you work with—including how your team moves work through the pipeline—is part of developing that judgment.
A Framework for Qualifying Impact
The better approach is to be honest about what you are actually choosing.
When you look at a potential task or project, ask yourself three questions:
1. Is this the constraint? If the bottleneck is review queue time, optimizing an endpoint does not change when work actually ships. Amdahl’s Law formalized this decades ago—speedups are bounded by how much time you actually spend in the part you are optimizing. If coding is 11 percent of your week, purely optimizing coding speed has a hard ceiling.
2. What is the aggregate cost? Do not estimate diffuse impact intuitively. Calculate it. If you think reviews are slow, measure how many engineer-hours per week are sitting in review queues. If you think context switching is expensive, measure how much time people report losing to interruptions. Compare that number to the value of the concentrated fix.
3. What improves if we do this work? Sometimes the answer is “a lot.” Sometimes it is “this looks more important than it is.” Both are okay answers. But you should know which one is true before you commit.
Getting this right often starts with how you lead when the plan changes—which includes decisions about what to prioritize when something new arrives. It is about making those calls with full information rather than just pulling the sharpest problem off the shelf.
The teams that actually balance this well do not rely on intuition. They use explicit mechanisms.
Error budgets ensure reliable work stays on the roadmap. Toil budgets reserve capacity for systemic improvements. Regular measurement of both throughput and stability prevents optimizing one at the expense of the other. Some teams explicitly allocate a percentage of capacity—say, 20 percent—to work that improves how the team moves, not just what the team ships.
Without those guardrails, concentrated problems are often easier to show direct value from. Not always because they are highest-leverage, but because they are easier to see and easier to measure.
The best engineering work often does not look dramatic. It does not come with an incident postmortem or a visible performance graph. It often makes everything work a little better for everyone else. The goal is not to ignore concentrated problems. It is to build the judgment and the systems that allow you to choose between them and diffuse benefits based on actual impact, not just visibility.