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.
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.
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.
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
- Introducing the Half type! (Prashanth Govindarajan)
- Designing a User Experience for Now While Planning For the Future (Joe DeVito) - Even if your job does not include designing user experiences, knowing how other people might do makes us better developers.
- An Introduction to Kubernetes - Deploying ASP.NET Core applications to Kubernetes - Part 1 (Andrew Lock)
- CodeTour and Visual Studio Code (Jeremy Bytes)
- Super Simple GraphQL Tutorial with C# (Giorgi Dalakishvili) - Really want to learn about GraphQL sometime, might as well start now.
- Solution & Project Structure of a Loosely Coupled Monolith (Derek Comartin)
- 3 Things I Learned About Sharing Big Ideas Better (JD Meier)
- Leadership in the age of remote work (Mangalam Nandakumar)
- Stupidity can be a plus in corporations — but not in software development (Jessica Kerr)
- Optimizing a Blazor WebAssembly application size (Gérald Barré)
Catch Up with the Previous Issue!
Thanks for reading, and we'll see you next week with tips on how to lead large development teams!