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:
Problem (the why)
Goal (the what)
Solution(s) (the how)
Optional additions
Alternatives
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.
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.
â 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
â 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
â 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!







Loved the way you summed it up. Thanks for writing this, Jordan!
Great write-up, I'm sharing it with my colleagues