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.

An overhead view of a rowing team, showing five people, each rowing through the water.
You are no longer just a rower; you are the coxswain and a rower. Photo by Josh Calabrese / Unsplash


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.

Photo by Christina @ / Unsplash

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.

No matter how you get there, just keep moving. Photo by Jonathan Chng / Unsplash

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

Catch Up with the Previous Issue!

The Catch Block #28 - Being a Force Multiplier
Make your team better by being the first point of contact and knowing strengths and weaknesses.

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