There's a comfortable career ladder implied in a lot of this industry, and it goes: you build for a few years to pay your dues, then you graduate upward into strategy and advice, leaving the actual building to the next cohort of dues-payers below you. The higher you climb, the further you get from the keyboard, until eventually you're a pure advisor — fluent in frameworks and roadmaps and board language, and comfortably distant from anything that might page you at 2am. It's a seductive ladder, and I want to argue that climbing it the way it's usually climbed produces some of the worst data advice in the market. The best advice — the kind actually worth paying for — comes from the opposite posture: from people who've built the thing, who never fully left the keyboard behind, who can trace a line from the boardroom recommendation all the way back to the pipeline it will actually run on. This is the case for advice earned at the keyboard, and it's as close as I come to a manifesto.
The failure mode nobody names: fluent, groundless advice
Start with the thing the industry politely doesn't discuss. There is an enormous amount of data advice given by people who have never built a data system in their lives — who moved into strategy early, or came from consulting, or ascended the ladder fast enough to skip the part where you actually deliver something and live with the consequences. And a lot of that advice is fluent: well-structured, confidently delivered, full of the right vocabulary, framed in exactly the language a board wants to hear. It sounds like expertise. It photographs like expertise.
And underneath, a great deal of it is groundless — disconnected from what's actually true when the recommendation meets a real system, a real team, a real budget, and a real 2am. The advisor who's never built recommends the migration without knowing what migrations actually cost in pain and rediscovered edge cases. Recommends the platform without having felt where it's genuinely weak. Recommends the architecture that's elegant on a slide and miserable to operate. The advice isn't malicious or even lazy; it's just ungrounded — floating a comfortable distance above the reality it's meant to describe, and there's no tell in the delivery, because fluency and groundedness sound identical right up until the recommendation is implemented and reality sends its invoice.
That's the failure mode I want to name plainly, because the industry is structured to reward it. The ladder pushes people away from the keyboard toward the money and status, and the further they get, the more their advice detaches from what they can actually vouch for — while getting no less confident, because confidence is what the ladder rewards. The result is a market full of advice that sounds authoritative and isn't anchored to anything, and clients who've largely stopped being able to tell the difference.
Why building is the source of the good stuff
So what does having built actually give you that no amount of framework fluency can substitute for? Not, mostly, the specific technical knowledge — that ages, and a good advisor keeps it current anyway. It's something more durable: a calibrated sense of what's real, earned the only way it can be, by consequences.
- You know what actually breaks, because it broke on you. When you've built and operated systems, you have a felt, specific sense of where things go wrong — which elegant designs are operational nightmares, which "simple" migrations hide months of pain, which vendor promises evaporate under load. That's not knowledge you can read. It's knowledge you accumulate by living with what you built, and it's the exact knowledge that makes advice trustworthy, because it's advice about reality rather than about the brochure.
- You can tell the demo from the delivery. Years of watching features dazzle in a keynote and then wilt against a real workload gives you a nose that a career of watching keynotes never will. In advisory work that nose is most of the value — telling a client which of the shiny things will survive contact with their actual data, from having watched the equivalents survive or die in yours.
- You have the credibility that unlocks the truth. This one is underrated. When you advise a technical team and they can tell you've actually done the work — from how you talk, the questions you ask, the failure modes you already know — they tell you the truth about the state of their systems. When they sense you haven't, they give you the sanitised version, and you advise on fiction. Having built is what earns you access to reality, and you cannot advise well on a reality you're not allowed to see.
- You can trace the line all the way down. The most valuable thing a built-it advisor offers is continuity of reasoning from the board-level recommendation to the pipeline that implements it. They can say "here's the strategy, and here's specifically how it survives contact with your actual systems, and here's where it'll hurt and what that costs" — because they can hold the whole chain, boardroom to keyboard, in one head. The advisor who's never built has to hand the strategy over a wall and hope it survives the translation into implementation. It usually doesn't, and they're not there to see why.
I wrote earlier this year about what transfers from building to advising and what doesn't — the craft-level version of this. This is the wider claim underneath it: that the building isn't a phase you graduate out of on the way to advice. It's the source the good advice keeps drawing from, and an advisor who cuts themselves off from it is drinking from a well that's slowly going dry.
The same recommendation, from two kinds of advisor
Here's the contrast in the flesh. A company is deciding whether to migrate its data estate to a new platform — a big, expensive, consequential call — and it takes advice from two people. Both, as it happens, recommend the migration. On the slide, their advice looks identical. Underneath, it could not be more different.
The first advisor has never run a migration. Their recommendation is built from the vendor's material, a couple of analyst reports, and a genuine, fluent grasp of the strategic logic — which is real, as far as it goes. Ask them "what will actually hurt during this migration?" and the answer stays at altitude: change management, some risk, a transition period. All true, all generic, none of it anchored to what this specific migration will do to this specific estate. They're recommending the idea of the migration, and the idea is sound. The problem is that the company doesn't have to implement an idea; it has to implement a migration, and about that the advisor can only generalise.
The second advisor has run several. Their recommendation comes with a map of the pain: which of your existing pipelines will fight the move and why, the undocumented business logic you'll rediscover the hard way, the "simple" cutover that eats a quarter, the specific point where the vendor's promise meets your reality and bends. Ask them what will hurt and they answer in specifics, because they've been hurt by the equivalent before. Their "yes, migrate" carries completely different information from the first advisor's identical-looking "yes, migrate" — it's a yes that has already priced in the reality, and it comes with the one thing the company actually needs, which is a truthful account of what it's signing up for.
Same recommendation. Same words on the slide. One of them is worth what it costs and one of them is a confident guess in a good suit — and the only way to tell them apart is to ask the questions that make the grounding show. Which is exactly the skill I want the people I write for to develop.
The counter-arguments, taken seriously
I'd be doing exactly what I'm criticising — confident, unbalanced assertion — if I didn't put the strongest objections and answer them honestly.
"Builders make narrow advisors — too in the weeds to see the strategy." Sometimes true, and worth conceding. A builder who only ever built, and never developed the ability to zoom out to strategy and speak the board's language, makes a poor advisor — too deep, too technical, unable to translate. The point isn't that building is sufficient. It's that building is the foundation on which the strategic and communication skills should be built, not a thing to be replaced by them. The ideal is both: hands-on grounding and the range to operate at altitude. A builder who never learned altitude is limited — but a strategist who never built is ungrounded, and I'll take grounded-and-learning-altitude over fluent-and-floating every time.
"Technical knowledge dates — yesterday's builder is advising on a world that's gone." A real risk, and the reason the whole thing only works if you stay close to the building. Advice has a shelf life; hands-on relevance decays; the builder who stopped building a decade ago and coasts on old credibility is genuinely dangerous, because their instincts are calibrated to a world that's moved. This is exactly why I argue for never fully leaving the keyboard rather than for having-once-touched-it as a permanent credential. The value isn't "built something once." It's "close enough to building, still, that the advice is current."
"This is just self-justification from someone who likes to build." Fair to suspect, so let me meet it directly. Yes, I like to build, and yes, I've structured my working life to keep doing it alongside advising — so I have an interest in believing this. But the argument stands on its own evidence: watch what actually happens when ungrounded advice meets real implementation, across enough engagements, and the pattern isn't a matter of my preference. The recommendations that survive contact with reality disproportionately come from people who knew what reality would do to them, because they'd been there. I'd believe this even if I'd discovered I hated building.
What this means for the people I'm actually writing to
If you're in the champion layer — a head of data, an architect, a transformation lead, the person who actually owns whether the data work succeeds — this has a direct, practical edge, and it's why I bother writing it. When you evaluate advice, whether from a consultant, a vendor, or a hire, the question that best predicts whether it's worth anything is not how fluent or senior or well-credentialed the source is. It's: can this person trace their recommendation down to what actually happens when it's built, or does it float? Ask them to. Ask what breaks, what it costs at 2am, where it's weak, how they know. The groundless advisor answers in generalities and vibes; the built-it advisor answers in specifics and scars. The difference is audible once you're listening for it, and learning to hear it is one of the higher-leverage skills you can develop.
The best data advice isn't handed down from a height, clean of implementation. It's carried up from the pipeline by someone who can still find their way back down — and who'll tell you, from memory, exactly what it's like at the bottom. If they can't make that trip in both directions, be careful what you buy.
The whole point, in one line
Everything I write here comes from this conviction, so it's worth stating it as plainly as I can. I don't believe good data advice descends from strategic heights onto grateful implementers. I believe it rises up from the work — from having built, broken, fixed, migrated, and operated real systems — and that the further advice gets from that source without staying connected to it, the more it turns into confident, fluent, well-dressed noise. The pipeline and the boardroom aren't two rungs on a ladder where you climb from one to the other and pull the ladder up. They're two ends of a single line, and the whole value of a good advisor is that they can walk it in both directions — carrying the reality of the keyboard up into the strategy, and the strategy back down into something that will actually run. The day I can't make that walk anymore is the day my advice stops being worth what I charge for it. Which is exactly why I never plan to stop building.