Why some dev teams are fast
In an earlier post, I wrote about why your dev team might be so frustratingly slow. So here is the converse — for a team to move really fast, here are the essential, high-leverage thing that leaders can focus on:
The team is working on a limited number of things at once.
Almost all development teams are working on too many projects compared to their capacity. It is very likely that you do not actually know about all of the projects that are being done. The fastest way to speed up your team is to fix this. Make the work visible. Priortize the current projects. Stop many of them. And physically place yourself in the way of new projects, so nothing gets started until something is finished.
New ideas don’t interrupt current work
When I started working with one team, I found they were actually spending about 60% of their time discussing project requests and about 40% of their time on implementing solutions. It is necessary for the dev team to talk about the future. But it is also necessary to make sure the team is not interrupted by all kinds of people who want to discuss new ideas. Limit the number of future items that can be discussed at any time. Help the team mantain boundaries around interruptions.
Management allows them to finish projects
If every project is rushed, and the team is never given the time to do things right, they will slowly destroy their architecture and toolset. If the team is allowed to maintain the system they can speed up more and more over time. Give the team the time to leave the system better than it was before they started.
The team is staffed to allow them to complete features without dependencies
If they are in direct control of all the systems that need to be changed, a fast team doesn’t have to waste time convincing others to help them. They spend less time waiting and more time working. Also, if everyone is working full-time for the team, there is little or no internal waiting. If they are collocated they can communicate even more quickly. Create small, dedicated, collocated teams that own whole problems and the whole tech stack.
Projects in progress are killed when the economics change
It is easy to get excited about a prototype or an agile backlog of must-have stories. In early-stage startups, these things are key. But once your business is established, it is the 8o% of the work, the boring but necessary cases outside of the happy path, that makes a difference. If you pretend this work is not needed, it will seem like you can afford to do big things. You’ll start grand rewrite projects that seem to be going great until they appear to grind to a halt. Assume half of your projects are actually out of your price range. Don’t get tempted by a prototype or ‘MVP’. Ignore sunk cost and kill ideas that are now unaffordable. (Don’t kill the team at the same time!)
The product strategy is stable and realistic
If you are experiencing any of the above situations, it is likely that you have tried to solve them by ‘multi-tasking’ — moving individuals between projects or dicing projects into the backlog. Teams are delivering fruit salad rather than whole meals. Context-switching can happen at many levels — task, project, or even the strategic level. If your strategy is unstable or insufficient, you will yank teams or departments back and forth between orthogonal strategic goals and not achieve any of them. All projects will move very slowly. Be realistic about how many strategic goals you can do this year. If you are capacity-constrained, favor serial over parallel strategies.
—
You’ll notice all of the above are things under management control. This is good, because they can be fixed just by changing how you lead. The bad news is that if you’re experiencing these problems, your management culture needs to change.
Do not assume that you can simply blame a dysfunctional management layer between you and the teams. They are getting the signal to behave this way from somewhere. If you model the behavior of overload and context-switching and long hours, the team may just be following your lead.
Wishing they would also stay late is probably not the solution.
