The Real Efficiency Bottleneck Isn’t Planning, it’s Thrash
Why planning aversion isn’t productive and how to find the sweet spot
This article is brought to you thanks to our sponsor, Jellyfish!
AI dev tools are everywhere, but real ROI is harder to measure.
That’s why Jellyfish built AI Impact: the first vendor-agnostic way to measure Copilot, Cursor, Gemini, Amazon Q, Claude Code, Windsurf, and review agents like CodeRabbit, Graphite, and Greptile → all in one place.
After analyzing over 2M PRs, we found AI-assisted work cut cycle times ~16% while keeping quality steady. But results vary: different tools, different teams, different outcomes. You want to know how your team is doing? Jellyfish can help.
Now let’s get into today’s topic.
A client asked to write a design doc for a multi-month, cross-team effort. His manager told him to skip it: “We don’t have time to plan.”. When my client told me this, I was half-surprised. I mean… I get it, planning isn’t most people’s favorite thing in Tech. It feels like slowing down, and plenty of teams have been dragged down by long, convoluted planning cycles. No wonder a real aversion to it has grown.
But to skip planning completely is a risky business, especially if it becomes the norm.
We like to get things done faster, but we like to get them done right even more. Skipping planning doesn’t help with either; it just pushes the hard parts downstream, where they’re harder and more expensive to fix.
This article takes on the rise of planning aversion and the most common arguments against planning. We’ll look at why planning feels so disliked, what it’s really for, and how to keep it light enough to move quickly while solid enough to prevent thrash.
Isn’t planning just a bunch of docs and spreadsheets and meetings?
If you’re a manager who’s slogged through a multi-week planning cycle full of decks, spreadsheets, and approval meetings, you’re right to be skeptical. And if you’re an IC who’s spent days writing documents and sitting in meetings where nothing useful came out, you’re right too. Planning didn’t become unpopular by accident.
But planning is more than its bureaucratic parts. The essence of planning is the moment when you ask:
What problems are we solving and why? How hard are they? What do I need to solve these problems? Who should be involved in this? What are the unknowns? What’s the riskiest part? In which order should we tackle things?
Answering those questions doesn’t require a six-month roadmap or a 20-page design doc. It can be as lightweight as sketching an edge case on a whiteboard, a quick Slack thread with a diagram, a one-pager to align two teams, or a 15-minute sync on rollout steps.
There are small planning moments everywhere. They don’t have to be heavy; they just need to happen. The format you choose matters less. What matters more is finding clarity and making sure you’re going in the right direction.
If plans always change, why bother?
This question gets to the crux of planning aversion, and the reframe I like to use comes from the following quote:
“Plans are useless, but planning is everything.” - Dwight D. Eisenhower
What Eisenhower meant is that the artifact (aka the plan) will always become outdated. But the act of planning is where the value comes from because it forces you to think through risks, tradeoffs, and unknowns. That’s what makes you better prepared, even when things change.
Planning is mental hygiene. Brushing your teeth doesn’t guarantee perfect dental health, but skipping it guarantees problems later. Planning works the same way: small, consistent steps that keep projects healthy.
Zero planning will come to bite you, while over-planning will slow you down. The sweet spot is just enough planning to create clarity and alignment, without wasting weeks on details that won’t survive first contact with reality.
What if we just don’t have time to plan?
There’s a lot of pressure on managers and individual contributors alike to deliver faster and better. I get it. When you have a mountain of items on your to-do list, planning only feels like adding more to the list. It’s easier to just start building and figure things out along the way.
But when we don’t plan and jump headfirst into building, what usually ends up happening is: realizing the problem wasn’t clear, or that the solution was not correct or complete. Or the right stakeholders were not involved, people weren’t aligned, and the solution is built on a house of cards of incorrect assumptions.
We say we don’t have time for planning, but then we spend twice as much on rework, firefighting, and debates that could have been avoided. Now the deadline is missed, everyone’s frustrated, and there’s even less time.
The truth is you almost always have time to think ahead. And this is not a bottleneck. The real bottleneck is thrash. So planning needs to be seen as a task in and of itself.
But isn’t skipping planning a way to show bias toward action?
“Bias toward action” is one of the most misused phrases in tech. I wrote about why it should be used with caution here.
Yes, most decisions aren’t one-way doors. Yes, you can usually fix things later. But ask yourself: is the rework really worth it? Does skipping a short alignment step actually get you to results faster?
A true bias toward action means taking thoughtful action fast enough to learn, deliberate enough to avoid waste. And the activity of planning is a form of action. Nuance matters.
How do you find the sweet spot between no planning and drowning in it?
It depends. The right amount of planning varies with your role, the scope, and the length of the effort. An EM planning a quarter looks different from an IC scoping a feature, and scoping a feature looks different from architecting a multi-quarter cross-functional effort.
Two rules of thumb help:
Planning should never take as long as the work itself. If you’re spending more time planning than building, you’ve gone too far.
Planning should move from high-level to fine-grained as you go. Start broad, then add detail as the effort gets closer and more concrete.
So how do you right-size it in practice? Here’s what that looks like for engineering managers, leaders, and individual contributors.
For engineering managers and leaders
Planning at the leadership level isn’t about creating a year-long plan in excruciating detail. It’s about giving your team a vision and a high-level roadmap to help them understand the priorities and allow them to move efficiently.
The way to do that is to build planning into the rhythm of the work. That can look like:
Creating a high-level roadmap for the quarter so priorities are clear. Focus more on the vision and less on the details.
Writing lightweight strategy docs that focus on tradeoffs.
Running backlog refinement and sprint planning as ongoing mini-planning cycles, not one-off events.
Making space for design reviews and spikes before complex projects start.
Each of these practices is an investment that creates a steady rhythm of planning and replanning that keeps the team aligned as things shift.
For individual contributors
It’s about giving yourself and your teammates enough clarity to avoid thrash once you start building.
The fastest way to do that is to make your thinking visible. That can look like:
Writing a one-pager to clarify the problem and the approach.
Getting alignment with cross-functional partners before diving in.
Asking for a design spike if the solution isn’t clear.
Drawing a system diagram to spot edge cases and integration points. Show, don’t tell!
Breaking down a big problem into a to-do list of smaller, testable tasks.
None of these steps are heavy. But each one makes misalignment visible earlier, when it’s cheap to fix. And each one creates artifacts you can share, so you’re not carrying the whole plan in your head.
Conclusion
You do not have to love planning. You do have to do enough of it to give your work a real shot. Keep it light. Do it often. Use it to reduce risk and thrash. That is how you move fast without paying for it later.
What’s your stance on planning? Have you found the sweet spot for you and your team? Would love to hear from you.
Until next time,
Irina
Did you enjoy this article? Hit the ❤️ button or share it with a friend or coworker. 🙏🏻
This is such a necessary distinction. We often confuse “planning” with “process”, and in our rush to be agile, we throw out the thinking part along with the bureaucracy.
The concept of “thrash” as the real bottleneck is spot on, it’s far more expensive to build the wrong thing fast than to take the time to align on the right thing first.
Thank you for writing this!
Thank you very well written....I like how you use the word alignment....also I refer to sequence management...to show alignment and sequence of what needs to happen when by who before other pieces...dependencies can be part of the unknowns and planning can flesh these out....