Delegation for the Aspirational Engineer

Posted by


The Strategic Brief:

Delegation is a skill that gets better with practice and by keeping track of your progress. Focus on the before, after and review phases of delegation by keeping notes around each phase. This will improve and refresh your delegation skills whether you are an experienced CTO, or an aspirational engineer.
 


Photo of Peacock showing off its feathers
©2017 Marco Coulter
 

Can we all agree on something? It is nice to take a vacation.

Of course, vacations only work when they are free of emergency texts and the sort of crisis emails that “only you” can deal with. Avoiding those interruptions requires us to learn effective delegation. To gain the full vacation recharge, we have to feel comfortable that the work back in the office is still being done.

This post comes from a conversation with Jason Baum on the ‘Humans of DevOps’ podcast where we discussed Learning to Delegate. Listen to my episode for a framework for task delegation and explanations of Delegation Scope; Resources; Responsibility; Reward and Priority. The DevOps Institute (a fantastic community for any DevOps or SRE professional) have a partner post on their blog at “How to Delegate: an Important Human Skill for 2022” that includes hints on avoiding self-enhancement bias and upward delegation. Definitely worth your time to read and listen.

After we finished recording, I realized I had not explained the three phases of task delegation where I take my brief notes: Before; After; and Review.

Before Phase

Once I realize I want to delegate a task, I first check that I have time to both delegate properly and later to assist/mentor/train as required. Next, I make notes that map out my thoughts on scope; resources; responsibility; reward and priority; to ensure I can be clear on my expectations. Sometimes during this process, I realize that I cannot delegate this task. Either I am not clear enough on the task to effectively delegate, or I do not have someone who is ready to receive the task. 

Imagine I need to ask an engineer who reports to me to build an API. That might require notes like this example. 

Get the newbie Paul to build the next API. It is his first API, so I should block 15 mins daily as personal office hours for him to quiz me. Ping Wendy, who may have to walk him through the new CI/CD process. Ping Clare in DevRel to advise on best practices for API publication. Ping John, as he is the guru in back-end code, but be clear that John is to advise not slip into coding!

  • Scope – API will support function documented by product team. He should agree measurable tests with product team before coding. API users are business partners and this API will enable new revenue. His code will pass CI/CD merges and tests, etc. and go live by [date].

  • Resources – he can call on Wendy and John for advice (not code). If he needs to talk to people outside company (e.g. business partners), come to me to arrange. Use my offer of daily office hours whenever he needs to. Work with Clare from DevRel for documentation and API publishing advice. 

  • Responsibility – First step should be to map out a delivery timeline and agree checkpoints with me. How he writes code is his business. If he cannot deliver all the function in the timeframe, he meets with product to negotiate.

  • Reward – My trust that he can own a business-critical deliverable. Also, increased profile for him as this expands his experience and gives him fresh CI/CD skills.

  • Priority – Sev1/2’s come first, other work is up to him to adjust.

This may look like a lot to do, and the first few times, it is. Once you use this approach a few times, and are familiar with your people, you will get to shorthand versions like the following.

“Get J to write API – sched daily office hrs 15 mins. Ping Mary CI/CD and Paul for back-end. Bus Part’rs come thru me. Due date [DATE]. He owns it. I support him as needed. Will boost his company profile. Sev1/2 come first.”

After Phase

Immediately after a delegation chat, I make quick notes that are just for me to track how well I thought I delegated. Did I pay attention to how they were reacting? Did I state everything I planned to state? If I got the delegation right, this note is one or two words. Sometimes it will include a remark about the person adjusting my expectations of them. E.g. ‘allow Ross more time for discussion – he is someone who gets comfortable with a new task by talking it through aloud’; or ‘Joyce is more experienced now and I need to avoid giving too much execution detail’.

Review Phase

When the task is completed, I set up a conversation with enough time to freely discuss how everything went. Before this chat, I poll the people they worked with for some feedback. The conversation begins by asking their thoughts on what was great and what could be better – get them talking. Next, I ask for feedback on my delegation. How could I have better prepared them? What did I do that they did not need? Then I provide feedback on the strengths and weaknesses I saw revealed about them. After the conversation, I note the actions. E.g. ‘ give more clarity on budget’, ‘set up training for Paul around observability tools’, ‘get CTO to acknowledge Paul on next all hands’. 

Build Replacements for Yourself

Showing trust and developing their skills is a reward in itself, though bigger tasks should be attached to promotions, bonuses and salary increases. Remember to give public credit as well.

Delegation shares the load and responsibility to others, while building up the people you work with. If you are aspiring to move ahead with your career, you will need a good answer when they ask “We want to promote you, who can take over your job?”.

Delegation helps prepare others to be ready for your role. Once you are delegating effectively, remember to go take that vacation leaving someone else in charge.