When leadership says “do more with less,” I’ve noticed teams interpret this as either work longer hours or try to do everything in parallel. The harder question is figuring out which few things actually multiply impact before you’ve spent quarters chasing the wrong constraints.
Research from Karlstad University found that not all problems have equal impact. When analyzing what actually affects how developers feel about their work, one factor dominated:
Process Unsuitability showed the strongest negative impact on job satisfaction: When processes don’t align with organizational needs or force teams to follow outdated methodologies, this explained the largest portion of satisfaction variance.
Compare that to documentation debt or infrastructure debt. Process misalignment has nearly 2x the correlation. So more than fix everything in parallel, you can weigh in that some problems matter way more and fixing them first will be an amplifier. Doing more with less means spending effort on constraints that actually bind, not spreading thin across every visible issue.
Daniel Lemire sort of frames this in why speed matters:
A common mistake is to spend a lot of time—too much time—on a component of your project that does not matter.
That’s exactly what happens when teams respond to “do more with less” by trying to work on everything. You end up optimizing documentation when process misalignment is costing you 2x more. You parallelize across six initiatives, but most of them don’t move the needle. The work looks busy because you’re in more meetings, touching more codebases, mentioned in more updates; but the total impact stays flat because effort scattered across low-leverage work doesn’t compound.
You learn by making mistakes. The faster you make mistakes, the faster you learn.
More than working faster, speed is about delivering faster by not wasting time on irrelevant components. This indirectly pokes at the need to iterate faster but that’s means, not the end-state. The hard part is identifying what actually matters before you’ve already optimized the wrong thing. GitHub’s developer experience work shows how assumptions break:
Despite expectations that meetings would be a major bottleneck… GitHub engineers reported 19% fewer meeting-heavy days than industry benchmarks, allowing leadership to prioritize other challenges.
They could have spent quarters reducing meetings and seen zero satisfaction improvement because meetings weren’t the binding constraint. Process unsuitability was. The measurement work itself requires effort. You still need some parallel exploration just to figure out where to focus, but its important to know when to stop exploring and commit.
Outlier investigation drives targeted improvements. Teams performing significantly above or below benchmarks revealed underlying causes—from system complexity to strong incident-handling practices—that informed where to prioritize investments.
The pattern I’ve seen work is where you measure enough to identify the 2x impact problems, then go deep on those while explicitly deprioritizing everything else. The tradeoff is that shallow parallelism produces visible activity. Deep focus looks quiet in the short term. You’re betting that fixing process misalignment creates more lasting value than touching twelve surface issues, and you need organizational capital to make that bet stick.
Teams that pick one or two high-leverage problems and go deep consistently outperform teams that parallelize across everything leadership mentioned. Not because they worked less, but because their work accumulated context rather than spreading thin. The team that deeply understands why processes don’t align can redesign them. The one that superficially touched twelve issues delivers mediocre improvements everywhere and moves on before seeing if anything worked.
There is a measurement trade-off though. You need some parallel exploration just to figure out where the 2x problems are. GitHub’s outlier investigation required looking at multiple teams to find patterns. The skill isn’t avoiding all parallelism—it’s knowing when you’ve learned enough to commit. Most organizations explore too long because it feels safer than betting, or commit too early because exploration looks like wasted effort.
The question isn’t whether some problems have 2x the impact. The question is whether you have enough conviction to ignore everything else while you fix them.