Fix What Hurts Most
I have talked about the Pareto Principle a few times before. Many people know it as the 80/20 rule. I do not treat it as some law of physics or precise math, but do I treat it as a useful heuristic. In messy systems, a small number of problems often create a disproportionate amount of the pain. I have leaned on that idea for years in both my personal and professional life.
When I join a new team that needs help digging itself out of a hole, this is the obvious first question: what is consuming most of your time? To no one’s surprise, the answer is rarely productive work that delivers value. It is usually toil, meetings, red tape, or endless communication cycles.
And to be clear, most teams do not need help noticing what is draining them. They usually know. What they often lack is the space, support, or focus to go after it systematically.
It is also rarely possible to tackle all of those problems right away, mostly because the team is already drowning in work and constantly firefighting. So the next question becomes: if we could eliminate or reduce just one of them, which one would give us the most bang for the buck?
Very often, addressing just the first two or three problems the team brings up removes a big chunk of the pain. And if not the toil itself, then at least the mental load and that sense of hopelessness that teams feel from time to time.
So let’s say you want to take a similar approach. You manage to identify the 20% of offenders causing 80% of the trouble your team faces. Now what do you do with that information?
A simple sequence that works well here is this:
- Question every requirement
- Delete what is unnecessary
- Optimize what remains
- Reduce cycle time
- Automate where it makes sense
That sequence is simple, but it works because it forces teams to stop treating all work as equally valid.
And yes, sometimes the biggest blocker is not technical at all. The team knows what should change, but lacks the authority, air cover, or slack to change it. Sometimes the work sticks around because nobody wants to own the political fight. Sometimes it stays because the team is genuinely overloaded and cannot even lift its head long enough to challenge the status quo.
But even then, this kind of thinking still helps. It gives you a way to look for leverage instead of just accepting the pain as permanent.
I would also add one more question: are we even the right team to be doing this work?
Sometimes the answer is yes, given the constraints at the moment. But if full automation is not possible, or not possible yet, a valid approach is to optimize the work, document it, and make it transferable so someone else can do it. The goal is not just to make the task faster. The goal is to reduce the load on the team that is currently carrying too much.
This is not an argument against headcount, better prioritization, or stronger leadership. Sometimes the team really is overloaded, understaffed, or trapped in bad constraints. But even in those situations, reducing high-friction work is often one of the fastest ways to create some breathing room.
Once that starts happening and the backlog begins to clear, you loop back and attack the next problem.
Some teams can afford to reserve one day a week, or every fourth sprint, to pay down technical debt. Others cannot. In those cases, the work has to be smaller and more opportunistic. But the principle still holds: if you never make room to remove friction, the friction wins.
And this is where things get even more interesting.
Phases 3 and 5 used to take a lot of time themselves. In many cases, teams dropped perfectly valid ideas because they were too busy firefighting to optimize or automate anything. The fix might have been obvious, but there was never enough time to build it.
That has started to change. With AI agents and coding tools, some of those fixes can now be addressed in a few hours. At most, a day or two, by someone who knows what they are doing. That does not magically remove bad process, unclear ownership, or bureaucratic nonsense. But it does lower the cost of turning a good idea into something real.
Work that used to sit in the “good idea, no time” bucket for months can now become a script, a tool, a workflow, or at least a working prototype before the week is over.
That does not remove the need for judgment. You still need to pick the right problems, understand the real constraints, and avoid automating nonsense. But it does remove many of the old excuses. The barrier to making meaningful improvements is lower than it has ever been.
So the real challenge is no longer just finding the 20% that hurts the most. It is building the habit of going after it on purpose, again and again, without getting distracted by noise.
Teams do not usually climb out of the hole through one heroic effort. They do it by removing friction, one high-leverage fix at a time. That is how the work becomes more manageable again. And that is how people get some capacity back for the things that actually matter.