The Oldest Trick in Management Just Stopped Working.

Stephen Messer, Co-founder of Collective[i] and LinkShare (sold to Rakuten for $425M, 1996–2005). Entrepreneur of the Year. Board member, Spire Global (NYSE: SPIR). Building intelligence.com

Board meetings are revealing. Spend enough time in them and you stop hearing what people say. You start hearing what they mean.

What gets decided in a boardroom doesn't stay there. The pattern a board tolerates becomes the pattern every VP tolerates. The excuse that works on a board works three levels down. If you want to understand why your company moves slowly, why goals keep getting deferred, why there's always one more prerequisite before the real work starts, it traces back to a conversation at the top. AI is changing those conversations fast, and if you're not in the room, you need to know what's shifting.

What I keep hearing, dressed in the language of strategy, is this: we can't hit the goal yet. We need to do this first.

That "this" is the project. And I'm done accepting it.

The project is the tell

New CTO arrives. Announces a replatforming. New CFO. Financial systems overhaul. New CMO. Martech consolidation. I used to treat these as serious strategic moves. Now I treat them as warning signs.

Here's what I've learned: most projects aren't strategies. They're delays with budgets. A mechanism for converting the pressure of a missed goal into the patience of a build cycle. The magic trick where the project is the flash and your actual numbers are what's disappearing.

Look at how the project gets presented. Timelines. Deliverables. Milestones. Headcount requests. Steering committees. Everything except one thing: a hard number. No one says "this project will add $8M in revenue by Q3" or "this cuts $2M in costs by December." They say the project will enable better outcomes. Eventually. After it's done.

The compensation structure makes it worse. Industry data shows 30% of IT leaders receive a specific project completion bonus. Not revenue growth. Not cost reduction. Finishing the project. The system literally pays for shipping the project, not for moving the business.

Then there's the tenure math. Median CIO tenure: 4 years 4 months. Average enterprise software project: 21 months start to finish. A CIO who proposes a major systems overhaul in year one has real odds of being gone before it's done. They get paid for the milestone. They leave before the outcome. The accountability was never there.

Projects are rarely a solution. They're usually a substitute for one. The person who can't hit the goal finds the project that explains why the goal has to wait.

WHAT THE DATA SAYS ABOUT LARGE PROJECTS AND THE PEOPLE BEHIND THEM

Nine months into a $2M CRM migration, the integrator has underdelivered, the team is exhausted, and the timeline has slipped twice. Rational analysis says: stop. Organizational reality says: we can't stop, we've already spent $2M and committed to a board presentation showing progress. So the investment compounds. The team expands. The original goal gets further away.

And the excuse machine runs perfectly. "We can't optimize the sales process until the new system is live." "The data won't be clean enough until the migration is done." The project becomes the alibi.

For what? Usually a system that's the same SaaS product they had before. New vendor. New logo. New steering committee. Same problem. I call it the AI Shuffle: swapping tools while calling it transformation. Every time I hear a leader say they're replacing their CRM or replatforming their stack, I think the same thing: here come the excuses. I'm almost always right.

AI ended the excuse. That's what makes this the right moment to say it out loud.

The old project defense had some legitimate ground. CRM implementations genuinely took 6 to 18 months. Replatforming actually required a long runway. The gap between "we need this" and "it's live" was real, and people used it because it was there.

That gap is gone.

When we roll out Collective[i], we start by augmenting an existing CRM for companies that want to move carefully, or replace the CRM stack entirely for companies ready to move fast. Either way, a client is live and focused on revenue in days. Not months. Days. When a company deploys an LLM, there's no project timeline. There's a launch date. The first results arrive before a steering committee would have held its first meeting.

Here's what makes that choice impossible to defend in 2026. A website that used to take three weeks now takes three hours. One of the most widely used code assistants cuts developer time by 55%, documented across hundreds of thousands of developers. A major financial services company deployed an AI copilot and completed business risk reviews in one day instead of three weeks. A Fortune 500 technology company took an IT support capability from concept to launch in under 100 days using two-week AI sprints. A leading pharmaceutical company compressed multi-week analytical processes to hours.

These aren't startups or edge cases. They're large organizations doing real work, faster, right now.

So when a leader sits in front of a board and says "this project will take eight months," the people across the table are running a new calculation. They've seen what AI-first execution looks like. They know the reference point has moved. Saying "eight months" isn't just describing a timeline anymore. It's telling the room something about the person saying it.

The tradeoff argument has collapsed with it. "We can do this or that, not both" used to be a resource constraint. Now it's a question about pace. When teams are shipping in days what used to take quarters, the scarcity of capacity that made the either/or real is gone. If someone is still presenting binary tradeoffs, ask whether the constraint is actually headcount or whether it's the speed the team is choosing to operate at.

The person proposing a long timeline isn't describing reality. They're describing their own pace. That's a different problem, and now it's visible.

How I handle it now

When someone proposes a project, I ask one question: what number does this move, by when, and by how much? One sentence. A specific number. If they can't answer that cleanly, the conversation stops there.

If they can answer it, we set quarterly improvements, revenue added or costs removed, measurable on the P&L, every quarter the project is running. Not when it's done. During it. That's the forcing function. If the project is genuinely creating value, proving it quarterly is easy. If they can't show it quarterly, the project is the problem.

Bonus and comp are tied to those quarterly numbers. Not to delivery. Not to milestones. To the actual business outcome. And here's the test I've started using: if someone pushes back on being held accountable during the project, they've answered the real question themselves. They don't believe in it enough to be measured by it. That tells me more than six more months of watching the project unfold.

I don't wait two quarters anymore to confirm what I already see. The project proposal is the tell. A manager who reaches for a project when AI is available isn't managing toward outcomes. They're managing toward cover.

The list. Use it.

The best thing AI did wasn't the productivity. It was the accountability.

When a tool goes live in days, the fog lifts. Either it's working or it isn't. Either the number is moving or it isn't. The space between "we started the project" and "we'll see results when it's done" disappears. What's left is just the outcome.

For people who run toward outcomes, this is the best era in business history to be operating. The tools move at the speed of ambition.

For people who've been using projects as cover, it's a different conversation. The cover is gone. The outcome is the job. The project is no longer an acceptable reason it isn't done.

The next time someone walks into a room and says we need to do this project before we can hit the goal, I hope the hairs on the back of your neck stand up. Not because projects are always wrong. Because in 2026, the question is simple: is this the fastest path to the outcome, or is this a compelling reason the outcome gets to wait?

Those aren't the same thing. Now you can see the difference.