Written by Scot Chisholm
| Founders, Leadership, Management | November 8, 2024
You can’t scale a team by doing everything yourself! It doesn’t matter if you’re a 5 person team, a 50 person team or a 500+ person team – mastering delegation is one of the most important skills you can learn as a leader. But you might be thinking – we’re entering the age of artificial intelligence (AI), smaller teams means less delegation. Wrong. In this new world you’ll need to master both delegation to humans and delegation to AI-based “team members”. But here’s the good news. The core skills are closer than you’d think, making the art and science of delegation even more important going forward.
But here’s the deal – most leaders refuse to delegate work to their team. They think that teaching someone how to do something is more time consuming than just doing it themselves. And this can be true if you’re just learning how to delegate – we’ve all had a project blow up in our face. But it’s vitally important not to shy away from delegation after a few mishaps. You don’t want to fall into the trap of doing everything yourself. You’ll inevitably become the bottleneck of your own business and the reason it can’t scale. This is not a fun place to be.
So, delegation just may be the most important skill you can learn as a leader. Seriously though, just take it from Tony Robbins, “the secret to success is learning to delegate”. Well then, let’s get into it…
At its core, delegation is about transferring some level of responsibility to another person (or AI), with the goal of getting more done than you otherwise could alone. A one plus one equals three type of thing. I’ve always thought about delegation in three buckets, or ‘levels’ – delegating a project, delegating a function, or delegating an entire company. You should start by mastering level one, project-level delegation. Then you can work your way up as you gain more experience. Let’s quickly go over each:
Level 1: Project-level delegation – This is the most common form of delegation and the main focus of this article. Project level delegation is assigning someone a project to complete with a pre-defined outcome in mind. The project could be small (commonly called a task), or large (commonly called a campaign, an implementation or a launch).
Level 2: Function-level delegation – This form of delegation gives a person responsibility over a core company function (i.e. product, marketing, sales, etc.) or sub-function (i.e. a function within a function). Really, giving a person management responsibility of any kind is a form of function-level delegation. The team has some level of delegated responsibility and the manager is leading the way.
Level 3: Company-level delegation – This form of delegation gives a person leadership responsibility over an entire company – typically the CEO role. One example might be a long-time founder & CEO who hires a new CEO as part of a succession plan. Another might be an ownership group hiring a CEO for their portfolio company. Both are forms of company-level delegation.
But no matter the level, there are always two major challenges: 1) can the person actually get the thing done, and 2) can the person maintain the quality standard while doing so.
Effective delegation is largely about extending the right level of trust for the situation. Extend too little and you’re a micromanager. Extend too much and you’re flying blind (a one way ticket to Manager Mode 😬). So what’s a leader to do?
Think about trust on a scale from 0-to-10, with zero being no trust, and ten being blind trust. Effective delegation happens between a two and eight depending on the project and the person. You’ll extend the most trust to an experienced person working on an easy project (an eight). And you’ll extend the least trust to an inexperienced person working on a complex project (a two). Everything else is in between.
But regardless of where you fall, it’s always beneficial to give instruction and feedback throughout the project. If you’re on the lower end of the trust scale, you’ll give lots of instruction and feedback. If you’re on the higher end of the trust scale, you’ll ease up a bit. That said, no project should ever go without some level of instruction and feedback. Even with your most experienced operators.
Now that we’ve covered the basics, let’s dive into the 5 rules to master delegation. Follow these rules closely and you’ll never have another delegated project blow up in your face again!
Start by listing all the projects on your plate – from repetitive tasks to one-off projects. This will give you a sense of everything you could possibly delegate to others.
Next you’ll want to identify the projects that are best suited for delegation. Take your project list and score each project against two variables – Difficulty & Exposure.
‘Difficulty’ gauges how difficult the project would be for someone else to complete. Lower difficulty projects are easier to delegate. Higher difficulty projects usually require more involvement and oversight.
The second variable is ‘exposure’, which gauges how many people the project will touch. High exposure projects touch a lot of people and are usually customer-facing, all-company-facing, or shareholder-facing. Low exposure projects touch less people and are usually less risky.
Now go through your list of projects and rank each one for difficulty and exposure (low = 0, medium = 5 , high = 10). The ones that get the lowest score (low difficulty, low exposure) are ripest for delegation. The projects with mid-level scores can still be delegated but will involve a bit more thought and oversight. The projects with the highest scores should be delegated with caution, or not at all.
An example of a project that should not be delegated is the company’s vision. First, the difficulty score would be very high because the leader is in the best position to craft the company’s vision (or at least lead the visioning process). Second, the company vision touches every customer, employee and shareholder in the company, so the exposure score is through the roof.
Delegating a project to the wrong person is like putting a square peg in a round hole — it’s almost guaranteed you’ll get frustration on both sides.
When matching the project to the person, there’s two things to consider:
Using the stack ranked list from #1, use the following scenarios for guidance in picking the right person to delegate to:
Low difficulty, Low exposure: The risk is low in this scenario, so you should feel comfortable assigning these projects to a wide range of people at any experience level. Depending on the project, skillset may become important.
High difficulty, Low exposure: In this scenario, skillset tends to matter a lot, and experience level factors into the speed in which the project can be completed. But, since the exposure is low, these projects can offer a great “test” for junior team members to work on a difficult project without much risk (outside of project delays).
Low difficulty, High exposure: Any high exposure project has inherent risk to it, so you’d favor giving this to someone with an aligned skillset and mid to high-level of experience. If you chose a lesser experienced person, the quality checkpoint becomes even more important before it goes out.
High difficulty, High exposure: This type of project is the hardest to delegate because of its complexity and risk. In the earliest days, these projects are best managed by the leader themselves (or co-managed). As you scale, these projects would be led by your trusted senior leaders, with the necessary checkpoints to ensure quality.
This is where the concept of a “guardrail” comes in handy – a set of operating instructions that the ‘delegator’ gives to the ‘delegatee’ to define the boundaries of the project. Like a map to help guide them (I’ve written extensively about guardrails here). For project-level delegation, the guardrails would include the desired outcome of the project, the quality standard that must be met, and the timeline that it must be delivered by.
A ‘checkpoint’ is a meeting or review that ensures progress is being made against the pre-defined guardrails. Checkpoints are very different than micromanaging – roughly 80% of a person’s time should be spent operating autonomously on the project, and only 20% should be spent in some form of a checkpoint.
Checkpoints can include a 1×1 meeting, a working session or a more formal project review. This is highly dependent on the person and the difficulty and exposure of the project. For simple projects you can handle your checkpoints through existing 1×1 meetings. For complex projects, you should use all three checkpoint types to make sure things stay on track. Smaller impromptu touch points are OK through email or slack, but keep these to a minimum. Too many small touch points is like death by a thousand cuts. It’s better to make your checkpoints deeper and less frequent, than shallow and incessent. At a minimum, I create two checkpoints – one half way through, and one at the end. Then I dial this up or down depending on the experience level of the person and the difficulty and exposure of the project.
For pre-established check points, I let the person lead the project update. Have them walk you through where they’re at, and if they need any help or guidance. You’re specifically looking at progress against the desired outcome, how the quality standard is being met and if the timeline is at risk. Your job is to coach them through the blockers and ensure they aren’t drifting off course in any of these three dimensions.
Avoid nitpicking every little detail when the project is in its earliest phase. But as the project progresses you should absolutely focus on the details that really matter. This should have been communicated up front to the ‘delegatee’ and should come as no surprise. One of your jobs as the leader is to hold the line on quality across the company, so don’t shy away from engaging in the details. Just make sure the person understands why these particular details are so important to you and the company. This is critical when balancing the line between micromanaging and proper quality control.
Checkpoints also serve as your early warning system if the person is struggling to complete the project in the right way. Catching a struggling project early gives you the opportunity to coach the person up before it gets much worse. Most checkpoints will raise yellow flags, which you should interpret as, “help the person calibrate and proceed with some caution”. This is normal, especially with less experienced people. But what you really want to look out for are the red flags. These are signals that the project will not be delivered correctly, or at all. Too many red flags and you’ll want to take more drastic action – either rescuing the project yourself, or handing it off to someone else.
Here are some red flags to watch out for:
If you see a red flag, you should add another checkpoint where the person demonstrates they are getting things back on track. If the person fails the added checkpoint, this is a sign that they were never suited to lead the project.
Reviewing the final project is a balancing act between quality and time/cost. “Good enough” vs. “Perfect”. In most cases, trying to get a project to “perfection” is a fool’s errand. It’s typical for leaders to get stuck in endless review cycles trying to make someone else’s work look exactly like their own. In reality, they aren’t improving anything in the eyes of the end-recipient. They are just wasting time and adding cost.
You optimize this tradeoff by constraining the final review cycle and setting an acceptable quality bar depending on the exposure level of the project. If the project is internal and will only be seen by a small group of people, then maybe “good enough” is fine. You should optimize for speed in these situations. On the other hand, if the project is client-facing and you know it’ll be scrutinized, then you’ll want to push further towards “perfection”.
Here’s my simple final review process for all projects. If you’ve managed your checkpoints effectively, you should aim for a one-cycle final review. Complex projects with higher levels of exposure will require more.
When reviewing the final product, provide feedback in written notes (so it’s easier to remember and track). Aim for one review cycle (if possible) and give feedback that correlates to the appropriate quality level of the task (i.e., don’t give 7 pages of super detailed feedback if you’re willing to accept a “good enough” quality level).
Balance constructive criticism with well-deserved kudos. The way you serve it up can make all the difference.
Be clear, be honest, and most importantly, be the kind of leader who turns feedback into fuel for improvement.
While you want to minimize review cycles, you also want to make sure that the feedback is fully incorporated. I don’t bend on this one unless the person convinces me that it was a poor suggestion (i.e., they tried it, and it didn’t work). This happens, so be open to it.
Then, get it out the door and move the business forward.
Each project is a stepping stone, upping our game bit by bit. After approving something, if there was an area that could have been improved (but wasn’t worth the extra time), I let them know how to improve it on the next project they do. 💪
Delegation is not just about distributing tasks. It’s about developing leaders. Done right, it’s one of the most important things you can do to move your business forward.
Join 20,000+ leaders getting the blueprint to go from $0 to $100M.
Founders, Ops | December 14, 2024
A deep dive into three powerful insights from my fireside chat with Hiten Shah, one of Silicon Valley's most underrated founders. From reframing product-market fit as a dial rather than a switch, to building formulas over funnels, to the real talk about raising capital - these are lessons every founder needs to hear right now.
Founders | October 13, 2024
What does this transition from startup founder to scale up CEO look like? The way I describe it to Highland members is this - you need to transition from working on all the details all the time, to working on the right details at the right time. There is a massive difference here. This means spending your time on two things: guardrails and checkpoints.
Culture, Management | August 30, 2024
Good feedback should empower, not deflate. Yet most managers stumble through the feedback process. Here are 5 essential rules will transform your approach to feedback and elevate your team's performance.
I'd love to learn more about you to better customize the tips I send, ensuring they are as relevant and helpful as possible.