There’s a question every technical professional eventually faces, almost always framed wrong: do you ask permission or ask forgiveness? Picking either side already means accepting the wrong frame. Asking too much permission stalls any initiative that depends on evidence that doesn’t exist yet. Nobody confidently authorizes what they can’t evaluate. Asking too much forgiveness is betting that the outcome will absolve the method, and the previous essay in this series already showed the limit of that bet: the organization forgives deviation when it turns out well, but forgiving isn’t authorizing, and confusing the two is the fastest way to accumulate debt that eventually comes due.
There’s a third stance, less quotable than the other two, and it’s the one that actually sustains a technical career over time.
I don’t prefer asking permission or asking forgiveness; I prefer building evidence before consensus exists.
It isn’t recklessness: recklessness acts without measuring the ground it stands on. It isn’t obedience either: obedience waits for a consensus that, in most decisions that matter, doesn’t arrive before the window closes. It’s a third thing, more boring and more useful than either: prototyping the reality you’re arguing for, instead of arguing for it in the abstract. You don’t convince a committee that an internal business school would solve adoption of a data tool with a slide and a projection. You build the school, you measure adoption, and then the argument stops being a hypothesis: it’s a number that already happened.
When is building evidence before consensus viable?
Building evidence before consensus isn’t a heuristic you can apply always or on any terrain. It’s a high-upside, conditionally-risky play, and that risk gets managed by recognizing, before acting, whether all three conditions hold at once.
Condition 1: low technical risk
If the prototype fails, the failure has to stay contained: it can’t touch a system critical operations depend on, or data another area is already using to make decisions. A pilot that can be switched off without leaving a scar is an experiment. One that can’t be switched off without breaking something is a bet dressed up as an experiment.
Condition 2: fast, visible payoff
The evidence has to materialize before anyone asks why it’s being produced. If the result takes months to show up, the “this is already solved, here’s the data” window closes, and what’s left is simply an unauthorized decision with nothing yet to back it up.
Condition 3: the boss can claim the win without being exposed
This is the condition almost always left out, and it’s the one that really decides whether the play survives. A superior who sponsors (even tacitly, even with the comfortable ambiguity of “go ahead, but it’s on you”) needs to be able to present the result as their own if it works, without their name being tied to the risk if it doesn’t. If that exit doesn’t exist, there’s no real sponsorship; there’s just one person alone holding up a decision the organization hasn’t yet chosen to share.
Outside these three conditions, the same play (the same prototype, the same enthusiasm, the same conviction that “once they see it, they’ll want it”) burns you. And it’s worth saying plainly, because it’s the part success narratives tend to erase: recognizing that one of the three is missing is work you do before building, not a retrospective read after something went wrong. High technical risk without a fast payoff is simply risk. A fast payoff with no way for the boss to claim it leaves the author alone facing the question of who authorized this. Any one of the three missing turns the evidence you were going to build into the exhibit used to write the incident report.
From internal hacker to institutional architect
Say all three conditions held and the prototype worked. This is where most technical careers stall, because they treat success as the end of the story instead of the start of a different obligation.
A prototype that catches on without formal authorization, however well it works, leaves behind an institutional vulnerability, not just a personal achievement. It runs without a formal owner, without allocated budget, without an explicit decision about which area it belongs to once the person who built it changes roles or leaves. As long as nobody questions it, it’s an asset. The day someone asks “who’s responsible for this?” and the answer is “nobody, technically,” that same asset turns into the problem someone else has to solve under pressure.
That’s the precise sense in which success without governance is debt: not a metaphor, but the same structure as technical debt, something that works today because nobody has yet collected the cost of never formalizing it. And like any debt, it has a due date someone eventually collects on: an audit, a change in leadership, an incident that forces the question of who approved what. Operating without governance is defensible as an origin. It’s indefensible as a permanent state.
The move that separates someone who had a good idea from someone building a career is formalizing before the debt comes due, not after. That means turning the prototype into a program: naming owning areas, defining budget, writing the process that should have existed from the start and now exists because the prototype proved it was worth writing. The institutional architect isn’t the internal hacker with more experience. It’s the internal hacker who understood that a prototype left un-institutionalized has an expiration date, and that someone else sets that date if you don’t set it first.
How do you tell this story upward?
The same fact can be told two ways, and the difference between them isn’t cosmetic: it decides whether the conversation that follows is about governance or about discipline.
The narrative that burns is “I skipped the process because the process was slow.” It’s honest, and it’s also the least useful one, because it puts the listener in the position of having to decide whether to sanction or let an infraction slide. And that decision, framed that way, rarely ends well for whoever triggered it.
The narrative that works is different, and it isn’t a manipulation of language: it’s a more accurate description of what actually happened. “This was a scoped, reversible adoption pilot that already generated evidence. I’m now proposing we formalize it as a program, with the appropriate owning areas (training, commercial, data) defining budget and responsibilities.” The fact didn’t change. What changed is that it’s now presented as what it actually was: a prototype designed to produce fast evidence with contained risk, not a transgression that needs forgiving. The first narrative asks for leniency. The second asks for a governance decision. Only one of the two builds authority.
Closing the series
The first installment of this series told how an internal business school solved adoption of a data tool that, numerically, was already correct. It’s worth closing where that story opened: the problem was never building the tool. It was closing a data unit’s credibility gap: getting the organization to trust its numbers and adopt them as its own.
That’s the point this installment, looking at the episode through the lens of career, comes to underline. The evidence built before consensus existed wasn’t valuable for the dashboard it produced. It was valuable because it closed that credibility gap, and a closed credibility gap is an asset that persists even after the specific tool that closed it has already been replaced twice. The dashboard is replaceable. The authority a data unit gains when the organization stops asking it for explanations and starts citing it as the referee doesn’t replace so easily. And that authority, not the code behind it, is what actually stays on the résumé.
Building evidence before consensus isn’t a career trick. It’s the discipline of knowing when the terrain allows it, formalizing before success becomes an ownerless liability, and later telling the story for what it was: not an infraction that turned out well, but a prototype that did its job.