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.
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.
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
- Announcing .NET 5.0 RC 1 (Richard Lander)
- Free e-book: Blazor for ASP.NET Web Forms Developers (Nish Anil)
Quality Reads
- How We Ended up with Git (Dino Esposito)
- Mistakes I Made When Learning to Code – and How to Avoid Them (Fredrik Strand Oseberg)
- Aircraft Carriers and Paper Airplanes (Jessica Kerr)
- Unit Testing in TypeScript Code (Rachel Appel)
- "await Task.WhenAll" Shows One Exception - Here's How to See Them All (Jeremy Bytes)
- Is Entity Framework Core Quicker than Dapper? (David Grace)
- Being A Better Ally (David O'Regan)
- We need young programmers; we need old programmers (Mark Seemann)
Catch Up with the Previous Issue!
Thanks for reading, and we'll see you next week!