Essay · AI & Capital Discipline · Part 08 of 12
Two companies pick the same four initiatives. One gets compounding returns and the other gets four disconnected projects. Same picks. Different order.
I've come to believe sequencing explains more variance in outcomes than selection does, and it gets a fraction of the attention, because selection is a debate and sequencing is just logistics until it isn't.
What order buys you
Some initiatives make the next one cheaper. Some make the next one impossible.
Clean up entity resolution across your customer records and the next four things you want to do get faster and better. Skip it and build four use cases on inconsistent identity, and you've now got four systems that each carry the same defect, and fixing it means touching all four.
This is why "start with the highest-ROI use case" is bad advice slightly more often than it's good. The highest-ROI use case in isolation is frequently the one that consumes the most goodwill, occupies the most integration surface, and leaves nothing behind for the next one.
The order I've seen work
Something that produces a reusable asset first. Not the biggest win. The one whose byproduct makes later work easier — a cleaned dataset, an integration pattern, a governance decision that only has to be made once.
Then the visible win. Once you can execute, spend that capability on something the organization can see and feel, because the second bet is funded by belief and belief needs evidence.
Then the hard one. By now you have the asset and the credibility, which is exactly what a difficult initiative consumes.
People want to reverse the first two. It's tempting, because the visible win is what gets you applauded. It's also how you end up with a celebrated pilot and no foundation, which is a fine quarter and a bad two years.
Dependencies people miss
The technical dependencies are usually mapped. Data before model, integration before rollout, everybody knows.
The ones that get missed are organizational. Does this initiative need a behaviour change from a team that's currently in the middle of a reorg? Does it need budget from a function whose head is leaving? Does it require trust from a group you just took headcount from?
Those are dependencies too, and they're less forgiving than the technical ones, because you can buy your way past a data problem and you can't buy your way past a team that's been asked to absorb three changes at once.
The honest limit
Sequencing discipline can turn into paralysis. I've seen teams spend a year building foundation because the sequence said foundation first, and by the time they were ready the sponsor had moved on and the budget was reallocated.
The guard against that is a rule I hold to fairly hard: no foundational phase without a use case shipping alongside it. Not after it. Alongside. The foundation gets built in service of something real and delivers something visible on the way, or it becomes a project with no constituency, and projects with no constituency don't survive a leadership change.
On Monday
Take your next four initiatives and, for each, write what it leaves behind that the other three can use.
Whichever leaves the most goes first, even if it isn't the biggest. And whatever you sequence first, attach something shippable to it, so the foundation has a reason to exist that a new CFO can see.
The operating principle. Order by what each bet leaves behind, not by what it returns. And never build a foundation with nothing shipping on top of it.
Juan Vegarra is the author of An Outsider’s Playbook. The views here are his own. More essays · Advisory · Write me