There’s a strange thing that can happen inside a growing software organization.
Everyone is busy.
Developers have full backlogs. Product has more requests than it can prioritize. Support tickets keep coming. Meetings fill the calendar. Releases happen. Bugs get fixed. Customers get answers.
From the outside, the organization looks incredibly productive.
But then someone asks a deceptively simple question:
“What have we actually improved?”
And sometimes the answer is surprisingly difficult.
That’s because being busy and moving forward are not the same thing.
When 100% Capacity Produces Very Little Capacity
Most organizations want their people fully utilized. On paper, that makes sense. If you’re paying for an engineering team, why wouldn’t you want them working at capacity?
The problem is what happens when every available hour is already committed.
A production issue appears. Something moves.
A major customer escalates a request. Something else moves.
Sales needs functionality for an opportunity. Move something again.
A security issue needs attention. Another priority changes.
Pretty soon the roadmap isn’t really a roadmap anymore. It’s a constantly rearranging list of whatever is most urgent today.
The team may technically be at 100% utilization, but it has almost 0% flexibility.
And software organizations without flexibility eventually become reactive organizations.
Firefighting Feels Productive
There’s something deceptive about firefighting: it feels incredibly productive.
A critical issue comes in. People jump on a call. Developers investigate. Someone finds the problem. A fix gets deployed. Everyone celebrates.
Problem solved.
And they should. Solving production problems matters.
But if the same team spends week after week responding to emergencies, customer escalations, defects, and operational problems, something important is being crowded out.
The work that prevents tomorrow’s emergencies.
- Refactoring.
- Automation.
- Testing.
- Monitoring.
- Documentation.
- Architecture improvements.
- Developer tooling.
- Removing obsolete code.
- Simplifying complicated workflows.
None of those things usually arrive marked URGENT.
So they keep getting pushed to next sprint.
- Then next month.
- Then next quarter.
Eventually, “we’ll get to that later” becomes part of the architecture.
The Roadmap Slowly Changes
Healthy product roadmaps contain a balance of work.
There are customer capabilities, strategic investments, technical improvements, operational work, and sometimes experiments that may not produce immediate revenue but help determine where the product goes next.
- Reactive organizations gradually lose that balance.
- The roadmap becomes dominated by tactical work.
- What does Customer A need?
- What broke yesterday?
- What did Sales promise?
- What needs to ship before the next renewal?
- What problem is Support escalating?
All of those can be legitimate priorities.
But if everything is urgent, strategy eventually becomes whatever survives the interruptions.
That’s not really strategy.
It’s triage.
Deployment Anxiety Is a Warning Sign
Another symptom appears when teams become nervous about releasing software.
You hear things like:
- “Let’s wait until Monday.”
- “Who else needs to be online when we deploy this?”
- “Do we know what else this might affect?”
- Or my personal favorite:
- “Don’t touch that.”
Some caution around production systems is healthy. Nobody wants developers recklessly deploying changes.
But fear is different from discipline.
If routine changes require heroic coordination because nobody completely understands what might break, the organization has accumulated risk faster than it has accumulated confidence.
- Eventually that affects velocity.
- Changes get smaller.
- Release cycles get longer.
- Innovation slows.
And the organization begins protecting the existing system instead of improving it.
Your Best Developers Often Become the Bottleneck
There’s another pattern I’ve seen repeatedly.
As systems become more complicated, institutional knowledge concentrates around a handful of experienced people.
- Everyone knows who they are.
- When something strange happens, call Sarah.
- Before changing that module, ask John.
- Nobody deploys that service unless Mike is available.
- At first, those people look incredibly valuable — and they are.
- But the organization has also created a dangerous dependency.
- Your strongest engineers gradually become human routing tables for the platform.
- Instead of designing what comes next, they spend their time explaining what already exists.
- Instead of mentoring and improving architecture, they get pulled into every production problem.
- The better they are at solving emergencies, the more emergencies they receive.
Expertise becomes a bottleneck instead of a force multiplier.
New Developers Tell You More Than You Think
One of the best indicators of platform maturity is what happens when a new developer joins the team.
How long does it take before that person can safely make a meaningful contribution?
- A few days?
- A few weeks?
- Several months?
- Do they have documentation?
- Automated tests?
- Repeatable development environments?
- Clear architectural patterns?
- Or does onboarding consist mostly of someone saying:
- “Sit with me and I’ll explain how all of this works.”
- Complex systems naturally require time to learn. That isn’t necessarily a problem.
- But when knowledge exists primarily in people instead of systems, documentation, standards, and automation, growth becomes increasingly difficult.
- Every new developer requires more time from the developers who are already overloaded.
Now the very people you hired to increase capacity initially reduce capacity.
Modernization Cannot Be Leftover Work
This is where leadership has to make an intentional decision.
If modernization only happens when engineering “has some extra time,” it probably isn’t going to happen.
- There is always another feature.
- Another customer.
- Another bug.
- Another deadline.
- Another escalation.
Healthy organizations deliberately reserve engineering capacity for improving the platform itself.
That percentage doesn’t have to be the same for every company or every quarter. Sometimes business conditions legitimately require nearly everyone to focus on a major delivery.
But modernization needs to exist as a real priority rather than a hopeful future activity.
You cannot continuously withdraw from the technical health of a platform without eventually making deposits.
The Customer May Never See the Most Important Work
This can be difficult because some of the most valuable engineering work produces almost nothing visible to the customer.
- Customers don't necessarily see improved CI/CD pipelines.
- They don't see automated regression testing.
- They don't see refactored architecture.
- They don't see better observability.
- They don't see standardized development patterns.
- What they eventually see is the result.
- Fewer outages.
- Faster releases.
- More predictable delivery.
- Better performance.
- Fewer regressions.
And a product that can evolve without everyone holding their breath every time something changes.
That is why technical health is ultimately a product concern and a business concern, not simply an engineering concern.
Stop Measuring Productivity by How Full the Backlog Is
A full backlog doesn't tell me that an engineering organization is healthy.
- Neither does a calendar full of meetings.
- Neither does the number of tickets closed.
- Neither does having every developer allocated at 100%.
- Those things measure activity.
- Leadership needs to look beyond activity and ask whether the organization is actually increasing its ability to deliver.
- Are releases becoming easier or harder?
- Are developers spending more or less time firefighting?
- Is onboarding getting faster?
- Are recurring problems being eliminated or repeatedly fixed?
- How much engineering capacity goes toward innovation versus maintenance?
- Are we reducing complexity or simply learning to tolerate more of it?
Those questions tell us much more about the direction of the organization.
Leave Room to Move Forward
High-performing engineering organizations absolutely work hard.
- But they also create room to think.
- Room to improve.
- Room to automate.
- Room to refactor.
- Room to experiment.
And occasionally, room to question why something has been done the same way for the last ten years.
A team running at 100% capacity all the time isn't necessarily operating efficiently. It may simply have no room left to become more efficient.
The goal shouldn't be to keep engineering as busy as possible.
The goal should be to create an engineering organization capable of continuously delivering value while making the platform easier — not harder — to change tomorrow.
Because ultimately, the question isn't:
“Is everyone busy?”
It's:
“Are we moving the product forward?”
Thanks,
Michael Cronin
Website: https://www.michaelcronin.info
LinkedIn: https://www.linkedin.com/in/michaeltcronin/details/experience/
