Common obstacles to effective delegation
What gets often in the way of our ability to delegate effectively, and some ideas on how to overcome such obstacles.
A common theme among my clients and community members is a suboptimal relationship with delegation. Overworked and overwhelmed leaders often struggle with delegating effectively.
In today's article, I'll share the most common causes I have observed and how to remediate them.
Before getting into the article, I have a question for you
Do you ever feel your professional life will be much easier if you could discuss topics like this and get guidance from me and other people who — like you — face challenges in their engineering leadership journey?
I've just opened 10 seats for my community, and I'd love to have you join us.
Click this button to learn more and reserve your spot!
I'm looking forward to seeing you in our next live call!
Now, back to the article.
Why are you so busy to begin with
Even before we discuss the specifics of delegation, I want you to stop and consider why you are so busy.
Yes, jobs are complex. Life is hard. People are throwing requests and obligations your way all day long. However, in most cases, you have the choice between taking on the request or politely declining it. And even when you have good enough reasons to accept a new request, you should have a chance to decide when it'll be done.
Little's law1 shows an intrinsic relationship between cycle time, work in process, and throughput. Your main lever to improving cycle time and throughput is to limit work in process and keep it reasonably low.
Though many engineering leaders effectively apply Little's Law to their team's work, it's surprising how rarely they use the same principle for their own workload.
Before convincing yourself you have a delegation problem, you might want to check first whether you have a workload and process problem. I wrote an entire article on my productivity and time management system2 that you might want to check before moving on to common obstacles to delegation.
Now that you've implemented your system and have a manageable workload let's examine some of the most common obstacles to effective delegation.
Excessive focus on the short-term
This is the most frequent obstacle I encounter, and it has to do with operating mostly reactively.
How do you start your workday? Do you check in on Slack and emails, check what's waiting for you, and then jump on the most pressing topic on the list? Do you run most of your workday from your inboxes?
If that's your case, it is no surprise you might be struggling with delegation.
To understand why, let's start by looking at a common—and IMO overly simplistic—model some people use when thinking about delegation: the Eisenhower matrix.
In its most common form, it looks something like this
The main problem is how people tend to deal with the Urgent quadrants. In addition to ignoring a task's importance and instead focusing almost entirely on its urgent side, a more pernicious issue gets in the way of effective delegation.
When something is urgent, you'll naturally look for the quickest way to get it done.
That's in the very same definition of urgency, right?
The quickest way to get it done is often to do it yourself.
That could be because you have knowledge that only exists in your head and makes you more effective in dealing with the task; you might not have the time to document the process before the task is due; or the so-common silly excuse that it takes longer to explain it to someone else than to do it myself.
Finally, to complete the vicious circle, the reactive flywheel, you add to the mix the compounding effect of choosing the quick way: more urgent work will pile up as a consequence of your focusing mostly on urgent work.
In the system's thinking terminology, this is a reinforcing feedback look that requires an active intervention in the system to change its behavior. That intervention is relatively simple, yet not that easy to implement: deliberately break the urgency cycle by shifting more of your focus toward the long-term impact of your actions. That includes a combination of the following:
Prioritize: You have permission to ignore certain seemingly urgent tasks that are ultimately not important.
Share Knowledge in Advance: Work on important and not urgent tasks to allow others to pick up the work from you in the future: document the process and have someone else execute it; pair on the task with someone else.
Share Knowledge on the Spot: Work together with other members of your team on urgent and important tasks. Accept that this will likely increase the calendar time needed to execute them, and treat it as an investment. Do not forget that a lot of the perceived urgency is just artificial.
Review instead of Doing: Delegate entirely urgent and important tasks to other team members. Introduce a review stage where you and the other person will check the work before marking it as complete. Use those review sessions as opportunities to give feedback and transfer knowledge.
Over time, you will want to do more Review instead of Doing a type of delegation, and that's where another insidious obstacle often gets in the way.
Confusing objective outcome with taste
A friend of mine, a former colleague and someone I deeply respect, once shared an observation that has stuck with me ever since: in order to delegate effectively, you need to accept that things won't always be done according to your own taste.
So much wisdom is embedded in such an obvious statement.
As leaders, particularly in the tech sector, what often prevents us from delegating is the feeling that we might not like the result. Not that the result won't accomplish the job, but we will not like the approach taken to get there.
Put differently, we tend to focus too much on how someone will get to a certain result rather than the result itself. Obviously, certain aspects of the how are important and should not be ignored: how we handle personal data, architectural patterns, testability, robustness of the solution, or reproducibility over time.
Many other aspects, though, are perfectly irrelevant, such as the choice of editors, how to structure a spreadsheet, how the work is broken down in increments, or the font size used on a document, just to name a few.
When considering a task you are willing to delegate to someone else, it becomes essential to clearly separate hard requirements from implementation details.
Hard requirements should be well articulated, both in terms of the desired goal—how to validate that the task actually does what it's supposed to do—and non-functional requirements that will influence the implementation. All these should have an outward-facing focus: By following these requirements, the task will be accomplished in a way that maximizes the likelihood of being beneficial for the team and the company.
Conversely, implementation details should have an inward-facing focus. They should be left to the person owning the task to decide as a way to optimize their ability to achieve the stated goal. The goal should be whatever makes them more productive while still complying with the overall set of requirements. You can share your preferred approach to offer the person different perspectives and expand their toolset, but you should refrain from forcing them to follow it.
If the job is done correctly but you are still uncomfortable with specific choices, you might want to share your observations with the person as something for them to consider for the next time. However, you should also have an honest conversation with yourself to ensure you're not letting your preferences and habits get in the way of assessing a job well done.
This leaves us with a revisited Heisenhower Matrix that looks like this.
Feel free to call it the Sudo Make Me a CTO Matrix going forward!
Join Us!
If you'd like to explore this and similar topics further, you can do it for a fraction of the cost of individual coaching and mentoring.
Secure one of the ten seats available in my community. Once sold out, sign-up will be closed to allow the new members to settle in before I open additional slots.
I'm looking forward to seeing you in our next live call, scheduled for next week, Thursday, November 28th.
To read more about Little's Law's original formulation, you can look at this page on Wikipedia. For more details about how this is often used in Agile, specifically in Kanban methodologies, check this article.
