I've been a lead developer for about six years now. During that time, I've had both very large teams (10+ other developers) and very small teams (1-2 other developer) working with me.

Seven people lined up, facing the camera, in the water. One of them has her eyes closed.
Oh COME ON Maritza, you blinked AGAIN! Photo by Duy Pham / Unsplash

These two extremes (the very large and the very small) require very different leadership styles. In this edition and the next, we'll talk about how to lead small teams; in later editions, we'll talk more about how to effectively lead larger teams.

What's a Lead Developer?

A lead developer, as I use the term, is someone who is in charge of projects but not people. They cannot hire/fire, though the manager may take their input on that decision. Rather, they guide projects through all lifecycle stages, from inception to obsolescence, delegating tasks to their teammates, making architectural decisions, and generally ensuring that the code their team writes is useful, readable, maintainable, and most importantly what the user wants.

You may be in a similar position at your job. If you are, the rest of the tips in this article will be useful to you.

Leading a Small Team

Small, agile teams are the ideal kind to tackle a single medium-to-large project. Each time I had a team of two or less other developers, I found that a few things were much, much easier than with large teams:

  • Communication is easier to facilitate. The less number of people that need to know something, the simpler it is to make sure the information gets to the people that need it.
  • You don't need to delegate as much. You still have to delegate some things, but not as often as with a larger team.
  • Because both communication and delegation take less of your time, you personally (as the lead) get to code more. This can be either good or bad, depending on your disposition. For me, this was great, since getting to code more made me feel like part of the programming team rather than a manager.

That said, small teams come with their own challenges. First and foremost among these is the bus factor.

Watch Out for the Bus Factor!

If you don't have a single large project your entire team works on, you are most likely dealing with several smaller projects. The problem that arises here is that it's too easy for a single person on your team to become the expert on any particular project. That person may then amass all the knowledge necessary to work on said app and probably get really, really good at solving problems in that project.

But what will you do if that person gets hit by a bus?

A city bus slows for a stop along a curb.
HOOOOOONNNNNKK!!! Photo by Hobi industri / Unsplash

Not literally, of course. But what happens if the single expert on an app your team is responsible for gets a better job, or retires, or quits?

Now you have a bunch of problems all at once, because all of that person's innate knowledge about the app leaves with them! You have to designate someone else to work on the app, and they will need time to become familiar with it, research problems, and learn what still needs to be done. No matter how good the new programmer is at programming in general, they will never be as fast as the expert programmer was at making improvements to this particular application, at least in the beginning.

This problem is called the "bus factor". If one of your teammates gets hits by a bus, how long will your team spend "ramping up" and getting familiar with that person's work?

Mitigating the Bus Factor

You can mitigate the bus factor in two ways.

First, try to make sure everyone on your team is at least familiar with the ideas behind each of your applications, even if they haven't directly worked on them. A few ways you can do this include:

  • Use extra meeting time to discuss changes requested by your customers to apps and why they are necessary.
  • Hold a lunch-and-learn so team members can familiarize themselves with apps they haven't worked on.  
  • Do a biweekly, once-an-iteration, or monthly meeting where you, as the lead, show off an app that one person is responsible for and point out where architectural or design decisions had to be made. The responsible developer can chime in with why these choices were used.

Obviously, nothing replaces the experience of working on these kinds of apps directly, but you can reduce the ramp-up time somewhat.

A cyclist does a trick off the top of a ramp.
This guy might be taking the "ramp up" thing a bit too literally. Photo by Leandro Riviello / Unsplash

This requires your team to have good communication skills, and for the team members to trust each other, things which I could spend entire series talking about. If you have those problems, you will have to fix them first before you can start mitigating the bus factor.

Second, if possible and if time allows, rotate projects. This will be difficult in a real-world environment; businesses are not big on allowing their developers to "waste" time getting familiar with a new app. But when feasible, have your teammates work on apps they are not familiar with; don't let them get stuck on maintaining a single app, because that's boring and no one wants a boring job.

By rotating developers across projects, you inherently promote cross-sharing of knowledge between the "expert" developer and the "newbie" developer for that app. In this way, if one of them gets metaphorically hit by a bus, the ramp-up time is much shorter because all of the innate knowledge did not disappear.

Every team will get hit by the metaphorical bus at some point. Unexpected illnesses, layoffs, people getting better jobs, all of these happen every day. We can't stop it, but we can mitigate its effects.

The bus is coming, but hitting it won't be catastrophic. We just need to be a little prepared.

Previews and Announcements

Quality Reads

Catch Up with the Previous Issue!

The Catch Block #22 - Technical Communication is Hard, Yo
Ever tried to explain “copy and paste” to a 10-year-old who has never heard those words?
Exception Not FoundMatthew Jones

Thanks for reading, and we'll see you next week!