Delegation As a Developer: Building the Next You

Delegation As a Developer: Building the Next You

Note: I originally wrote this post for the nDepend blog, here is the original post. 

“I love me some me!”  

Yes, there’s more than just an ounce of truth in that statement said by the great NFL receiver Terrell Owens.  Terrell loved some Terrell. In fact, if you knew one thing about the man, it’s that he loved himself. Most of us can hide it a little bit better than Terrell, but we’ve all been guilty of this sentiment at one time or another. We suffer from pride and do our best to counteract it with humility.  I’ll admit it—as a software developer after I write a solid, beautiful piece of code, my pride gets a first-class ride on the ego train!

Why start an article about delegation with an eccentric statement about ego?  The truth is we’re all good at what we do.  We spend time honing our craft, studying our industry, and trying to better ourselves.  Eventually, through experience, we’re able to understand and execute on things that less senior developers just can’t.  Our peers and managers recognize this, so we begin the journey to the role of leader.  And that leadership role doesn’t just entail learning all of the new frameworks and extensions. It also means learning a new set of skills.  One of those skills is delegation.

The Quandary of Leadership

When I was first recognized as a leader on my team, the recognition was extremely rewarding.  I had worked hard as a developer on this team and naturally stepped into some very minor leadership roles along the way.  I was honored to be selected as the team lead, and soon the team was coming to me for direction while the boss was looking to me for updates on how the team was performing.  

Rather quickly, I found myself thrust into a lonely middle ground. Management expected me to keep my team on task, and I was also trying to meet my standard deliverables.  It was obvious that keeping the team running and efficient required some new skills, and these skills weren’t the kind of things I could obtain by entering commands on my keyboard and getting results.  

These were skills that required—gulp—talking to people and finding out what makes them tick. Oh, and guess what? These skills had no tangible output. There was no rewarding pull request with a peer review after finding out that Jack needs a little more help with CSS and could use some training there.  There was no successful build notification after discovering that Diane had some issues going on at home and it was starting to impact her work output.  While I spent time building relationships with my team members, guess what I was NOT doing?  Producing!

All my career to this point was spent producing. Talking and relationships were a side gig that never got much attention, but they unknowingly got me much further along in my career than I like to admit.  I always liked to think that I would be promoted on technical merit, but it seems that managers are always looking for the next manager, and the technical merit is just expected.  

This transition from producer to leader presented me with a new skill set to learn and start putting into practice.  

Does Delegation Pay?

Angular 4, C# 8.0, progressive web apps, AWS…oh my, oh my.  These are all things I need to understand well and want to dive into with some hands-on learning.  How and why should I find time to learn about delegation?  What’s the payoff?

Further Your Career and Skill Set

Delegation is one of the skills that all managers and directors, as well as team leads, must learn.  Developers are a unique bunch of workers who have the ability to produce tangible goods (software) in the comfort and convenience of their own homes, with a laptop.  Whether you want to climb the corporate ladder or set a different career path, being able to lead people is a skill that will prove its value.  There are pathways up the corporate ladder for the solo technologist, but your technical influence will outpace your power to make actual decisions.  

Work On What You Want

When you become a leader, you get more control over the direction of your team, but you also gain some valuable control over what you’ll work on.  You may have the opportunity to delegate some of the tasks you don’t find challenging to your team so you can focus in on what you’re best suited to work on.

Better the Community

Delegation has the added benefit of allowing you to pass on your experience. When you give some of your responsibility away to your team members, you’re bettering them and making them stronger contributors.  It can and should be rewarding watching your teammates become better developers and more effective leaders themselves.  Like Yoda said to Luke Skywalker in The Last Jedi, “We are what they grow beyond.” When you delegate, you’re effectively mentoring.

Delegate to Scale

Finally, you delegate to scale.  Many team leads take on the most important development tasks and, in the process, become a blocker to progress.  It’s easy to fall into this control trap because we’re generally very good at what we do.  Perhaps we just don’t have confidence that a team member can execute on this task as well as we could.  Sound familiar?  If we avoid these traps, our team gets better through delegation, and we in effect scale upward.

The craft of delegation is often times directly opposite to what we have done in our careers that have led to success.  This was my biggest challenge as I took on more and more responsibility as a lead developer.  I was used to having a list of tasks that had to get done, and I took great pleasure in marking those things complete.  In order to break through the glass ceiling of how much I can get done in a day, I was forced to begin letting go of a little bit of control and delegating the work.

Delegation Basics:  A Team Of Yous?

Delegation would be wonderful if I could have a team of mes.  I know what makes Rick tick, what motivates him to get his work done, and what might trip him up.  I know his skill set, where he shines in the stack, and where he might need some additional training.  But since there are no cloning devices (yet), we need to delegate to people we don’t know as well as we know ourselves. So, with that, let’s think about it. How do you scale you?

Know the Players

I’ve found that knowing my team members is truly the first step.  Ideally, you know your team members well before your project starts.  The reality is that you’ll be put into this position amidst other deliverables—perhaps other project work.  You’re going to have to carve out time to start getting to know your teammates and what brings them to life.  In my experience, a regular 15-30-minute one-on-one weekly meeting will get you there the fastest.  After you have a solid base, understanding everyone’s skill set well, you can scale back. But soon your team will really rely on these chances to communicate with you one on one.

Pitfall:  At times, you’ll be tempted to cancel this meeting!  Trust me, I know.  You’ll be thinking of how you could use this time to get actual work done.  DON’T CANCEL!  Keep the meeting and try to learn something new about this person.

Pitfall:  No one gets to level set by knowing the players before they can start delegating tasks to them.  Work can’t stop because you don’t know your team, which means you may not do this well at first.  Stick with the process, and as you get to know your team, delegation will become easier.

Pitfall:  Sometimes we can build the next version of ourselves, but sometimes we just have to delegate tasks and make sure the work gets done.  Know your team members and what they aspire to.

Understand the Tasks

Look at the tasks you have on your plate.  Think about the ones most important, that you personally need to get done.  Then, think about some smaller tasks you could delegate to a team member.  These could be tasks that don’t require your expertise but could be done with just a little bit of input from you.  A great way to encourage your team member is to give them some slam-dunk tasks.  Let them taste the success of accomplishing a more senior-level task!

Pitfall:  The small task you just delegated to your team member might actually be a big task for them.  When a leader asks you to do something, that will often jump to the top of a priority list. Don’t lose sight of this priority change as you pass this task on.

Now Delegate

Delegation of the task itself can follow many patterns.  One pattern that has worked well for me at work (and in life with my own kids) is

  • I do, you watch, we discuss
  • You do, I watch, we discuss
  • You do, we discuss

This pattern can feel slow and too deliberate, but it allows proper expectations to be set and gives three opportunities for learning.  Whatever pattern you choose to use, keep it consistent.  Your team members can appreciate process and predictability!

Pitfall:  Do not omit the “we discuss” portion of the process.  This is your best teaching opportunity!

Pitfall:  Delegation failures are most often failures of the delegator.  Expectations need to be communicated, and some autonomy must also exist.  Your team members are not robots but human beings.

Perfection or Progress?

If you’re interested in further reading, the internets are full of articles about delegation, how to succeed at it, and how difficult it can be.  I really enjoy listening to the Manager Tools podcasts and articles.  They do a great job teaching this stuff, and they do so with the perspective that a boatload of experience provides.  No doubt, once you start practicing delegation, you’ll understand its challenges.  This may make you want to run back to your IDE and crank out some good code!  Code follows instructions right?!  Avoid this urge!

From my experience and from talking to others, I know that no one gets this right the first time. So have plenty of grace for yourself.  Failure is always our best teacher, so as you get opportunities, team lead or not, take them.  We can often learn new technologies in the convenience of a quiet room, but to delegate requires at least one other unpredictable human being of whom we can’t control the outputs.