The Art of the Impossible
A Builder’s Manifesto
“The superpower of not knowing what can’t be done.” Jensen Huang has said some version of it. So has every founder who walked into an industry sideways and built something the veterans swore was impossible. The outsider who didn’t know hospitals don’t share data, so they built a platform that made them share it. The engineer who didn’t know regulatory environments crush the naive, so they just shipped and figured it out.
The conventional wisdom was wrong. Not because the veterans were stupid. Because they’d internalized constraints so deeply they’d mistaken them for physics.
This is the celebrated version. The outsider disrupts. Silicon Valley has told this story a thousand times. Ignorance of constraints as competitive advantage. The beginner’s mind as superpower.
But there’s another version of this story that almost nobody tells. It doesn’t have a clean narrative arc. There’s no dramatic founding moment, no IPO, no magazine cover. It happens quietly, over years, inside the very institutions the outsiders are disrupting.
It’s the story of the builder who stayed.
A note before we go further: this is not an autobiography. Some of it is true. Some of it is pattern-matched from a decade of watching builders collide with institutions. The story has been composited, generalized, and adjusted to fit your screen. If you recognize yourself in it, that’s the point. If you think it’s about one specific person, it isn’t.
Three Fates
When a builder enters a large organization, three things happen. Not might happen. Do happen. I’ve watched all three play out over more than a decade.
The first is absorption. The most common outcome, and it’s not a failure of character. It’s adaptation. Large organizations are optimized for consistency, and consistency rewards consensus. You learn to say “let’s align on the framework” instead of “let me build it.” You learn that the meeting about the meeting is where decisions actually get made.
You develop a sixth sense for organizational risk and a vocabulary for managing it. Year by year, the instinct to build something from scratch fades. Not because you lost it. Because the environment selected against it.
By year five, you run meetings about things you used to make.
The second is exit. The celebrated path. You leave. You start something. LinkedIn applauds. The implication, always, is that staying was the failure. That the smart ones get out. That large organizations are where builders go to die.
The third is resistance. This is the rarest, and it’s the one I want to talk about.
You stay. You keep building. Not in rebellion. You still lead the teams, attend the governance reviews, navigate the stakeholder landscape. You understand why the system works the way it does. You respect the clinical rigor, the regulatory constraints, the institutional knowledge that keeps patients safe. You are not at war with the organization.
But somewhere in the margins, you refuse to let the builder die. You prototype when you could write a requirements document. You write first code when you could assign it to someone three levels down. You build the thing that wasn’t supposed to be possible, and then you walk it into the room where people have been planning it for six months.
Not to embarrass anyone. Because working software changes the conversation from “should we?” to “how do we scale this?”
What Resistance Actually Looks Like
I want to be honest about what this is. It’s not heroic. It’s not romantic. Most of the time, it’s just relentless.
It’s the moment you realize you’ve spent four hours in sequential meetings about an AI initiative, and none of those meetings involved anyone building anything. So you go home and build the actual thing in an evening. Not because you’re smarter than the committee. Because a prototype answers questions that slide decks can’t.
It’s writing the first lines of code for a platform that your organization told you was too risky, too early, too ambitious. Not because you disagree with the risk assessment. Because you know that risk looks different when there’s a working system to evaluate instead of an abstract proposal.
It’s the loneliness of operating at a different clock speed than the institution around you. Not because you’re better. Because you’re wired to build, and the organization is wired to evaluate. Both are necessary. Only one has a lane.
And it’s the hardest skill of all: the handoff. You built it. You proved it works. Now let go. Give it to the engineers who will make it better than you ever could. Your job was never to own the thing. Your job was to make the impossible thing real enough that brilliant people could see it, believe in it, and make it legendary. Show them the art of the impossible. Then step back.
I want to be clear about something. The organization is not the enemy. Large institutions do things that no individual or startup can do. They run clinical trials that save lives. They operate at regulatory standards that genuinely matter. They coordinate thousands of people toward goals that require coordination.
The system isn’t broken. It’s just optimized for a different function than creation. It’s optimized for consistency, for risk management, for scale. Those are good things. They’re just not the same thing as building from zero.
The tension isn’t good versus evil. It’s two different metabolisms sharing one body.
The Pattern
Every builder who stays long enough develops the same pattern, whether they name it or not.
Find the whitespace. Not a complaint. A vision. The seam between what exists and what should exist. The gap that everyone walks past because it sits between two org charts, or two systems, or two assumptions that nobody thought to question at the same time.
Prototype alone. Don’t ask for permission, a budget, or a team. Just build the minimum version that proves the concept. Write the first code yourself. Not because you’re the best engineer in the room. Because the act of building is how you think. The prototype is your business case, your requirements document, and your proof of concept rolled into one artifact that people can touch.
Prove it works. Get it into someone’s hands. Let them use it. Let the usage make the argument that no presentation could.
Recruit believers. Not from the top down. From the ground up. The person who used your prototype and told three colleagues. The engineer who saw what you built and said “I can make that better.” The leader who saw adoption happening without a mandate and had the wisdom to fund it instead of fight it.
Hand off execution. This is where most builders struggle. The prototype is yours. The product is theirs. Let them own it. Let them rebuild the parts you hacked together. Let them add the governance and the monitoring and the documentation that production systems need. Your job was to prove the impossible. Their job is to make it inevitable.
Move to the next gap.
This is founder behavior inside an employee context. It’s why these people are simultaneously the most productive and the hardest to evaluate. They don’t fit in a box labeled “leader” or a box labeled “individual contributor.” They’re both. And most performance frameworks have no idea what to do with that.
AI Changed the Math
For decades, the builder inside the large organization was constrained by the same dependencies as everyone else. You need a team to build a platform. You need budget for infrastructure. You need months of procurement to get the tools. The instinct to build fast collided with the reality that building required resources that moved at institutional speed.
AI broke that constraint. Not gradually. Suddenly.
One person can now prototype in a day what used to take a team a quarter. I don’t mean a mockup. I mean a working system, backend and frontend, with documentation, ready for someone to evaluate. The gap between “I have an idea” and “I have a working version” collapsed from months to hours.
This changes everything for the builder who stayed. Especially in regulated industries.
In biopharma, finance, healthcare, the phrase you hear most often is “safe and responsible AI.” And it’s not wrong. These are domains where getting it wrong has real consequences: patient safety, financial exposure, regulatory action. The governance exists for reasons that matter.
But “safe and responsible” has a shadow meaning in most large organizations. It means slow. It means committee. It means the gap between a working prototype and an approved deployment can be measured in fiscal quarters.
The builder’s job isn’t to bypass that governance. It’s to compress the distance between “here’s an idea” and “here’s something safe enough to evaluate.” A working prototype with guardrails built in changes the risk conversation from theoretical to concrete. It’s easier to govern something you can see.
The outsider’s advantage was always speed. Move fast, unencumbered by process. The insider’s advantage was always knowledge. Deep understanding of the real problems, the actual workflows, the constraints that matter. But the insider could never move at outsider speed because the organization’s machinery stood between the idea and the prototype.
That machinery is now optional for the prototype stage. AI gives the insider-builder outsider speed while keeping insider knowledge. That’s a combination that didn’t exist before.
I wrote recently about why microinnovation beats transformation. The argument was about organizational strategy: enable 1,000 small bets instead of one big plan. But I left something out. Those 1,000 bets don’t make themselves. Someone has to be the first. Someone has to build the thing that proves the concept, negotiate the governance shortcut, create the space where others feel safe to experiment. Microinnovation at scale requires at least one person who was willing to microinnovate alone.
AI makes that first move radically easier. The builder who would have spent a month on a prototype can now spend a weekend. The proof of concept that would have required three engineers can now be built by one person who understands the problem deeply enough to describe it precisely.
The constraint that held these people back was never talent or will. It was the dependency on organizational resources to build the first version. That dependency is dissolving. And the people who feel it most acutely are the ones who’ve been waiting years for the tools to catch up to their instincts.
The Rethink
Every large organization has builders hiding in plain sight. They carry titles like “director” or “vice president” but they still write code on weekends. They build things in the margins that nobody asked for and that everybody ends up using. They’ve stayed when they could have left, not because they lack ambition, but because the problems inside the walls are genuinely interesting. Hard problems. Regulated problems. Problems that matter.
These people are not optimizing your existing systems. They’re showing you what your next systems look like.
But here’s the uncomfortable truth: most organizations don’t know who these people are. The ones who build from zero look, on paper, exactly like the ones who manage what exists. Same titles. Same meetings. Same org chart boxes. The difference is invisible until you look at what they’ve built, not what they’ve managed.
And the organizational instinct, when it does notice them, is often to promote them away from building. “You’re too valuable to write code. You should be leading strategy.” As if strategy and building are different activities. As if the person who built the impossible thing from scratch is better utilized approving someone else’s quarterly roadmap.
The rethink isn’t a restructuring. It’s a recognition. Find the builders who stayed. Understand that they’re operating with a pattern (see the gap, prototype, prove it, hand it off) that creates disproportionate value. And instead of promoting them into roles that extinguish the instinct, create space for the instinct to compound.
The organizations that figure this out will have an extraordinary advantage. Not because they hired better. Because they stopped accidentally suppressing the builders they already had.
The Art of the Impossible
The outsider’s superpower is not knowing what can’t be done. They walk in clean, unburdened by accumulated impossibilities, and they build what the veterans said couldn’t exist.
The insider’s superpower is knowing exactly what they said can’t be done, and building it anyway. They’ve heard every objection. They’ve sat through every governance review. They know the regulatory landscape, the data constraints, the organizational politics. And they build anyway. Not in ignorance of the constraints. In full awareness of them. Routing around what can be routed around. Respecting what must be respected. And proving, one prototype at a time, that the boundary between impossible and possible was never where everyone assumed.
One of them disrupts from the outside. The other transforms from the inside.
Both are practicing the same art.
The difference is that the outsider gets the magazine cover. The insider gets another meeting invite.
But the work is the same. The instinct is the same. The relentless refusal to accept that “this is how we’ve always done it” constitutes an argument is the same.
If you’re a builder who stayed, you already know everything I’ve written here. You’ve lived it. You’ve felt the pull of absorption and chosen resistance. You’ve built things that weren’t supposed to be possible and handed them to people who made them better than you imagined.
You don’t need a manifesto. You need to know you’re not alone.
There are more of us than the org charts suggest.
And the tools just caught up.