Continuing our series from last week, let's see some more tips about how to lead small software development teams.

Tips for Leading Small Teams

Being in charge of a small team is the ideal situation for a new team lead, because there's less pressure and less change they need to go through. They can contribute directly (through code) and indirectly (through decision-making and leadership). The indirect contributions often end up as more of a struggle, though.

See, there are two main ways to kill a project, and they both can be caused by the lead and their indirect contributions.

Make Decisions Quickly

The best thing about a small team, as mentioned in the previous issue, is that a small team can adapt quickly to problems or new requirements in their project. However, a small team must also make decisions quickly, and guess who these decisions fall to? That's right, you, the lead developer.

Forking forest path
Eeny, meanie, miney, moe... Photo by Jens Lelie / Unsplash

Decisions range from minor (what code formatting style do we use?) to huge and impactful (which frameworks will we use?). Making these decisions quickly is a benefit to our team, because it allows them to get on working without waiting around.

Please note: we don't want to make these decisions on a whim. We do need to gather information, do some research, ask people, whatever we require in order to make a decision. But when the time comes, we need to actually make a decision.

There are two ways to kill a project: through inaction, and through action. Failing to make a timely decision is killing a project through inaction, because while everyone is waiting on us to decide, work that could be getting done if the decision had already been made is instead languishing.

There will be situations in which we have done all the necessary research, talked to all the right people, gathered everything we can get about the options available to us, and we might still be unable to decide which option is the best fit for us. This situation is called analysis paralysis and the longer a project is in this state, the more likely it is to fail. If this happens, often we are better off just flipping a coin and doing whatever the coin says.

So, if analysis paralysis happens to you, do exactly that: flip a coin.

Photo by Virgil Cayasa / Unsplash

Sometimes we need to make a decision just to get out of our team's way. Go with your gut and whatever your research tells you, but if that fails, just flip a coin and be done with it. If you've reached this point and done the research, neither option will be bad; they'll just be different.

Stay Out of the Way

It is important to make decisions in a timely manner. But it's also just as important to not make decisions that don't require a lead's input. A temptation for a lot of new team leads is to insert themselves into situations that do not actually require their decision-making.

Trays of Baked Goods
A little temptation can't be a bad thing, can it? (gains 20 pounds) Photo by Greta Punch / Unsplash

Let's be real: being a team lead means having less direct contributions to the codebase. This is not a bad thing; in fact I'd argue that it is required of the position. But it's easy to feel like we're no longer contributing as much as we used to towards the success of the project, and this purported lack of contribution can impel a new lead to attempt to contribute in other ways.

Ways like deciding that the app needs a new feature that "the customer will absolutely love" without actually talking to them. Ways like upgrading to a new version of our frameworks without knowing if the upgrade is difficult, necessary, or both. Ways like adding more and more tests aiming for more coverage without investigating to see if that is useful. Ways like telling your teammates exactly what to do even though they are perfectly capable of doing it themselves. Ways in which a lead can sink a project. These decisions are all within our power to make.

As lead developers, we have a responsibility to ensure the project goes as smoothly as possible within the constraints (time, technology, customer demands, etc.) that we have. The easiest way to screw up a project is to make changes that are a) not researched, b) not easy, or c) not desired by the customer, or some combination thereof.

So don't trip. Don't make changes hastily. Don't change things that do not need to be changed, or that you cannot justify. Be mindful of the impact that the changes you do make will have. It's easy to sink a project with lots of little unnecessary decisions; you don't want to end up in this situation. Stay out of the way, let your team work, and the project will get along just fine.

Previews and Announcements

Quality Reads

Catch Up with the Previous Issue!

The Catch Block #23 - Mitigating the Bus Factor
Don’t let the metaphorical bus cause a disaster on your software team!
Exception Not FoundMatthew Jones

Thanks for reading, and we'll see you next week with tips on how to lead large development teams!