The engineering lead was frustrated. "I don't understand it," he told me. "We have smart people. We have good people. But nothing gets done."
I spent a week observing. What I found wasn't a team problem. It was a system problem.
The team was spending four hours a day in meetings. They had no clear priorities—everything was "priority one." Their deployment process required manual sign-offs from three different people. They were interrupted constantly by support tickets.
No amount of "trying harder" would fix that. The system was designed to be slow. And nobody had noticed.
Quick Takeaways
Fixing Slow Engineering Teams
✓ Root causes: Process (too many approvals/meetings), Context (complex codebase), Priority (unclear/fighting), Tooling (infrastructure fights)
✓ Meeting audit: Track time in meetings vs coding—aim for 80%+ maker time
✓ Priority clarity: One priority at a time, everything else waits
✓ Deployment friction: Automate everything—one-click deploys, no manual sign-offs
✓ Technical debt: Allocate 20% of sprint to refactoring—pay it down continuously
✓ Interruption protection: Async support, focused work blocks, fewer Slack channels
The Diagnosis
Before you can fix a slow team, you need to understand why they're slow.
Is it process? Are there too many approvals, too many meetings, too many steps between idea and deployment?
Is it context? Is the codebase so complex that every change takes longer to understand than to implement?
Is it priority? Is the team pulled in too many directions, working on too many things, never able to focus?
Is it tooling? Do they spend more time fighting infrastructure than building features?
Most slow teams have some combination of all four. The good news is that all of these are fixable without replacing anyone.
The Process Fix
I've never seen a startup where process couldn't be simplified.
A team that needs six approvals to deploy a change will deploy less often. A team that has daily hour-long meetings will have less time to work. A team that requires sign-off from multiple stakeholders will move slower than a team that has clear ownership.
The solution isn't to eliminate all process. It's to eliminate process that doesn't add value.
A good rule of thumb: every process should have a clear purpose. If you can't articulate why a process exists, it probably shouldn't.
The Priority Fix
When everything is a priority, nothing is a priority.
I've watched teams spend their days in a state of constant reactivity. Something urgent pops up. They drop what they're doing to handle it. Something else urgent pops up. They switch again.
At the end of the day, they've handled a dozen urgent things and made zero progress on anything that matters.
The solution is radical focus. Pick the two or three things that actually matter. Ignore everything else until those things are done.
This is harder than it sounds. Urgent things feel important. They demand attention. But urgent and important are different categories, and the best teams learn to distinguish them.
The Context Fix
Some teams are slow because they can't find anything.
"Where's the API documentation?"
"Who wrote this code?"
"Has anyone solved this problem before?"
Every minute spent searching is a minute not spent building.
The solution is investment in discoverability. Documentation that gets read. Code organization that makes sense. Knowledge sharing that actually happens.
This isn't glamorous work. But it's the difference between a team that can find what they need and a team that can't.
The Tooling Fix
Some teams are slow because their tools are fighting them.
A deployment process that takes an hour. A testing suite that takes two hours to run. A local environment that takes a day to set up.
Each of these is a tax on productivity. And like any tax, it adds up.
The solution is investment in developer experience. Make it easy to deploy. Make it fast to test. Make it simple to get started.
This might not be "product work," but it enables product work. And it's almost always worth the investment.
The Pattern
Here's what I've noticed: slow teams aren't broken. They're burdened.
They have too much process. Too many priorities. Too much complexity. Too many tool problems.
The solution isn't to work harder. It's to remove the burdens. Make it easier to do the right thing. Make it harder to do the wrong thing.
Remove the meetings. Simplify the process. Focus the priorities. Fix the tooling.
And suddenly, the same team is fast.
The Leader's Role
Fixing a slow team starts with the leader.
Leaders create systems. If the system is slow, the leader created that system (or allowed it to exist).
Leaders set priorities. If priorities are unclear, the leader made them unclear.
Leaders invest in tooling. If tools are broken, the leader hasn't prioritized fixing them.
The leader who wants a faster team needs to look in the mirror first. The problem isn't the team. The problem is the system the team operates in.
The Bottom Line
Before you fire anyone, try fixing the system.
Most teams are faster than their systems allow them to be. Remove the friction. Clarify the priorities. Invest in the tools.
And watch what happens.
FAQ
Q: How do I convince my team to change our slow processes?
A: Start with data, not opinions. Track time spent in meetings vs coding for one week. Show the team the numbers. Most developers are frustrated by slow processes—they just need permission to change them. Run a one-week experiment: cancel all non-essential meetings, protect maker time, and measure velocity improvement. Results speak louder than arguments.
Q: What if leadership won't let me reduce meetings or approvals?
A: Escalate with data. Calculate the cost: 5 developers × 20 hours of meetings/month × $100/hour = $10K/month in meeting time. Show leadership what features could ship with that time instead. Propose a trial: reduce meetings for one sprint and measure results. If velocity improves, you have evidence. If it doesn't, you learned something.
Q: How quickly can we expect to see improvements?
A: Some changes show immediate impact: reducing meetings, clarifying priorities, protecting focus time—teams feel these within days. Technical debt reduction takes longer: 2-4 weeks to see real velocity gains from refactoring. Tooling improvements vary: better CI/CD shows impact in days, new frameworks might take weeks. Measure everything and celebrate small wins to build momentum.
Q: Should we stop all meetings to fix velocity?
A: No—meetings serve purposes. The problem is unnecessary meetings and meeting overload. Keep: (1) Brief daily standups (if useful), (2) Weekly planning with clear priorities, (3) Monthly retrospectives with action items. Cut: Status meetings, meetings without agendas, recurring meetings out of habit, meetings that could be async updates. Goal: 80%+ maker time, not 100%.
Q: What if the problem is actually the people, not the system?
A: Be honest: sometimes people are the problem. But exhaust system fixes first—80% of "people problems" are actually system problems. If after fixing systems, specific individuals still underperform: (1) Have direct conversations about expectations, (2) Provide specific feedback and coaching, (3) Set clear improvement goals with timelines. Termination should be a last resort after genuine attempts to help people succeed.
Q: How do we balance fixing technical debt vs shipping features?
A: Allocate 20% of every sprint to debt reduction. This is non-negotiable—like paying interest on a loan. If you don't, debt compounds and velocity collapses. During planning: identify 1-2 high-impact refactorings that enable future features. Frame debt work as enabling speed, not preventing features. When stakeholders push back, show them historical velocity charts correlating with debt levels.
References
-
DeMarco, T. & Lister, T. (2013). Peopleware: Productive Projects and Teams (3rd ed.). Addison-Wesley.
-
Kim, G. et al. (2018). Accelerate: The Science of Lean Software and DevOps. IT Revolution Press.
-
Brooks, F. (1995). The Mythical Man-Month: Essays on Software Engineering. Addison-Wesley.
-
Fournier, C. (2017). The Manager's Path: A Guide for Tech Leaders Navigating Growth and Change. O'Reilly Media.
-
Pichler, R. (2010). Agile Product Management with Scrum: Creating Products that Customers Love. Addison-Wesley.
-
Lencioni, P. (2002). The Five Dysfunctions of a Team: A Leadership Fable. Jossey-Bass.
-
Newman, S. (2021). Building Microservices: Designing Fine-Grained Systems (2nd ed.). O'Reilly Media.
Related Reading
- When 'Just Hire More Developers' Is Wrong Advice — Why adding people often backfires
- Why Engineering Velocity Matters More Than Headcount — Focus on speed, not team size
- Why Agile Fails for Many Startups — Process that actually works
- Tools Tech Teams Use to Ship Faster — Technology for velocity
- Technical Debt: When It's Fine, When It's Dangerous — Managing debt strategically
Need Help Unblocking Your Team?
At Startupbricks, we help startups identify and remove the friction that's slowing them down. If your team feels faster than it should, let's talk.