The Addiction to Urgency (Part 2/2)
A Requiem for the 100% Plan
In Part 1, we looked at how "high performance" often disguises a stress addiction. How cortisol and adrenaline trick us into thinking the crunch is working. How the system rewards fire drills and ignores the teams that never need one. And how the content team, the quiet one that just delivers, outperforms almost everyone over time.
But Part 1 left one question open: if 80% is the rightcapacity, what does that actually look like? How do you know when you're planning at 80% and not at 120-150%? And what do you do with the room that opens up?
Because the strange thing is, when you first create space, nobody knows what to do with it. It often just feels... weird.
An Unwrapped Gift
If you've been running at 150% for years, free timedoesn't feel like a gift. It feels like a threat. Your brain, wired for emergencies, doesn't know what to do with silence. There's no deadline to chase. No fire to fight. No adrenaline to ride.
And the instinct kicks in immediately: fill it with stuff. More initiatives. More tasks and increments. More, and more. To infinity...and beyond! The backlog is bottomless, remember? There are always 50 to 100 things waiting. (If you generally don't have a backlog but you have a product, that's another subject)
So, the moment a gap appears, it's gone before anyone noticed it existed.
This is the paradox: the teams that need breathing room the most are the least likely to take it when it appears. Not because they don't want to. Because the system won't let them. A manager sees unused capacity on a dashboard, and the reflex is instant: "If they have time, they can take on more!"
The space often doesn't even survive its first Monday morning standup (the team's brief daily sync where everyone shares what they're working on).
How to Spot the Difference
There are two tests, and they work on different levels.
The individual one: are you still working on the weekend? Not at your desk necessarily. In your head. Running through tomorrow's problems on a Sunday evening. Mentally sorting the backlog while pretending to watch a movie. If your brain can't stop working when your body stopped, you're not at 80%. You're carrying the system home with you.
The team one: does the team have room for quality and focus? Not in theory. In practice. Is there space in the sprint (the team's fixed timebox for delivering work, usually two weeks) to actually think about what you're building, or is every hour accounted for? Agile lists focus as a core value. But focus needs room. A team planned at 120% doesn't focus. It triages.
Here's the thing most plans get wrong: when every person on the team has tasks filling their entire capacity, that's not 100%. That's already 150%. Because the plan doesn't account for context switching, for meetings that run over, for the question from another team, for the production incident that takes half a day. All of that is invisible in the plan but very real in the week. What feels like "everyone has something to do" is already overload. The plan just doesn't show it.
Toyota identified this decades ago. They called it "Muri", one of their three system diseases alongside "Muda" (waste) and "Mura" (unevenness). Muri means overburden. It's what happens when you load a system beyond its sustainable capacity. Not a people problem. A design problem. And Toyota didn't build one of the most efficient production systems in history by planning at 100%. They built it by making room for reality.
And yet, the same country that gave us Muri and Hara Hachi Bu also gave us "Inemuri", meaning: falling asleep at your desk as a sign of dedication. And "Karoshi" which means: death by overwork (officially recognized as a cause of death by the Japanese government). The wisdom exists. The system overrides it. That's not a Japan problem. That's an everywhere problem — maybe not to the extreme, but it exists. The knowledge of what's healthy and what's sustainable has been around for decades. Most organizations just choose not to apply it.
Now look at what's not on the board. The automation that three developers have been talking about for months but "there's never time." The quality improvement that everyone agrees would save hours per week but keeps getting deprioritized. The learning that would make the team faster next quarter but doesn't fit in this one.
That's your X%. It's not missing. It's being sacrificed.
The team at 150% knows what they should be working on. They just can't. The team at 80% has room to actually do it. And over time, that room compounds into something the overloaded team can never catch up with: a system that gets better instead of one that just survives.
Stop Starting, Start Finishing
There's a phrase in lean thinking that sounds simple but feels deeply uncomfortable in practice: stop starting, start finishing. It means exactly what it says. Instead of pulling new work in, finish what's already in progress. Instead of starting five things, fully complete two.
The discomfort is real. When you stop starting randomly and/or constantly, the board looks "empty." The velocity chart dips. Someone in a standup will say "shouldn't we pick up X and Y as well?" And the pressure builds, because the system is trained to equate activity with progress.
But finishing things is where value lives. A half-built feature delivers zero value. A completed one delivers all of it. And the more work in progress you carry at the same time, the longer everything takes to finish, because context switching, dependencies, and waiting time multiply with every additional item.
There's a reason the Pareto Principle (roughly 80% of effects come from 20% of causes) basically keeps showing up in every management book ever written: roughly 20% of your backlog items will deliver 80% of the value. That ratio doesn't change just because you plan at 150%. You just end up working on the 80% that barely moves the needle while the 20% that matters sits in a queue behind them.
Planning at 80% isn't about doing less. It's about finishing the right things. The backlog doesn't shrink because you work harder. It shrinks because you stop starting things you can't finish properly.
The Wiggle Space
I've introduced something with teams that I call the Wiggle Space. Don't worry, it's not a new framework. It's a swimlane on the board. A simple, visible line that holds a different kind of work: the things that are always there, always waiting, and always matter.
Automation. Quality improvements. Aligned learning. Technical debt reduction. The kind of work that makes next month easier but never feels "urgent enough" for this sprint or delivery cycle.
Toyota's original Lean framework identified seven types of waste. Later, an eighth was added: unused human potential. It's the waste you create when people have skills, ideas, and drive but no room to apply them. Every team has someone who knows exactly what should be automated, what should be improved, what would make everything faster. They just never get the chance because every plan is full before it starts.
The Wiggle Space is where that investment lives. Not in a yearly training budget. In the daily work.
The rule is straightforward: when your planned sprint goal work or delivery cycle is done (or effort for a specific competence) and there's nothing left to pick up from the current commitment, you don't start pulling in new sprint scope. You work on what's in the Wiggle Space. The team aligns beforehand on what's in that space. Of course, if something comes up that has to do with the "normal" work, the Wiggle Space work is deprioritized again.
It sounds small. But it changes the entire dynamic. The team stops feeling guilty about "having nothing to do" between finishing the sprint goal and the sprint end. The Wiggle Space gives that time a purpose. And over weeks and months, the compound effect is visible: fewer manual processes, fewer recurring bugs, a team that spends less time firefighting because they invested in prevention when they had the chance. (It's probably obvious that a prerequisite is that the team generally already knows what they're working on and has some sort of authority over their system.). And not to mention: it converts the conversation about the goal away from "does everyone have enough to do?" to "This is what's necessary" and that's it. There's enough "other stuff" to do but its focus is on improvement and support of the main goal when necessary. Not opening up multiple goals that lead to losing focus.
The content team from Part 1? They usually have something like a Wiggle Space, even if they don't call it that. They protect their room. They use it. That's why they get better while everyone else stays busy.
Where AI Enters the Room
Here's the honest truth about AI in teams right now: it can technically do a lot. It can prepare refinements. It can draft documentation. It can summarize meetings, generate test cases, flag dependencies. In theory, AI could orchestrate entire workflows with minimal human intervention.
But that's not where most teams should start, especially if they haven't worked with AI at all before (and that's more teams than you'd think).
There's a scene in Douglas Adams' "The Hitchhiker's Guide to the Galaxy" where a supercomputer called Deep Thought is built to answer the Ultimate Question of Life, the Universe, and Everything. It computes for 7.5 million years. The answer: 42. Everyone stares. Nobody knows what to do with it. Because by the time the answer arrived, everyone had forgotten what the question was.
That's what's happening with AI in most organizations right now, in my experience and from conversations with others. AI comes in and suddenly what used to take 100% of a team's capacity takes 40%. The answer is there. The capacity is "free". And instead of asking "what should we do with this room?", the reflex kicks in: fill it. More tickets. More output. More velocity on the dashboard. The same 150% engine, just running on a faster fuel. The answer arrived, but the question was never asked: are we measuring output, or are we measuring whether this is actually really sustainable?
Most teams should start with the Wiggle Space.
The automation that nobody had time to build? AI can help build it. The recurring report that eats two hours every week? AI can generate it. The onboarding documentation that's been outdated for a year? AI can draft the update. These aren't glamorous use cases. They don't make it into keynote presentations. But they're the ones that actually free up capacity for the work that matters and humans generally care for. We all need purpose in the end.
The mistake organizations make is using AI to accelerate the 120%. More tickets, faster delivery, higher output on a dashboard. That doesn't solve anything. It just runs the same broken engine at higher RPM until it breaks faster.
Using AI for the Wiggle Space is different. It's investing in the 20% that was always being sacrificed. And the return isn't more output. It's a team that has room to think, room to finish, and room to get better.
The State Nobody Plans For
Creativity needs room to breathe. Barely anything great was ever built in permanent crunch mode. It happens in Flow.
Not bored and not overworked. Flow.
Mihaly Csikszentmihalyi described Flow as the mental state where you're fully immersed in what you're doing. Time disappears. Focus feels effortless. You're not pushing yourself through the task, you're pulled into it. But Flow has a prerequisite that most organizations ignore: the balance between challenge and skill.
If the challenge is too high and the skill too low, you get anxiety. If the skill is too high and the challenge too low, you get boredom. Flow lives in the channel between the two. It's where the work feels meaningful and the capacity feels right.
Game designers have understood this for decades. Jenova Chen (the creator of "Journey" from 2012) built his entire master's thesis around applying Flow theory to game design. His insight: if you overload the player, they quit. If you bore them, they quit. The sweet spot is the Flow channel, where challenge and skill stay in balance and the player feels in control of the experience.
Teams work the same way. A team at 150% isn't in Flow. It's in survival mode. Anxiety, triage, shortcuts. The challenge overwhelms the capacity, and the quality of thinking drops. A team at 80% with meaningful work in the Wiggle Space has a chance to be in Flow: enough challenge to stay engaged, enough room to do it well, and enough control to feel ownership over what they build. And honestly: in most work environments we really don't need to worry about boredom. Nobody writes "enable Flow" into a sprint plan. But every decision about capacity either creates the conditions for it or destroys them.
The 80% Choice
There's one thing I've learned in every coaching engagement: the most valuable work happens in conversations that no tool can automate.
Trust isn't built in delivery cycles. It's built in the space between them. And if your system leaves no space, trust never gets a chance to form.
AI can help you protect that space. Not by replacing the conversation, but by handling the noise around it. The prep work, the repetitive tasks, the administrative overhead that eats into the time where real collaboration could happen. But the space is only useful if you protect it. If your organization treats freed capacity as available capacity, you haven't gained anything. You've just found a faster way to exhaust the same people.
Planning at 80% doesn't mean doing 80% of the work. It means being honest about what a team can sustain. It means protecting the Wiggle Space. It means choosing to finish instead of choosing to start. And it means accepting that a board with fewer items might deliver more value than a board that's full.
The content team doesn't "need" AI to survive (or any team really). But when the content team gets support in their Wiggle Space (with or without AI), something shifts: the automation actually gets built. The quality actually improves. The learning actually happens. Not because someone finally prioritized it. Because there was room for it.
The "high performance" team (with or without AI) comes to cram more into the same sprint. More tickets, more initiatives. And for a quarter or two, it looks like it's working. Then the same thing happens that always happens: the crash. That's the nature of fire-alarm mode.
The choice isn't about technology. You can leave AI entirely out of this subject (but look, it's necessary now, this won't go away). It's about what your organization believes "enough" looks like. And whether your system rewards the team that's always on fire, or the one that never needs to touch the fire extinguisher.
The 100% plan had a good run. But it's time to let it go.
If you're wondering how you can wiggle some improvements into your workspace, book a free consultation call: