Large teams present unique challenges for developers with a leadership role. In this edition of The Catch Block as well as the next several, we're going to discuss ways to effectively lead a large team of developers, starting with two ideas: you cannot know others without knowing yourself, and you must be ready to step in for anyone. Don't worry, it's not as daunting as it seems.

Developer, Know Thyself

The single biggest way to be an effective leader of a large team (of any team, really) is to know and understand the strengths and weaknesses of each person on the team. What they don't tell you is: that includes you.

A woman gestures toward the camera, with he face and hand obscured by a long-frond plant.
Thanks for the reminder, creepy jungle lady. Photo by Dev Asangbam / Unsplash

You need to be honest with yourself about what you're good at, what you're bad at, what you like doing and what you hate doing. You need to know yourself before you can know other people.

Ask yourself: do I really like front-end, or middle-tier, or back-end work? Do databases crumble before me, or do my user interfaces kick ass?  What do I like to do, and what am I good at? Honesty is key when answering these kinds of questions.

Once you know what you like and are good at, here's the kicker: don't assign that stuff to you.

As leaders, part of our responsibility is assigning tasks and projects to our teammates. We decide what they need to do next. To be frank, it is all too easy to take all the good stuff and give it to yourself. It's a perk of the position, and it's OK to do this sometimes. But if you're taking all the fun work all the time, you are failing your team, and more importantly, failing yourself.

Be Ready to Step In

Programming teams are sometimes likened to film crews: each person has a distinct job, the jobs are not usually interchangeable, and we need all of them to get the movie made. The problem with this analogy is that it doesn't acknowledge the real world, because in the real world, people get sick, people leave jobs, and the projects still need to go on. The movie doesn't stop getting made because the gaffer left; someone needs to step in and do that job.

Your job as a leader is to ensure that the work gets done, no matter who needs to do it. That means that if no one has the ability to complete a particular task or work on a given project, it's up to you to complete the task, build the interface, research the new technology, or whatever the task is.

If possible, you can delegate that work to someone who you trust will do it right. But that's not always feasible, and there will be times when no one on your team fits the bill. When that happens, it's now your job.

A baby points and smiles at the camera, while his mother looks on from the background.
Now the baby's getting in on the act. Photo by 🇻🇪 Jose G. Ortega Castro 🇲🇽 / Unsplash

This may seem like a weird tact to use, the whole don't-assign-stuff-you-like-to-yourself thing, but it's not, and hopefully you can see why: you need to be able to fill in for anyone on your team. Even if you're not as adept as the original person is at this particular task, having someone with at least a passing familiarity with the topic at hand ensures that the project can keep going, with as little disruption as possible.

As we'll see in the next few issues of The Catch Block, your job as a lead is mostly about causing as little disruption as possible, and removing the things that might be disruptive.

Previews and Announcements

Quality Reads

Catch Up with the Previous Issue!

The Catch Block #25 - A New Mega Series is Coming!
It’ll be titled “C# in Simple Terms.” Plus habits, how not to hate Javascript, Postel’s Law, and Blazor goodness.

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