This is a simple truth: if your team is running at full capacity, then the bottleneck that is holding them back is you. I’m going to take some time to try and outline why you’re holding your team back, and give a few clues on how you can maximize the team output.

Original Post on TeachingTechLeads.com

Setting Up the Scenario

Let’s say you have a team of 4 developers working on your project. There are 24 stories to implement, and using Little’s Law, we know that our team can complete a story every 12 hours.

You sit around in a meeting room and white board each and every story with the full team. You guys hash out basic patterns to implement and an enterprise messaging system that will keep all the pieces in constant, eventual, contact with each other.

Great!

The team heads back to their desks and is off to the races.

Around lunchtime the next day, you receive 2 pull requests. So, you start reading one, while the other devs twiddles their thumbs. About the time you finish the first pass on the first pull request, you are dragged off to a meeting.

When the meeting ends, there is a secondary response from the first developer on an open question you left on their pull request. And a brand new pull request in need of review from your third developer.

The fourth developer? They’re in the weeds and in desperate need a guiding hand.

You could head over to their desk, but at what cost?

The Math Behind It All

One developer running full steam at the rate of 1 story per 12 hours could complete this sprint of work in 32 work days.

That means the team of 4 should complete it in 8 work days. That’s a healthy two week sprint.

But that’s running at 100% efficiency. No downtime.

What about code review? What about a feedback loop around a refactoring that could strengthen your overall design?

Every time that you interject yourself into the equation, the numbers get pushed out. And not just for that one developer that you’re sitting down with, but for the whole team.

And don’t forget that you don’t work developer cycles anymore. A developer should be allowed a two hour window minimum to get into a good flow(I’ll find some research to back this up later). They can focus, they can put their heads down, they can get work done.

You keep management cycles now. You world is held together by 30 minute windows that may or may not be filled with meetings about something or other.

So, when you are needed, you may not be around. That developer with the question you could answer off the top of your head may be stuck waiting for an hour because you’re on a conference call where you’re needed for literally one 2 minute question and answer.

Because that developer was blocked, the rest of the queue is then pushed back.

How do you stop being the bottleneck?

Accept Your Constraint and Minimize It

You work with it and you work around it. You let your team help.

Here are some ways to keep things moving when you’re not there to intervene yourself.

Staggered Stories

Don’t start everyone out of the gates at the same time.

The best part about a continuous discovery/requirements gathering paradigm is that you always have work to do. When you run out of work, there’s a good chance that some more will appear in the backlog.

If you have a free developer, they are free to start looking in to any spikes or any technology questions you have about the new feature in the next sprint.

Individual Design Sessions

Sit down and do your design sessions with the singular/group of developers for a particular feature. As work comes up, sit down with the assignee and start blueprinting how to implement it. This isn’t the session that you and the architect had where you make broad gestures towards abstract notions.

This is putting names to services and defining the contracts.

This is drawing out the entities and the tables that will contain them.

The more the developer knows about the design, the less questions they’ll have during implementation. The less questionable code there is during implementation, the faster the code review will go. You two already decided on the implementation, the code review will be a cake walk.

Now, I’m not pushing for siloed development. Yes, this one developer will know this portion of the code better than their peers, but there’s a way to make sure that the knowledge is spread. Which is…

Peer Code Reviews

If you’re not there, have another team member read the code. This allows for someone else to be immersed in the code that they had no hand in creating. They will gain knowledge and subject matter expertise, while providing valuable insight that a second(third) set of eyes can provide.

In a project where I was leading over 7 different developers, I instilled a rule that each pull request needed the approval of a peer before I would look at it. This was because A) I was having a lot of trouble keeping up with all the code reviews and B) I knew that the first peer review would catch all the small things that I would have rejected the review for anyway.

Real Time Communications

In my current team, we have a rule. If you cannot figure something out within 20 minutes, you raise your hand. This is usually in the form of someone standing up and exhaling very loudly.

Worst case scenario, it is dropping a call for help into our team chat channel. This is broadcast to the whole team, including the leads and the architect. As long as they are actually looking at their chat notifications…

There needs to be a near immediate channel of communication between the team members. If there is not, then you are all boats adrift in the dark.

Say No to Meetings

This should be its own topic. But, you are not needed in every meeting you are invited to. I go to about half of the meetings that are proposed on my calendar. There are better uses of my time and if there is something that is needed of me, I should be able to tell from the agenda that should have been attached to the meeting invite.

Just learn to say no, politely.

In Conclusion

It’s tough, I know. The realization itself is the worst part. Every 30 minutes that you are stuck in a meeting when someone is waiting on you, you are blocking at least one developer from efficiently using their time.

You need to provide yourself ways to work around this restriction. Accept that the best use of your time is to enable your team. That’s what it means to lead, to make everyone else better.

If you have streamlined the process of getting work delegated to your developers, then you should be the bottleneck. That’s great! It means that the system is working. They are able to work without interruption and produce amazing code.

This means that they can do their job and you can get back to yours, which is to enable them and to progress the project towards completion.

Are there any other tricks you folks use to enable your team? I'd love to hear them below!