Jack researched delegation frameworks, interviewed founders, and analyzed real-world workloads to build a practical system for deciding what to delegate, automate, or keep.


A few months back, I was on a call with a founder who told me he hadn't taken a real weekend off in six months. He had a team of seven, including a project manager and two assistants. He was still the one scheduling discovery calls, answering routine client queries, and reviewing every piece of content before it went out.
He had no system for deciding what work belonged to him and what didn't. Most professionals are in the same spot. They carry tasks that never needed to be theirs, burn hours on low-stakes work, and watch their most important projects stay stuck. A delegation matrix is the tool that makes that visible and fixable.
A delegation matrix is a 2×2 grid that helps you sort your tasks based on two things. The first is how much value they create for your business. The second is how much energy they cost you personally. Where a task falls on that grid tells you exactly what to do with it. Keep it, delegate it, replace it with a system, or protect it as a priority.
If you've ever ended a packed week feeling like nothing important moved, this is the tool that explains that. It turns a vague sense of being stretched thin into a clear decision for every task on your plate.
The delegation matrix has four quadrants, including Delegate, Replacement, Investment, and Production. Together they form the DRIP model. Each quadrant maps a different combination of value and energy cost to a specific action.

Here's how each one works:

Building a delegation matrix comes down to four steps: running a time audit, putting together a complete task list, scoring each task on value and energy, and mapping everything to a quadrant.
Here's how it looks in action:
Once everything is mapped, your matrix template should have these columns:
| Task | Business Value (1-5) | Energy Cost (1–5) | Quadrant | Action |
|---|---|---|---|---|
| | | | | |
| | | | | |
| | | | | |
Knowing which tasks to pass on first is a different question, and it's usually where people stall. The filter comes down to two things. First, how much the task is costing you right now in hours and mental load. Second, how much effort it will take to pass it on, factoring in training time, documentation, and the risk if something goes wrong. That combination tells you when to move.
| Cost to you | Effort to transfer | When to act | Example tasks |
|---|---|---|---|
| High | Low | Now | Inbox triage, meeting scheduling, data entry |
| High | High | 90-day plan | Complex client processes, specialized reporting |
| Low | Low | Batch or automate | Templated responses, simple research |
| Low | High | Leave for now | High-context decisions, niche technical work |
Start at the top of that table. Tasks that cost you the most and are easiest to pass on should move first. The time comes back quickly because the ramp-up is minimal. The bottom rows aren't urgent. Either the cost is low enough that keeping them doesn't hurt, or the transfer effort isn't worth it yet.
Delegation matrix in context:
{{templates}}
The most common delegation mistakes are passing tasks on without context, checking in too much after delegating, and delegating only when you're already underwater. Two more round out the list. One is keeping all the decisions even after handing off the work. The other is treating delegation as a one-time fix instead of an ongoing habit.
Here's what each one looks like in practice:
| Mistake | What it looks like | Fix |
|---|---|---|
| Passing tasks on without context | You give someone the task but not the "why," so every edge case comes back to you as a question | Spend two minutes explaining the outcome you need and the standard you're measuring against before the work moves |
| Checking in too much after passing work on | The task is off your plate, but you're hovering so closely that it would have been faster to do it yourself | Set a single check-in point upfront and let the person reach it before you ask for an update |
| Delegating reactively | You only think about it when you're already underwater, so whoever gets the work receives it in a rush with no proper transfer | Build a monthly review into your calendar to catch delegation candidates before they become a crisis |
| Keeping the decisions while giving away the work | Every output still needs your approval before it moves, which makes you the bottleneck anyway | Define which decisions the person can make independently before the work starts |
| Treating it as a one-time event | You map your matrix once and never revisit it, so tasks that should have moved months ago are still with you | Review your matrix quarterly, because what belongs in your Production quadrant today may not belong there next year |
The mistakes above all share the same root cause. Delegation is treated as something you do to people, rather than a system you build around your work. Once the matrix is in place and the habits are there, it can run on software.
Once you map your delegation matrix, the Delegate quadrant fills up fast. Inbox triage, meeting scheduling, follow-up emails, research tasks. These are exactly the jobs that drain your time without needing your judgment, and they're the first place Lindy earns its place.
Lindy is an AI assistant you text to get things done. You stay in the loop on anything that needs your approval, and everything else moves without you.
Here’s what that looks like in practice:
{{cta}}
The main difference is what each one measures. The Eisenhower matrix uses urgency and importance. The delegation matrix uses business value and personal energy cost. Eisenhower helps you decide what to do today. The delegation matrix helps you decide what should be yours. They work well together, but they're answering different questions.
Anything that requires your specific judgment, relationships, or accountability. Firing a team member, making a final call on company strategy, handling a client relationship that runs on personal trust. These stay with you not because they're too important, but because the outcome is tied to you specifically.
Once a quarter is a good baseline. Your role changes, your team changes, and tasks that belonged in your Production quadrant six months ago may now belong in someone else's hands. A quarterly review takes about 20 minutes and keeps the matrix from going stale.
Yes, and it's often more useful for solo founders than for anyone else. Without a team to delegate to, the matrix helps you identify what to automate, what to outsource to a contractor, and what to stop doing entirely. The quadrants still apply. The destination for each task just looks different.
