The simple fact of the matter is this: once you become a lead developer, you will code less than you have so far in your career. At that point, your job is no longer about writing the best code, it is about ensuring your teammates can write their best code through the technique of delegation.
Delegating tasks effectively is an art, one that takes time and failure to learn. But there are still a few commonly-accepted ways to delegate, and in this post, we're going to discuss them.
Delegate!
Delegation is a critical ability for lead developers to have. The reason why we are mentioning it so late in this series is that it takes many of the previous skills (time management, vision, knowing strengths and weaknesses, etc.) to be able to delegate effectively.
When you are the lead of a project, it's easy to feel like it all falls on your shoulders. In some ways it does, but more often it doesn't, at least not in the way it feels like. It's your project, but most modern software applications cannot be coded by a single individual in the time allowed. You are going to need help, and effective, deliberate delegation is how you get it.
You will need to learn how to delegate tasks to the right individual so they can get them done. Along with knowing their strengths and weaknesses and delegating according to them, which we discussed last week, you should also keep in mind a few other things.
First, it's important to delegate early. Nothing sucks more, as a team member, than being given an task and told you have not enough time to complete it in. As soon as you know you need to delegate a task, get to work figuring out who would be best suited to complete it, and get it in front of them. Don't stress trying to select the "perfect person" or the "person who would benefit the most from doing this;" these are good starting points, but we cannot always live up to them. Go with your gut and pick the person you feel is right for the job.
Second, when defining a task that someone else will do, you need to set clear, easily-defined goals for it. Tell your teammate exactly what the result of the task should be, but not how to get to that result; the latter is for them to figure out. Outline the rationale of why this needs to be done, what the benefit is, and why the customer wants it. Without clear goals and rationale, the task becomes a sort of guessing game of "what did they really mean when they said X" and that just wastes everyone's time.
Third, once you hand over the task to your teammate, don't just step back. Take a personal interest in the completion of the task, as much as time allows. Let your teammate know that you want this done, you want them to learn something, and that you are confident in their abilities. One of the great motivators is the freedom to accomplish something within your own bounds; let them know they have this freedom and they will get the task done well, often in ways that surprise you.
Delegation, like many of the skills necessary to be an effective lead developer, is more art than science, and you're bound to screw something up in the early going. The point is to keep going. Make mistakes, learn from them, do things better next time.
Next week will be the last issue of the Leading Teams mini-series. In it, we will discuss steps we can take to fulfill a large part of the job of lead developer: being a better mentor.
Quality Reads
- Exploring your .NET applications with dotnet-monitor (Scott Hanselman) - Scott keeps turning out quality posts.
- Hacking Grindr Accounts with Copy and Paste (Troy Hunt) - Another very cool post from Troy about a very scary bug.
- What the "No-Code" Movement Means for Software Developers (Karl Hughes) - This is a pretty speculative article, but I link it here for the primary reason that it does a good job explaining the "no-code" movement and why we shouldn't be terribly concerned about it.
- Reading Code is a Skill (Trisha Gee) - One that we need to practice. Read other people's code, people! Also, we need to be able to write readable code, and these two skills (reading code and writing readable code) are not mutually exclusive.
- When does Blazor decide to render your UI? (Jon Hilton) - AKA why the method StateHasChanged() exists in Blazor.
- On The Virtues Of Being Emotionally Attached To Your Code (Ben Nadel) - I actually disagree with one of the central assertions of this piece: that when users are using software I (as a developer) wrote, "they aren't experiencing the software - they are experiencing me." That said, it's always a good idea to read pieces with views opposed to your own once in a while.
- Calculate the Moon Phase With C# (Khalid Abuhakmeh) - This is a great example of "things I didn't realize we could do with C#".
Catch Up with the Previous Issue!
Matthew Jones
Thanks for reading, and we'll see you next week!
