I was sitting across from a CEO last month who said something that made my heart sink: “I think my engineering team has checked out. We used to ship features in days. Now everything takes weeks. Maybe I need to replace my CTO.”
I’ve heard this story a hundred times. Hell, I’ve lived this story from both sides. And here’s what kills me: everyone in that room is trying their hardest, yet somehow the whole system is grinding to a halt.
The CEO sees lazy engineers. The engineers feel buried alive. And nobody, nobody is talking about the invisible monster that’s actually eating their company from the inside out.
The Conversation That Changes Everything
Picture this: Your star developer Theo walks into your office. Six months ago, he was shipping features like a machine. Now he looks exhausted, and you’re about to have that conversation.
“We need to talk about velocity,” you say.
Theo sighs. “I know it looks like I’m slowing down, but there’s just… more work now.”
“But we hired three more developers. Shouldn’t things be getting faster?”
And right there, in that gap between what seems logical and what’s actually happening, lives the beast that’s drowning your team.
The Matrix You Can’t See
Your business is a complex adaptive system. I know, I know that sounds like consultant speak. But stick with me, because once you see this, you can’t unsee it.
Every feature you ship isn’t just code that gets deployed and forgotten. It becomes part of an increasingly tangled web. That simple notification system you built in week one? It now touches seventeen other features. That “quick fix” for enterprise clients? It’s created invisible dependencies that slow down every future change.
Here’s what happened at ACE (a company where I spectacularly failed as CTO): The CEO saw symptoms: delayed features, missed deadlines, frustrated customers. He hired me to “fix” his slow engineering team. But we were both blind to the real problem: the technical complexity had already passed a critical threshold. The system wasn’t slow because people weren’t working hard. It was slow because it had shifted from a liquid state into what systems thinkers call “boiling.”
What Boiling Really Looks Like
When a system boils, it’s not dramatic. There’s no explosion, no mass resignations. Instead, you get this:
- Your best developer spends 80% of their time reading code instead of writing it
- Simple changes require touching twelve different files
- Nobody can predict how long anything will take anymore
- Every new feature feels like it might break something else
- Your team has meetings about meetings to coordinate the coordination
I watched Theo go through this in our book. One day Alice confronts him: “Why are things taking so long? Are you losing interest in our project?”
Theo tries to explain, but how do you articulate that the invisible complexity has gotten so dense that every line of code feels like defusing a bomb? You can’t. So it comes out as “there’s just more work to do.”
Alice, like most CEOs, hears excuses. Theo feels unheard. Trust erodes. And the system keeps boiling.
The Brooks’ Law Trap
Here’s where it gets worse. The CEO’s instinct, add more developers, is like pouring gasoline on a fire.
Fred Brooks figured this out in 1975: adding people to a late software project makes it later. But we keep doing it because it feels like it should work. More hands, more work done, right?
Wrong. Dead wrong.
Every new developer needs to understand the existing complexity. Who teaches them? Your existing developers, who are already drowning. Now they’re drowning while teaching someone else to swim in the same churning waters.
I’ve seen teams go from shipping daily to shipping monthly after doubling in size. Not because the new people were bad—they were brilliant! But because the communication overhead grew exponentially. Three people need three communication paths. Ten people need forty-five. Twenty people need… you get the idea.
The Hidden Phase Change
Water doesn’t gradually become ice. At 32°F boom! Phase change. Your engineering organization works the same way.
When complexity reaches a critical point, your liquid system (flowing, adaptive, productive) suddenly shifts to boiling (chaotic, unpredictable, overwhelming). Miss the warning signs, and it’ll freeze solid, where every change requires six approvals and nothing ships without a committee meeting.
Most leaders never see the phase change coming. They’re watching the wrong metrics:
- Story points delivered (meaningless when complexity changes)
- Lines of code written (actively harmful to track)
- Number of features shipped (without considering the compound cost)
Meanwhile, the real signals are screaming:
- How long does onboarding take?
- How many people need to be consulted for a typical change?
- What percentage of time goes to maintenance vs. new development?
- How often do fixes create new bugs?
The Way Out
So your team is drowning. Now what?
First, stop adding water to the pool. No more developers until you address the complexity. I know this feels counterintuitive when you’re behind on everything, but trust me—I learned this the hard way.
Second, create boundaries. Theo saved his company by splitting their monolithic team into focused squads. B2C team here, B2B team there, shared services in the middle. Suddenly, not everyone needed to know everything. The cognitive load dropped. The system began to flow again.
Third, invest in reducing complexity before adding features. This is the conversation I wish I’d had at ACE:
“We need to spend the next sprint on refactoring and automation.”
“But what about the features our customers are waiting for?”
“Those features will take twice as long if we build them on quicksand. Let’s build on solid ground instead.”
The Real Conversation
Here’s what that conversation between CEO and CTO should actually sound like:
“Our velocity is dropping.”
“You’re right. Our technical complexity has grown past our team’s ability to manage it. We’re drowning in our own success. Here’s what I propose: we pause feature development for two weeks, split our team into focused units, and invest in the infrastructure that will let us ship faster for the next two years.”
“But our competitors—”
“Are probably drowning too. The question is: who figures out how to swim first?”
The Pattern You Can’t Unsee
Once you recognize this pattern, you’ll see it everywhere:
- The startup that was lightning-fast at 5 people and molasses-slow at 50
- The team that ships daily until they hit 10,000 users, then can barely ship monthly
- The CTO who was a hero at Series A and a “bottleneck” at Series B
It’s not about the people. It’s about the system.
Your engineering team isn’t slow because they’re lazy, checked out, or incompetent. They’re slow because they’re drowning in complexity that nobody, including them, can fully see or articulate.
What Happens Next
You have two choices.
Keep treating the symptoms: hire more people, push harder, maybe fire your CTO and hope the next one has a magic wand.
Or start seeing the system: recognize the phase change, create boundaries, reduce complexity, and give your team the tools to transform that chaotic boiling back into productive flow.
The CEO I mentioned at the start? He called me last week. They spent a month refactoring, creating team boundaries, and building automation. His exact words: “It’s like we gave the entire engineering team their brains back.”
His team wasn’t slow. They were drowning.
The question is: what about yours?
P.S. If you’re reading this and thinking “this is exactly what we’re going through,” you’re not alone. Every scaling technology company hits this wall. The ones who thrive are the ones who see it coming and act before the system boils over. The first step? Stop adding water to the pool and start creating boundaries that let your team breathe.
