Maxed-Out Engineering Teams Slow Down. Here's the Fix
Charity Majors says a team at 100% capacity slows down like rush-hour traffic. Here's how a Sri Lankan engineer can make that case to leadership with data, not complaints.
If you have ever watched an engineering team burnout in slow motion while leadership kept asking for more, Charity Majors just wrote the column for you. In Stack Overflow's new advice series "Paging Charity?", the Honeycomb CTO answers a senior staff engineer asking how to get leaders to stop demanding unsustainable speed.
Her answer surprised me, because it isn't "push back harder." It's "change the words you use." That reframing matters a lot for small Sri Lankan teams, where one or two people often carry an entire product.
🚦 Why a team at 100% capacity actually slows down
The core insight is counterintuitive but provable. A fully loaded system does not move faster. It seizes.
"A system running at 100% capacity doesn't go fast. It slows way, way down, like New York City traffic at rush hour." — Charity Majors
Anyone who has sat on the Colombo–Galle road at 6pm understands this in their body. Add one more car to a saturated road and everyone stops. Software teams are the same. When every engineer is booked to the minute, there is no room to absorb a production incident, a sick day, or a last-minute client change. The whole pipeline jams.
The hidden cost is resilience. Majors makes the point bluntly:
"People can't step up in a real crisis if they have nothing left in the tank."
For a two-person startup in Sri Lanka, this is existential. If both engineers are at full saturation and the payment gateway breaks at midnight, there is no reserve to draw on.
🗣️ Drop "fast" and "slow" — they end the argument
The most practical advice is about vocabulary. Majors argues that "fast" and "slow" are useless flatteners. When you say "we need to slow down," you sound like you are asking to do less, and no leader will agree to that. Everyone wants velocity. The real disagreement is about how to get it.
Her fix is to replace vague words with precise ones:
| Vague word | Precise replacement | What it actually measures |
|---|---|---|
| "Too fast" | Saturation | How much of the team's capacity the goals require |
| "Slow" | Clock rate | The friction and real time it takes to ship |
| "Tech debt" | A named taxonomy | Specific categories of debt, not one vague bucket |
Once you talk in these terms, the conversation shifts from emotion to engineering. "We are at 95% saturation" is a fact a manager can act on. "We're going too fast" is a feeling they can dismiss.
📊 Use the frameworks that already exist
You do not have to invent a measurement system. Majors points to three that already carry weight with leadership:
- DORA metrics — deployment frequency, lead time for changes, change failure rate, and time to restore service. These are the industry-standard four.
- SPACE — a broader framework for developer productivity that looks beyond raw output to satisfaction and collaboration.
- Jack Danger's technical debt taxonomy — a way to name and categorise debt instead of treating it as one undefined blob.
Key takeaway: Stop arguing about speed. Measure saturation and clock rate with a named framework, then let the numbers carry the argument for you.
The Sri Lankan reality is that most small teams measure nothing. There is no dashboard, just a founder's gut feeling that "we're behind." If you are the engineer in that room, being the person who shows up with DORA numbers instantly changes your standing. You stop being the one complaining and become the one with data.
💡 Lead with evidence, not grievances
Majors's sharpest point is about how managers actually listen. Predictable complaints get tuned out. Documented wins get attention. The engineer who wrote to her already had the proof: when work inflow slowed slightly, the team's velocity went up.
That is the move. Don't say "we're overloaded." Say:
- "Last quarter, when we cut intake by 20%, our cycle time dropped and we shipped two features early."
- "We have had three incidents this month. Each one came during a week we were over 90% booked."
- "Here is our change failure rate before and after we added review slack."
This is also where Sri Lanka's hustle culture works against us. Overtime is often worn as a badge. But unpaid, unrecorded overtime hides the true cost of saturation. If your team is regularly working beyond contracted hours, at least quantify it. Our free Sri Lanka overtime pay calculator turns those extra hours into a number a manager can see, and a number is much harder to ignore than tired faces. If meetings are the thing eating your clock rate, our meeting planner helps you size the real cost of pulling everyone into a room.
🛠️ What this means for you
Whether you are a solo freelancer, a student joining your first team, or a founder running three people hot, the lesson scales down cleanly:
- Slack is not laziness. It is the buffer that lets you respond to crises and, paradoxically, ship faster overall.
- Change your vocabulary before you change your team. "Saturation" and "clock rate" open doors that "slow down" slams shut.
- Bring numbers. Even a rough DORA-style log on a spreadsheet beats a feeling. Managers act on evidence, not exhaustion.
- Protect the tank. A team with nothing in reserve cannot rise to a real emergency, and emergencies always come.
I think the deeper message is that sustainable pace is not a wellness perk. It is an engineering requirement, the same way you would never run a database server at 100% CPU and expect it to stay responsive. Treat your people with the same respect you give your infrastructure, and the velocity follows.