Pointer is a reading club for developers. It’s a window into what other current and future CTOs are reading and thinking about.

Subscribe at www.pointer.io

Thoughts from a Tech Lead

Tips and Tricks When Delegating

Derek Parham

Author’s Background: Derek is the former technical lead of Google Apps and now is an entrepreneur and startup advisor in New York City.

_____________

At some point all technical leads discover they need to delegate, but then often have little or no experience with it. When I started at Google as a software engineer, I didn’t understand the importance or really even the meaning of delegation. But I observed that some teams just ran better than others. The well-run teams made fewer mistakes due to miscommunication, grew more engineers into leaders and generally executed faster. I realized that much of this was due to strong technical leaders on the team. So what did these leaders do differently? They all possessed strong delegation skills.

I want to talk about some tactics that I saw successful technical leads use and provide some tips on how you can implement them. Specifically:

• Fully handoff— Explicitly place the full scope of the project on the new owner instead of doing piecemeal
• Support from behind — Be the wizard behind the curtain
• Delegate but verify — Don’t throw tasks over the wall without checking in and making sure things are going in the right direction

Fully handoff

Like many technical leads, I started off as the first engineer of my team at Google. It was natural for me to feel a special ownership of the product as it was my baby and my responsibility. When I first had to delegate though, it felt like other engineers were helping me on my product. Due to this thinking, I ended up not fully handing off tasks.

Beginning leaders falter fully handing off projects in any number of ways. They might continue running meetings, keep some parts of the project for themselves or encourage the point person to do things their way to prevent mistakes. Many times, these things are done in the name of “helping out” because the lead is more experienced or faster at doing certain tasks. Turns out though, this holds back point people from learning plus hurts morale.

If a lead holds onto any part of a project, they subvert the point person since they then can’t own the overall plan. By staying overly involved for the purpose of finding all mistakes before they happen, the point person never gets that experience. Don’t be afraid of mistakes being made on stuff you delegate, remember that you learned most of the stuff you know by making your own mistakes. Do make sure that the point person has your support and you aren’t surprised on major decisions (tips on that to follow).

Efficiency tip: If a lead can accomplish a sub-task fastest, simply have the point person make the call for them to do it. This allows for the most efficiency while making sure point person owns the overall plan.

Do an explicit handoff

One of the easiest ways to make sure that a point person feels full ownership is to have an explicit handoff. There is a big difference between the phrases “can you work on this” and “you own this now”. If you intend to delegate a task, use the appropriate amount of formality to make this understood. For small bugs this can be as simple as changing the “owner” field. For larger projects, a conversation or a handoff meeting might be better. If you do have a conversation, make sure that:

• The engineer understands they are now running point on the task
• Requirements are understood and there’s an opportunity to ask initial questions
• Expectations and a schedule are set for follow up
• If necessary, send out an email with details to the team to summarize and show the point person is the owner

Going over these things in person also allows the lead to build an initial connection around the project with the point person so future followups are smoother.

To Try:

• Make sure you’re fully handing off tasks. Look at your workload for the week and make sure that nothing you work on is owned by someone else. If you find something, send it over to them or have the point person decide that you’re the best to work on it.
• Make sure all projects have explicit owners. You, the point person, and the team should all know who owns what.
• Next project you delegate, hold a 10 minute meeting to explicitly hand off the task to them. Review the requirements and set expectations for follow up during that time.

Support From behind

Fully handing off a task it doesn’t mean your job is done. Instead, you need to move to the background and support the point person from behind. Lets take a simple example: Lets say a question comes in about a project that you delegated and know the answer. Whenever this would happen, it always seemed easiest to simply respond rather than bother the engineer who now owned the project. But doing that trades short-term pain for long-term pain: it causes inconsistent answers since I may not know the latest developments, takes away valuable information from the point person on the questions being asked and is a distraction for my day to day tasks. Most importantly, it took away ownership from the point person by inadvertently superseding them.

So in this situation, how do we “support from behind”? By responding back cc’ing the point person saying “Susie owns this and can answer”. This enforces that Susie is the point person and you are not. What if Susie needs support though? For example, its a questions she doesn’t yet know the answer to. In that case, then send Susie a private email preemptively telling her the answer (“Hey Susie, just in case you don’t recall, we made that decision due to a customer request”). See what we did there? Susie gets the knowledge plus receives credit for answering. The lead also benefits since the next question from the original asker will go straight to Susie. Best part is, Susie feels more responsibility for the project and knows that the lead has her back.

Efficiency tip: Many questions will come from a point person to a technical lead about delegated projects. To improve team efficiency, consider prioritizing these emails above all others. It creates confidence that if the point person has a problem, you’re the fastest responder and first person they approach. As a bonus it means they’ll probably ask more questions where by you can influence the project with on-the-spot discussions instead of finding out about details later.

Their success is your success

On strong teams, the effort a lead puts in supporting from behind is well rewarded. Engineers develop a loyalty to the technical lead because they know they will get credit for their success (which they got more easily due to the support). Then because they’re developing their own leadership and execution skills, the whole team gets stronger. This is why some teams inside Google simply ran better, the leads supported their engineers from behind which raised everyone up.

To Try:

• Don’t answer any questions about projects you don’t directly own. Cc the point person and separately send along any info they might need to answer the question.
• Answer all questions from point people quickly, even interrupting your work to do so. Use this as an opportunity to influence the project.
• Look for opportunities to support from behind. If you are about to do something for a project, see if you can instead pass the experience to the point person and they earn the credit.

Delegate but verify

After a task was delegated and I was providing support, it was tempting to think that I didn’t have to do anything else. Sometimes surprises popped up months later though — issues like lack of progress or questionable design decisions. By checking out, I gave up one of the most important responsibilities of a lead: verification of the completion and quality of the work.

You can verify a project’s progress in a number of ways. Typical methods include 1:1s and casual hallway check-ins. Sometimes these can be ineffective though, since it’s hard to dig into details of various decisions. In those cases, I recommended my point person keep a written track of ongoing project progress (like with email or Slack). If teams preferred to work by talking face-to-face, ask the point person to send a summary email on major discussions or decisions to an email list for the project (or bug report if it’s small). That way discussions get documented both in real time and for posterity. Code reviews are also an excellent way to follow along with progress and even snipe in small tweaks.

When you have larger feedback to provide, it’s often best to provide it privately to the point person. Its helpful to let a point person learn from their mistakes, but you don’t want them to walk off any cliffs. For critical decisions, private rather than public discussions avoids subverting their ownership. If changes are needed, the point person can then suggest it publicly. Hopefully that critical change works out and the point person gets the credit. But if the change doesn’t work, the lead can step up taking the blame. This is another example of how a lead can support from behind.

Efficiency tip: If a discussion doesn’t need to be private, see if you can include others! Junior engineers learn a lot simply from watching senior engineers talk about ideas and discuss tradeoffs.

To Try:

• Have all projects use an email list where all big decisions and discussions have notes sent
• Follow along and give suggestions to the point person privately if necessary
• Hold larger design discussions if possible, encouraging junior engineers to listen or participate