How *do* you break down a large project? INVEST

Going from Big Vision to Series of Executable Steps is a key skill for senior+ engineers. PMs can help but they don't know everything.

If your goal is to be the engineer who gets us over the water, not builds us a bridge, you'll need to learn this. You're solving business problems, not just executing tasks somebody else defines for you.

I'm doing this at work on a for-me unprecedented scale right now. Turning ~6 months worth of vision first into projects then into deliverable roadmaps.

INVEST

Here's the heuristic I use: INVEST.

It applies fractally. To projects, to epics, to stories. How deep you go depends on the level of abstraction you're talking about. Higher level with the CEO, lower level with the team building the next feature together.

Independent – the unit-of-work can ship when finished. Straight to prod. No waiting around to carefully coordinated with other things. Especially not across teams. Use feature flags or hidden URLs if need be. Do not let work in progress build up

Negotiable – you can define what is and isn't part of this story. Defining what's not in scope is crucial. Otherwise you risk creating a never-ending task. Negotiate until everyone agrees or can disagree and commit.

Valuable – the unit-of-work must deliver value to stakeholders. Users or otherwise. Something useful has to come out. No building things for the sake of building them. The value can be to the team, you're a stakeholder too.

Estimable – you can roughly estimate how long this will take. Use reference class forecasting (how long have similar things taken in the past). If you can't do this, it's not small enough yet.

Small – small stories are quicker to build, easier to verify, and spend less time in progress. You want flow, not death marches. Smooth is fast.

Testable – automated or manual, you gotta be able to test what you did. Someone can look at the story and your work and say "yep, looks about right"

What to do first

Once you have a bunch of those, you gotta order them somehow. You're looking for the shortest critical path through the task list.

You have tasks that depend on other tasks being done first. Can't put a button on the page if there's no page. Those dependent tasks create a critical path.

How you order non-dependent tasks doesn't matter. Best if you can do them in parallel. How you order dependent tasks is critical.

I like to ask "What will make everything else easier or unnecessary?". Then sort accordingly.

You'll want to de-risk any technical risk first. If you're not sure "can we even build this", figure that out first. What is the smallest thing you can do that shows you can build a thing? If you make it directly valuable, even better.

Why this matters

You never know when priorities shift. Keep your work small, deployable, and valuable.

That way you're making progress even if leadership says "Stop working on that, we need you on this other thing for 3 months". Flexibility.

Cheers,
~Swizec