Never forget how to delegate. This is the easiest framework for engineers.

How the most common type of document maps to delegation

📣 Try out the Directus MCP (Sponsor)

Your devs waste time on internal support tickets. Marketing is blocked. Your roadmap is drowning in “quick fixes.”

We built the Directus MCP so you can connect the AI tooling of your choice to your backend with guardrails. Your permissions, your schema, your control.

Now? Marketing can ship content without tickets. Devs can finally escape CRUD hell.

Mercedes-Benz, Emirates, and Domino’s trust Directus. Devs, marketers, and AI - finally working together, not around each other.

The Directus MCP is available now. Once you connect it, everything else is busywork.

---

If you’ve struggled with delegation before, you’re not alone. As you grow in level, it just plops in your lap.

Your manager: “Work with Jason on Project Dino. Hand off work to him so we can get this shipped faster.”

So you try. You tell Jason, “Hey Jason, can you work on this part of the project?”

Jason, eager to prove himself, says, “Leave it to me!”

Then, you check in with Jason a week later, only to realize he didn’t understand a core piece of the puzzle, and you just lost a week toward the deadline. Now, you’re dreading the moment your manager checks in for an update, to tell him that Jason hasn’t made any progress, and your manager loses confidence in your ability to lead.

If you can relate to this, don’t worry. This same situation happened to me. But since experiencing this, I found one of the easiest ways to think about delegation that not only produces great results, but also personal growth for the people you delegate to.

⭐ The framework

It starts with two words—One. Pager.

And no, this isn’t about writing a document for every tiny task you delegate. It’s about understanding how much detail the person you’re delegating to needs to be successful. So how does it work then? Let me show you.

If you didn’t read my one-pager article, it’s ok. Here’s the template for a one-pager:

1. Problem (the why)

2. Goal (the what)

3. Solution(s) (the how)

4. Optional additions

   1. Alternatives

   2. Risks

When you’re delegating work, you can think about each section as a floor on an elevator. You only need to ask, what floor do I stop at?

The floor you stop at depends on the skill and knowledge of the other person.

One-Pager Delegation Framework

• For a Staff+ engineer, you may only need to explain the problem to them. Solely from that, they can figure out everything else themselves or by asking you the right questions.

• Similarly, for a Senior engineer, you likely only need to give them the problem and goal, and let them figure out the solution.

• For a mid-level engineer, they are great executors, so you’ll want to give them the solution, but expect them to figure out the rest.

• And finally, for entry-level (or junior) engineers, you’ll likely stop at the bottom floor so that you minimize thrash and give them a pit of success.

🤔 What it looks like in practice

Scenario 1: Staff+ Engineer

This is the easiest scenario to delegate to, and why Senior Managers and Director-level leadership love Staff engineers so much, because they make their lives easy. You can hand off a broad problem statement or domain area, and the Staff engineer will figure out everything else.

For example, the Director can say,

“I’ve heard engineers complain a lot about slow and flaky CI builds. Can you look into it?”

Although this is somewhat vague, the Staff Engineer will ask all the right questions, research, and determine what, if anything, needs to be done.

So in the Staff+ Engineer case, you can typically stop at the “Problem” floor. There’s no need to go any further down.

Scenario 2: Senior Engineer

Now, let’s say you’re delegating to a Senior Engineer. Here, you want to be more explicit about the high-level goal, so communicating the why and what, but not the how. You can let them figure out the exact solution.

Extending our previous example further, this would look like:

“I’ve heard engineers complain a lot about slow and flaky CI builds. I saw that 1 out of every 5 PRs have unrelated test failures. I’d like us to work toward getting this number to 1 out of every 20 PRs. What do you think?”

Here, we tell the Senior Engineer the problem, and we’ve done enough research to feel confident about what the goal should be, or at least the metric we want to improve. But you’re not prescribing how it should be done.

As you can see from the diagram, they’ll figure out what solution, alternatives, and risks are associated with fixing the problem.

Scenario 3: Mid/Junior Engineer

Finally, for mid and junior engineers, you’ll need to provide the most information. In addition to the why and the what, you’ll also need to show how.

Extending the previous example, the delegation would look like:

—Problem (why)—

“I’ve heard engineers complain a lot about slow and flaky CI builds.”

—Goal (what)—

I saw that 1 out of every 5 PRs have unrelated test failures. I’d like us to work toward getting this number to 1 out of every 20 PRs.

—Solution (how)—

I think the best way to tackle this is to start by identifying the top 5 most flaky tests. You can pull the CI logs from the past month and count failure rates by test name. Once you have that list, go through each test and look for common patterns like race conditions, hardcoded timeouts, or tests that depend on external services.

For each flaky test, either fix it to be more stable or add retries if it’s truly non-deterministic. I’d start with the test that fails most frequently and work your way down the list. Let’s plan to check in after you’ve analyzed the logs and identified the top 5 tests, so we can align on priorities before you start fixing them.”

As you can see, it’s very specific about what needs to get done and how to approach it. This is a scale you can tune depending on the experience of the other person.

Along with the how, you’ll need to be aware of the risks and proactively ensure they’re addressed or the other person is aware of them. When delegating at this level, I also like to think of “Risks” as potential mistakes the person may make and how I can point them in the right direction.

For example, instead of hoping the person does it how I envision, I’ll show similar example outcomes so they’re clear on what I’m looking for. This is always a good practice when delegating, but even more important for someone with less experience, as there’s much less that’s automatically implied.

💡Don’t always associate by title

Although we described which floor to stop at based on engineering title, be flexible. Give them that opportunity to stretch their skills and not have all the parts handed to them, especially if they show you they can handle it. You can always adjust them based on the trust you’ve built and your confidence in the person you’re delegating to.

Use the escalator floors to figure out:

For this person and the how difficult this problem is, which floor makes sense to stop at and leave the rest up to them, so they can grow and flex their strengths?

The times you leave more to them than their title prescribes are some of the biggest growth opportunities for them and drive their progress to the next level.

💭 How this complements other frameworks

The one-pager delegation framework tells you how much detail to provide, but there’s more to delegation than that. You don’t just hand off a one-pager and call it a day. That’s where other delegation frameworks like Wes Kao’s CEDAF come in.

I marked what is already covered by this framework with a ✅ emoji, and what’s not covered with a ⚠️ emoji.

Wes Kao’s CEDAF Framework

• ✅ Comprehension: Handled by providing the right amount of detail from the one-pager delegation framework

• ✅ Excitement: Handled by talking about the problem, though it’s also good to tie this to things they care about, like their growth from the project.

• ✅ Derisk: Covered by the “Risks” section of the one-pager.

• ⚠️ Align: Should in general be covered, whether you’re handing off a doc that they can comment on or having a conversation. Still, it’s good to make a point to ask what questions they have.

• ⚠️ Feedback loop: This is about clear expectations on when you expect updates from them. This isn’t covered by what’s in a one-pager alone, so I suggest telling them this separately.

You might wonder then, what’s the point of using the one-pager framework if it doesn’t cover everything from Wes Kao’s CEDAF? Because they’re complementary. CEDAF also isn’t a superset of the one-pager framework.

By thinking about the structure of a one-pager and knowing which “floor” to stop at, you know how much detail to provide to ensure the person you’re delegating to is successful. Then, use CEDAF to ensure you’re communicating it in the best way and making your expectations clear. The two of these together create a complete delegation system: the one-pager tells you what to say, and CEDAF tells you how to say it.

📖 TL;DR

• The One-Pager Delegation Framework: View each section of a one-pager like a floor on an escalator. Decide which floor to stop at based on the other person's experience and the trust you have in them.

• Don’t always associate what floor to stop at with the title of the other person. Gradually let them fill in more of the details to intentionally challenge them, give them room to grow, and flex their strengths.

• Remember to also give them room to ask questions for clarity and provide clear expectations on when you expect updates.

👏 Shout-outs of the week

• Give your engineers a kingdom by

  Anton Zaides
  — A great way of thinking about what to delegate to other engineers as you move to leadership positions. Give them ownership and autonomy over an area, not solely tasks.

• It’s the opposite of death by a thousand cuts by

  Hilary Gridley
  — How the power of AI compounds and why one person’s AI story is not as strong as what’s specific to you.

• Advice for New Principal Tech ICs by Eugene Yan, Principal Engineer at Amazon — 30+ lessons helpful to know for all levels, but interesting to see how they apply to principal engineers.

---

Thank you for reading and being a supporter in growing the newsletter 🙏

You can also hit the like ❤️ button at the bottom of this email to support me or share it with a friend to earn referral rewards. It helps me a ton!