跳到主内容
精选85Wes Kao(RSS)组织与管理

委派任务前先问自己这6个问题

Before you delegate, ask yourself these 6 questions

原文
推荐理由

管理者与团队协作的读者可直接套用这套6问清单,今天就能用在下次委派任务时,减少返工、提升效率。

👋 Hey, it’s Wes. Welcome to my bi-weekly newsletter on managing up, leading teams, and standing out as a high performer. Check out my intensive course on Executive Communication & Influence. You’ll learn alongside mid-career operators from Netflix, Google, Stripe, Anthropic, etc. → Save your spot in the September cohort

Read time: 6 minutes

“It will take too long to explain how to do to this.”

For years, I resisted delegating because it was faster to do the task myself. Intellectually, I understood the benefits of delegating, including the ability to scale myself, work through others, increase my impact, etc etc etc…

But carving out the time to explain all the nuances of a task felt like a lot of work. I was afraid I wouldn’t explain well and the person wouldn’t do a good job, which would lead to me redoing the work anyway.

One day, I realized that having a checklist might help me quickly identify what to tell someone outside my own head. I’ve since used checklists like the below on hundreds of requests for others. It works in a variety of situations where you need to establish shared context:

  • If you used to do the task, and are training someone else to do it going forward
  • If you’re not sure how to do a task, but you’re looping in a cross-functional partner to do their part in a project
  • If you want to use AI as a thought partner and you want it to give you advice that’s more relevant to your situation

Here are questions I ask myself so I can confidently share context when making a request:

1. What does this person know? What’s new for them?

Considering your colleague’s existing knowledge will help take yourself out of your own head and into theirs. From this question alone, you’ll remind yourself of what they already know (that you can explain more quickly or build on) and what’s new for them (that you probably wouldn’t remember was new for them until you consciously thought about it). This has the positive effect of making you more empathetic and patient.

Every situation, project, etc will be different, so use your judgment. For example, you’d share different context if your colleague is already working on a part of a project and you’re now bringing them into a different part of that project, vs if that same person were hearing about a project for the first time.

2. Why are we doing this?

If the task requires judgment, which almost all beyond the very basic tasks do, you want to help them make the right call when you’re not looking over their shoulder. Sharing the “why” behind the task means they won’t be overly reliant on following mechanical directions or step-by-step instructions.

Also, knowing how your part fits into a broader project makes any task feel more rewarding. You can see how your work is part of something bigger.

🚫: [Silence]

✅: “This matters because…”

✅: “Our goal is to vet which micro-influencers to reach out to for our upcoming campaign. We want to make sure they’re a good fit for the brand and this specific launch.”

✅: “Once you finish this, we’ll share it with X team and they’ll take it and…”

3. What do they need in order to do this task?

This includes access to tools, platforms, spreadsheets, docs, assets, budget, people, etc. Have this ready beforehand, or be ready to list this out verbally so the person can get these assets on their own. This is like mise en place in cooking. You want to gather everything the person might need.

4. What does great look like?

Try to “show, not tell” what great looks like. For example, share mock ups, examples, screenshots, docs, analogies, etc. You want to help them pattern match and viscerally understand what you’re saying. This is where an example can be worth a thousand words.

Even if you don’t have a one-for-one example because the thing you’re asking for is new, you can show examples and say “It’s like this, except…”

🚫: [Silence]

✅: “The final document should look similar to this.”

✅: “Here are a few examples of strategy docs. Yours doesn’t need to have the exact same sections, but notice how these docs cover the ‘why now?’ of a problem and [insert other things you want to point out].”

5. What’s the timeline and priority level?

You’ll want to note if this is a “do this in the next few hours” or a “sometime this week” or “sometime in the next two weeks” type of task. Avoid phrases like “ASAP,” “urgent,” and “priority” because they are too vague and can increase stress levels unnecessarily.

Re: how much time to spend on a task, it’s not always obvious what’s considered “good enough.” I’ve delegated tasks, but when the person delivered their work, I realized they were more detailed than I needed them to be. I didn’t properly set expectations.

I like asking my colleagues to give me a heads up if they’re partway through the project and realize my estimate is off. There’s no shame in this, so don’t blame them or assume they’re “working too slowly.” If you are delegating to junior team members, getting visibility into their process will allow you to help them be more efficient. In my experience, though, what seems like a speed issue is often actually a scope issue, so it’s not something that can be solved by simply trying to work faster.

6. What’s most likely to go wrong? What can I do to prevent this from happening?

These two questions pretty much cover 99% of derisking. If the stakes are low, spend less time on this. If the stakes are high, come up with a more comprehensive set of risks so you can assess the likelihood and impact of each issue. What do you not want the person to do?

🚫: [Silence]

✅: “I don’t need paragraphs of explanation or background about each customer. I only need the name of the customer and a few bullet points about why you picked them. From there, I’ll look up each customer you recommended and review their profile myself.”

To recap, here are the questions:

  • What does this person know? What’s new for them?
  • Why are we doing this?
  • What do they need in order to do this task?
  • What does great look like?
  • What’s the timeline and priority level?
  • What’s most likely to go wrong? What can I do to prevent this from happening?

These questions are a starting point, so there may be questions you want to swap out or add that are more specific to your situation. I encourage you to create your own go-to questions.

The next time you delegate or make a request for help on a project, give these questions a try. I’d love to hear how it goes.

Join 85,000+ tech operators who are becoming sharper leaders. Subscribe (it’s free):

Thanks for being here, and I’ll see you in two weeks on Wednesday at 8am ET.

Wes

Further reading

✨ Course update: September will be the second to last cohort

The cohort next month will be the second to last cohort of the year. If you’ve been thinking about joining, check out the course details.

Here are new student reviews from the cohort a few weeks ago.

“Just the right amount of time to get the tools and exercises to feel equipped. Wes Kao’s principles, tools are fantastic. Loved how course was structured around exercises and realistic scenarios.”

  • Lilly Chen, Product Manager II @ Google

“I left with concrete actions to improve my communication, and a feeling that this is a lifelong exercise and skill well worth investing in.”

  • Anita Lillie, Senior Principal Product Designer @ Amplitude

“Really helpful. Wes went beyond theory and gave practical examples and tips. Love the cues that Wes gave to start addressing some of the issues that I find myself frequently dealing with (self sabotaging, indirect communications, rambling).”

  • David Li, Lead Product Manager @ Yelp

“This course was phenomenal. Effective communication is hard, and even when you think you’re good, you realize you have a long ways to go. If you are looking to improve what you bring to the table in conversations you’re having with clients, peers, leaders and more, I highly recommend taking this course with Wes.”

更进一步:量化金融体系

看懂新闻只是起点——沿量化金融路径,把它变成能交付的工程能力

进入量化体系 →

相似阅读

另一事件,读法相近