What Over How

The kickoff is the best meeting of the quarter. The boss says it's time to modernize the platform, and every head in the room nods. The deck says so, the budget is approved, and the meeting ends early because there's nothing left to argue about.

The infrastructure lead is nodding because modernize obviously means stability: fewer moving parts, boring technology, nothing that pages anyone at 2am. The product lead is nodding because modernize obviously means speed: more integrations, faster releases, yes to the roadmap. The CFO is nodding at a smaller cloud bill. One word, three distinct projects, and nobody in the room knows it yet.

Month four is when the projects finally collide. Nobody has failed on the how. Everyone's been executing well, and that's the problem. Every week of good execution carried them further apart, and the word "modernize" covered the distance until it couldn't.

This isn't a software problem. Swap the platform for a rebrand, a second location, or a hiring push, and the scene plays out the same way: the word changes, the collision doesn't. The failure happened back in that first meeting, at the moment everyone agreed on a sentence and stopped checking what it meant.

Competence doesn't correct a misaligned what. It scales it.

Why the what gets skipped

A how can be assigned, estimated, and demoed by Friday. A what is a conversation with nothing to show at the end, and it carries a risk the how never does: it can surface that two people in the room want different outcomes, and one of them is going to lose that argument. So the room stays agreeable, the hard conversation gets postponed, and the bill arrives in month four with interest.

There's an honest exception. Sometimes you find the what by building, because a rough version you can react to beats a spec you can't. I prototype constantly. That's fine as long as you know which one you're doing. The trap is committing to a how while believing you have a shared what.

Why this matters more right now

None of this is new, and none of it is about AI. I put a name on this principle in 2018 and bought the domain the same week. Then life did what life does, a business to run and a pandemic in the middle of it, and the idea sat there, named but unbuilt, until now. The principle hasn't changed. The stakes have.

Everything I wrote in Wielding the New Fire was about the how. AI collapses the loop between having an idea and finding out whether it holds. It hands back the attention you were spending on mechanics. That makes it a multiplier, and a multiplier pointed at an unaligned what doesn't buy you a smaller failure sooner. It buys you a bigger one.

Picture two hikers setting out for the same summit from different trailheads, radios on, comparing gear and pace every hour. The mountain has two summits, and each of them is picturing a different one, so every check-in sounds fine.

Now hand them each a helicopter.

Speed could surface the mistake sooner, if that extra energy went into checking the summit instead of the pace. It usually goes into covering ground. Execution feedback isn't alignment feedback: the demo looks good in every wrong direction, and the helicopter puts you on the wrong peak before anything feels wrong.

Every team I talk to is getting faster right now. Very few of them have gotten more aligned. Ask yourself whether yours has. The gap between those two rates is where I expect the next several years of expensive mistakes to come from.

What this looks like in a room

"Develop a what over how mentality" is the kind of advice that sounds good and changes nothing. This is the practice.

Make people write it down separately. Before anyone estimates anything, have two or three people describe what success looks like, on their own, in specifics, in a paragraph. Then read them out loud. They almost never match. The half hour that costs you is the cheapest half hour in the project.

Ask what you're willing to give up for it. A goal that costs nothing isn't a what, it's a preference. The tradeoff is where the real objective is hiding, and people who claim the same goal will often refuse very different prices for it.

Name what's explicitly out of scope. Disagreement about exclusions is much easier to detect than disagreement about goals, because exclusions are concrete and goals are aspirational. Nobody argues with "make it great." Plenty of people will argue with "so we're not doing that."

Here is what the result can sound like. A hypothetical team that walked in saying "automate our proposals" might walk out with this: prepare a proposal draft from the approved customer details, for staff to review. Do not calculate final pricing, and do not send anything to the customer. That brief names the output, who owns the last step, and two things the system must never do. Everyone in the room can check the finished work against it.

Explicit exclusions are the entire reason we could turn down auto-apply on Exec Foundry. We knew what we were protecting, so a feature that demos beautifully was an easy no. Without the what, that's an agonizing decision. With it, it took about five minutes. I wrote about that one here.

None of this is a methodology with a binder. It's a habit: insist on the destination before arguing about the route, and stay in an uncomfortable conversation long enough to discover that you didn't agree. Habits can be practiced, and a room often needs one person whose job is to hold it there while everyone else wants to move on to estimates. That's a fair amount of what I do with clients. What I'd distrust is any process that promises to skip the uncomfortable part.

Catalyst Forge is named after this. The forging is real work and it's the part I enjoy most. But the word carrying the argument was never "forge."

Find what matters. Then forge it.