Levels of Work

Know what you've been handed before you start working.

Why this matters

Someone hands you work. You start working. Three days later, you realize you're solving the wrong problem at the wrong level.

This happens constantly. Someone says "fix the performance issue" and you start optimizing queries. But the actual problem was architectural; no amount of query optimization will fix it. You were handed a Problem and treated it like a Task.

Or the reverse: someone hands you a Task, "add a loading spinner here," and you redesign the entire state management system. You were handed a Task and treated it like an Epic.

Before you start working, know what you've been handed.

The levels

Problem

"Conversion is dropping." "The system can't scale." "We're losing to competitors."

You have been handed a question wearing the costume of an assignment. Nothing is defined yet: not the approach, not even what solved would mean. The work at this level is discovery. Ask questions until the symptom gives up the problem underneath it, then define what winning looks like. When you can state the objective, you are holding an Initiative.

The trap is jumping straight to solutions. "Conversion is dropping" does not mean "rebuild the checkout flow." It means find out why conversion is dropping, then decide what to do about it.

Initiative

"Migrate to the new platform by Q1." "Launch self-serve onboarding." "Reduce churn by 30%."

Now the objective is defined. This is your thesis on how to solve the Problem, and it is too big to execute directly: weeks or months of work, multiple workstreams, coordination across teams. The work here is decomposition. Identify the milestones, sequence them by what depends on what, and cut Epics that each deliver meaningful progress on their own where possible.

The trap is treating the whole thing as one big Epic. Initiatives are too big to plan in detail. Break them down first.

Epic

"Build the authentication system." "Complete the data migration." "Launch the pilot program."

A major phase of the Initiative: small enough to plan, big enough that mistakes are expensive. This is P-Cubed's home altitude. Prepare produces the Tasks, Prove validates the load-bearing decisions, Produce ships the capability and sends learnings back up.

The trap is skipping Prepare and Prove because the Epic looks clear from the outside. It rarely is.

Task

"Map the user data schema." "Build the import script." "Fix the SSO redirect bug."

A specific action with clear acceptance criteria, one or two days of focused work. This is where the work happens. Confirm what done looks like before you start, do the thing, ship it, move on.

The trap is gold-plating.^[1] Tasks are small. If you catch yourself expanding scope, you have discovered a new Task. Write it down and finish this one first.

Identifying what you've been handed

When work lands on your desk, ask:

1. Is the objective defined? If not, you have a Problem.
2. Is it weeks/months of work? You have an Initiative.
3. Is it days/weeks with multiple parts? You have an Epic.
4. Is it 1-2 days with clear criteria? You have a Task.

The field guide, for when you need it fast:

The confusion happens when:

• A Problem is presented as a Task ("just fix the performance")
• An Epic is presented as a Task ("add user authentication")
• A Task is expanded into an Epic ("while you're in there, maybe we should...")

Clarify before you start. "What does done look like?" gets you 80% of the way there.

A worked example, away from the desk

The levels are easier to feel in a domain with no tickets. When we moved, the garage had to become a working household space, and the same hierarchy fell out of it:

• Problem: the new home's garage does not yet support the household and workshop capabilities it needs to support.
• Initiative: build a functional garage, workshop, and reloading center.
• Epic: establish the reloading station.
• Task: break down the shipping boxes.

The exact mapping can vary, and that is not the point. The point is what the distinction prevents: a task masquerading as the outcome. Breaking down the boxes was real, finishable work, and doing it did not mean the garage worked. A task is not a problem. Completion at the wrong level can still leave the work undone.

Work flows down, learnings flow up

The hierarchy isn't just for planning. It's for learning.

Down: Problems become Initiatives. Initiatives become Epics. Epics become Tasks. Each level adds detail and specificity.

Up: Tasks produce learnings. Learnings inform Epics. Epics validate or invalidate Initiative assumptions. Initiative outcomes reveal whether you solved the Problem.

This means:

• Don't wait until the Initiative is done to learn. Learn at every level.
• A failed Task might reveal a flaw in the Epic plan.
• A completed Epic might show the Initiative thesis was wrong.
• That's fine. Adjust. The goal is solving the Problem, not executing the plan.

Decomposition

Breaking big things into small things is a skill.^[2] It's also where most planning goes wrong.

Good decomposition:

• Each piece is independently valuable (when possible)
• Each piece has clear acceptance criteria
• Dependencies are explicit
• Pieces are roughly similar in size

Bad decomposition:

• Pieces that can't be shipped independently
• Vague criteria ("make it better")
• Hidden dependencies that block everything
• One huge piece and several trivial ones

The test: Can you explain each piece to someone else and have them execute it? If not, decompose further.

The anti-patterns

Premature decomposition: Breaking things down before you understand them. You end up with a beautiful plan for the wrong thing.

Infinite decomposition: Breaking Tasks into sub-Tasks into sub-sub-Tasks. If a Task is more than 2 days, it's an Epic. If it's less than a few hours, it's a step, so just do it.

Level confusion: Executing at the wrong level. Treating a Problem like a Task (jumping to solutions). Treating a Task like a Problem (over-analyzing).

Skipping levels: Going from Problem straight to Tasks without defining the Initiative or Epics. You'll ship a lot of code that doesn't solve the problem.

The first question

Before you start any work, ask: "What level is this?"

Then work at that level. Not the level above. Not the level below. That level.

Problems need discovery. Initiatives need decomposition. Epics need P-Cubed. Tasks need execution.

Match the work to the level. Everything else follows.

Know what you've been handed. Work at the right level. Break it down until it's small enough to ship.