19 min read
James, I want to tell you something personal. Not about the framework. Not about the model. About why I ask the question I ask.
Every engagement I do — every single one — there is a moment where I sit across from the most senior technology leader in the room and I ask them a question. It is simple. It takes about thirty seconds to say. And the answer tells me more about that leader, their organization, and their actual understanding of how software gets made than anything on their org chart, their Jira dashboards, or their quarterly business review.
Here is the question.
If I gave you fifty million dollars tomorrow — all your intellectual property, all your customers, and your current software factory continues to operate and meet your customer needs for the next eighteen to thirty-six months — what would you build?
That is it. That is the whole question.
And James, every single time I ask it, the room changes.
Because the question is not really about money.
It is about honesty.
It is the fastest way I know to find out whether a leader knows how their company actually builds software — or whether they are managing an inherited machine they no longer believe in.
The First Response Is Always the Same
The first thing out of their mouth — every time, without fail — is some version of a grin and a half-joke. “Can I pay myself a bonus and retire?”
Most readers also read: Stop Reviewing Code. Start Proving It Works. My Take on AI in the Quality Process of Software.
No. That is the constraint. You cannot cash out. You cannot coast. You cannot park the money in treasuries and run the clock. The existing factory keeps the lights on and the customers happy for the next eighteen to thirty-six months. That is your runway. That is your safety net. Your current business is not at risk.
Now build.
When I take the escape hatch off the table, something shifts. It shifts physically. I can see it in their posture. Because for the first time in a long time — sometimes for the first time in years — a leader who spends every waking hour managing what they inherited is being asked to imagine what they would choose.
Not what they would fix. Not what they would optimize. Not what they would transform.
What they would build. From scratch. With intention.
They Would Not Rebuild What They Have
James, this is the part that should keep every board member awake.
Nearly every executive — after they get past the retirement joke, after they sit with it for a minute, after they let themselves actually think about it — says some version of the same thing.
I would build a parallel organization. Small. Lean. Based on first principles.
Then I ask them what those first principles are. And the answers are remarkably consistent across industries, company sizes, geographies, and technology stacks.
One. Do not get sued and do not go to jail. Regulatory compliance. Legal obligations. Fiduciary duties. The things you cannot skip because skipping them ends the company.
Two. Delight the customer. Not satisfy. Not meet expectations. Delight. Build something so good that customers do not want to leave. Build something that solves their problem so cleanly they tell the next person about it.
That is it. Two principles. Everything else is a choice.
And here is the part that matters. Here is the part I need you to sit with.
They would not rebuild their current capabilities. Not the way those capabilities exist today.
That is why the word transformation is wrong.
You do not transform a machine you would never choose to build.
You rebuild from first principles.
What They Would Not Build
Would they build a robust finance department with thirty-seven people, a complex approval hierarchy, and a month-long budget cycle? No. They would build something lean that handles the compliance obligations and gives leadership real-time visibility. Maybe two or three people. Maybe fewer.
Would they build an HR department with layers of business partners, a sixty-day requisition process, a performance review system that nobody trusts, and a headcount approval chain that requires four signatures? No. They would build something that gets great people in the door fast and makes sure those people want to stay. Probably one or two people who are excellent at it.
Would they build a software engineering department that looks like the one they have today? Forty people across seven teams with two layers of management, a shared platform team that is simultaneously everyone’s dependency and nobody’s priority, a QA function that manually regression-tests for three weeks every release cycle, and a DevOps group that spends eighty percent of its time keeping the lights on?
No. James, they would not.
If the entire organization exists to build software — if that is the core of what the company does — they would build a team of about five people. Maybe fewer.
Five.
Not fifty. Not a hundred. Not three hundred with a planned headcount increase to four hundred by Q3.
Five.
Why Five
The number five is not arbitrary and it is not romantic. It comes from something very specific that every experienced engineering leader understands but most will not say out loud in their current operating context.
Five is the number you need so that if Tim leaves for a new opportunity next month, or Sarah goes on maternity leave, or Marcus decides to go back to grad school — you do not lose everything. You do not lose institutional knowledge. You do not lose the ability to ship. You do not lose the understanding of how the system works, why the decisions were made, and what the customer actually needs.
Five is not about capacity. Five is about resilience. It is about making sure the whole system does not wobble because one person took another job.
But here is the thing nobody says during the headcount planning conversation. Five people with the right tools, the right incentives, the right operating model, and the right level of trust can outship your current team of fifty. Not because those fifty people are bad. Not because they are lazy. Not because they do not care. But because your organization was not designed to move at the speed those fifty people are actually capable of.
You know this. You have watched a senior engineer fix a production issue in forty minutes that took the formal incident process four days to route, triage, assign, prioritize, estimate, schedule, and resource. You have seen a motivated team ship in a week what the planning process said would take a quarter. You have watched someone build a proof of concept over a weekend that an architecture review board spent six months debating.
The people are not the problem. The system is the problem. Five people without that system can move at a speed your current organization structurally cannot match.
The Part I Am Actually Measuring
James, here is the thing I have never said out loud in a blog post before. The fifty million dollar question is not really about fifty million dollars. It is not really about hypothetical organizations or first principles or team sizes.
It is a diagnostic.
When I sit across from a CTO and ask this question, I am measuring exactly one thing. Does this leader actually understand how their organization works? Do they have a coherent mental model of how software gets made inside their company? Can they articulate — not in buzzwords, not in framework names, not in vendor slide decks — the actual mechanics of how an idea becomes working software that a customer touches?
Or are they operating the puppet theater they inherited?
That is the real question underneath the question. And I ask it because the answer is immediately obvious. Not in what they say. In how they say it.
A leader who understands their operating model will light up. They will get specific fast. “I would build a team of four. An architect who can code. Two senior full-stack engineers who understand the domain. A product person who talks to customers every single day. I would give them access to the AI tooling, a direct line to me, and a blank canvas. We would ship something real in eight weeks.”
That leader knows. That leader has been thinking about this. That leader can see the gap between what they have and what is possible, and the fifty million dollar question gives them permission to say it out loud — maybe for the first time with the CEO sitting right there.
Now contrast that with the leader who pauses. Who reaches for safe language. Who says something like “well, I would invest in modernizing our platform” or “I would focus on reducing our technical debt” or “I would build a center of excellence for AI adoption.”
That leader does not know. Not because they are dumb. Not because they are dishonest. Because they have never had to answer the question from first principles. Their entire operating model is a set of inherited rituals. Standups. Sprint plannings. Quarterly roadmap reviews. Architecture review boards. Headcount requests. Vendor evaluations. Budget approvals.
None of those are bad in isolation. But when a leader cannot step outside of them — when they cannot even imagine building from scratch without defaulting to the same structures they inherited — that tells me something critical.
They do not know how software gets made. They know how to manage a system that produces software as a side effect of a lot of meetings.
And that is exactly why so many transformation programs fail. They are being led by people trying to renovate a house they would bulldoze if you let them start over. I see the same pattern in legacy modernization — every consultant says they can fix your monolith with AI, but the third attempt only works with separate governance and a practitioner who has done it before.
Why the CEO Is Listening
James, I need you to understand the room dynamics when this happens.
I ask this question to the CTO. But the CEO is in the room. And the CEO is watching. Not the answer. The confidence.
When a CTO lights up, gets specific, and paints a picture of a lean team that can outperform the existing organization — the CEO sees a leader who understands the machine. Who has a vision that extends beyond managing what was handed to them. Who can imagine a future that looks fundamentally different from the present. That CTO just earned trust with the person who matters most.
When a CTO hesitates, retreats to safe corporate language, and describes something that sounds like a slightly better version of what already exists — the CEO sees something else. The CEO starts doing math in their head. We spend forty million a year on engineering. This person cannot describe how to build the same capability from scratch for one-tenth of that. What exactly are we paying for?
That is not me being provocative. That is the thought that crosses a CEO’s mind when their technology leader cannot articulate from first principles how the thing they run actually works.
And the CEO should be concerned. Because if the technology leader of your company cannot explain — simply, clearly, specifically — how software gets made, what the actual bottlenecks are, how value moves from concept to customer, and why the current structure exists the way it does — then you do not have a technology strategy. You have a headcount allocation.
That is what the fifty million dollar question reveals. Not whether someone is smart. Whether someone is operating from understanding or from ritual.
Rituals and Good Luck Charms
Let me say it plainly because I think you can hear it.
Most enterprise software organizations operate on a combination of rituals and good luck charms. I do not say that to be cruel. I say it because I have seen inside enough of these organizations to recognize the pattern.
The rituals look like process. Standups every morning. Sprint planning every two weeks. Retrospectives that generate action items nobody tracks. Architecture review boards that meet monthly and take ninety days to approve a decision that three engineers could have validated in an afternoon. Change advisory boards that exist so someone can sign off on a deploy that an automated pipeline should have handled.
These rituals were not designed. They accumulated. They were reasonable responses to problems that existed at certain moments in time. And then the moments passed and the rituals stayed because nobody felt safe removing them. Because removing a ritual feels like removing a safety rail even when the ritual has not caught a real problem in three years.
The good luck charms are subtler. The belief that more engineers equals more output. The belief that a governance layer makes decisions better rather than slower. The belief that a longer planning cycle reduces risk rather than increasing it. The belief that coordination overhead is the unavoidable cost of building at scale — rather than a design choice you are making every single day.
I have watched organizations burn millions on coordination that could have been architecture. Millions on alignment exercises that could have been working software. Millions on process frameworks that exist to manage a complexity the operating model itself created. If you map the value stream, you will see exactly where those millions go — eighteen days of wait hiding inside a twenty-eight-day cycle.
If you removed the rituals and good luck charms — if you started with a blank sheet and fifty million dollars and two principles — you would not rebuild most of what you have.
You already told me that. You told me when I asked the question.
So why are you still paying for it?
This Is Why Transformation Keeps Failing
This is the part executives do not like hearing because it sounds like an attack on effort. It is not. It is an attack on category error.
You keep calling this transformation as if the current organization can be coached, trained, and reorganized into the thing you actually need.
It cannot.
Not because your people are incapable. Because the structure itself was built for a different cost model, a different speed, and a different set of constraints.
You built layers because coordination used to be cheaper than rebuilding. You built approval systems because mistakes were expensive and cycles were long. You built specialist teams because tooling was fragmented and handoffs were normal. All of that made sense in the world that created it.
That world is gone.
Now the cost of building has collapsed. The cost of coordination has not.
So every transformation initiative hits the same wall. The organization absorbs the new tooling, preserves the old control surfaces, and emerges looking basically the same. More licenses. More dashboards. Same wait states. Same meetings. Same dependency chains. Same inability to turn engineering effort into market speed.
That is why I ask the question.
It gets past the slogans.
Because when you give leaders a blank sheet and enough money to matter, they stop talking about transformation and start describing a rebuild.
This Is Not Bold. This Is Math.
James, I want to be clear about something because I know how this sounds. I know it sounds aggressive. I know it sounds disruptive. I know some people hear the fifty million dollar question and think I am trying to burn down the current organization or insult the people in it.
I am not. Not even a little.
The people in your organization are smart, hard-working, and doing the best they can inside the system they were given. I respect them deeply. I have been them. I spent twenty years inside those organizations. I was the engineer staying late because the process made a three-day task take three weeks. I was the manager defending my headcount in a budget review because I knew cutting two people would not reduce workload — it would just make the remaining people miserable. I was the director sitting in an executive offsite wondering why we were spending two hundred thousand dollars on a three-day strategy session when my teams needed a better CI pipeline and permission to ship without a change advisory board.
That executive offsite. Let me stay on that for a second.
You know the number. Your company spends somewhere between two hundred thousand and a million dollars a year on executive offsites. Flights. Hotels. Conference rooms. Facilitation consultants. Printed workbooks. Team dinners that somehow cost eight hundred dollars per person. Strategy sessions where senior leaders write on Post-it notes and pretend they are innovating.
That is not an exaggeration. That is the actual number at most Fortune 500 companies. Some spend more.
Here is my question. Could you take the money you spend on executive offsites — the annual ritual where leaders fly somewhere nice, agree on priorities they will not fund, produce a strategy document nobody will read after March, and fly home feeling aligned — and use that same budget to build a parallel team that can outship your competition?
Not a big expensive transformation. Not a consulting engagement that produces a roadmap. Not a center of excellence that writes guidelines.
A team. Five people. Real tools. Real authority. Real customer access. Building real software that ships.
That is not bold. That is not crazy. That is not disruptive.
That is asking whether the money you spend on theater could be spent on outcomes.
What Building Actually Gets You
When I say build, I do not mean prototyping. I do not mean a proof of concept. I do not mean a hackathon deliverable that gets a round of applause in a demo and then never gets deployed.
I mean production software that serves real customers and generates real value.
A team of five people — an architect who writes code, two strong engineers who understand the domain, a product person who is on the phone with customers every week, and someone who handles the operational surface — can ship real production software in eight weeks. Not twelve months. Not after a platform migration. Not after the vendor evaluation is complete.
Eight weeks. Fifty-six days. From blank repo to production traffic.
That team does not need your architecture review board because the architect is on the team. It does not need your sprint planning because a five-person team coordinates by talking. It does not need your change advisory board because the engineering and operational expertise is in the room. It does not need your headcount approval process because five is the team.
And because that team does not carry the coordination overhead of the existing organization, it moves at a pace that makes the existing organization look like it is standing still. Not because the existing people are slow. Because the existing system is designed for control, not speed. And that design choice has a cost — measured in months of cycle time, millions in coordination overhead, and market opportunities that ship at your competitor’s pace instead of yours.
Here is what that means commercially. If a five-person team can do what fifty cannot — and the economics of AI tooling, agentic development, and a stripped-down operating model make that not just possible but increasingly common — then you are not just building a faster engineering team. You are building a different competitive structure.
You can enter markets that your current organization is too slow to address. You can respond to customer needs on timelines that your current planning cycle cannot accommodate. You can test hypotheses in weeks that your current roadmap process would take quarters to schedule. You can ship experiments that become revenue while your competition is still in architectural review.
That is what the fifty million dollars buys you. Not a better version of what you have. A fundamentally different way to operate.
This Is Not Bimodal IT
I know what you are thinking. You are thinking this sounds like bimodal IT. Gartner sold that concept a decade ago. Run a fast team alongside the slow team. Let the fast team innovate while the slow team keeps the lights on.
It failed. Everywhere.
Here is why. Bimodal IT shared governance. Both modes reported into the same leadership, competed for the same budget, and used the same approval frameworks. Mode 1 always won the resource fight because Mode 1 had the revenue. Mode 1 had the customers. Mode 1 had the risk arguments. Mode 2 got innovation theater budget and eventually got absorbed back into Mode 1 when someone needed headcount for a priority launch.
The parallel factory model is different in three specific ways.
Separate governance. The parallel team does not report into the existing engineering organization. It does not use the existing planning process. It does not compete for the existing budget. It runs independently with its own leadership, its own decision-making authority, and its own relationship with the business.
Structural speed advantage. Bimodal IT’s fast team was still human-speed. They were faster because they had fewer meetings, not because they had a fundamentally different capability. The parallel factory has AI-native tooling, agentic development workflows, and an operating model designed from day one for the speed those tools enable. The advantage is structural, not heroic.
Pre-committed kill criteria. Bimodal IT ran forever. Nobody killed Mode 2 because nobody defined what failure looked like. The parallel factory has explicit benchmarks at months two, four, and six. If the team has not shipped a production capability by month six, the initiative terminates. Maximum loss: half the annual investment. That is less than most failed consulting engagements cost you. That is less than your executive offsites cost you.
Bounded downside. Asymmetric upside. That is a bet worth making.
What the Answer Tells Me About You
James, let me bring this back to the personal.
When I ask the fifty million dollar question, I am not testing intelligence. I am not testing creativity. I am not running a trick question to make someone feel small.
I am testing self-awareness.
A leader who can answer this question specifically, confidently, and fast — that leader knows their org. They know what works. They know what does not. They know what they would change if they had permission. They have been thinking about this, probably for years, probably in the quiet moments between meetings when the operating model they run frustrates them and they imagine something better.
A leader who struggles with it — who retreats to transformation language, who describes incremental improvement, who cannot imagine something fundamentally different — that leader may be good at their job. They may be a decent manager of a system. But they are not the leader who will build the next version of the company. Because they cannot see it. They cannot describe it. And if you cannot describe the destination, you definitely cannot navigate there.
I say this with empathy. I have been the leader who could not see it. Earlier in my career, before I started building from first principles, before I saw what a small team with the right tools and the right authority could do — I was managing the system too. I was protecting headcount. I was defending process. I was running the rituals because the rituals were what I had.
The shift happened when I watched two engineers build something in three months that a team of twelve had budgeted as a year-long initiative. Not because the two were ten times better. Because they did not carry the weight of the system. They did not wait for approvals. They did not attend alignment meetings. They did not write architecture proposals. They talked to the customer, designed the solution, built it, deployed it, and iterated on it. That was the whole process.
Everything I thought I knew about how software organizations needed to work — the teams, the layers, the ceremonies, the oversight — was wrong. Not because those things are inherently bad. Because I had confused the cost of coordination with the cost of building. And the cost of building had just dropped by an order of magnitude. The coordination stayed the same.
That is what the fifty million dollar question reveals. The gap between what building actually costs and what your organization spends. The gap between what is necessary and what is inherited. The gap between operating from understanding and operating from ritual.
The Conversation You Need to Have
James, here is what I want you to do with this.
I want you to ask yourself the question. Not in a theoretical sense. Not as a thought experiment you file away. Actually sit with it.
If you had fifty million dollars, your IP, your customers, and your current factory running on autopilot for the next two years — what would you build?
Be specific. How many people. What roles. What tools. What operating model. What governance. What do you ship first. What market do you enter. What does week one look like. What does month three look like. What does the team meeting feel like — because yes, that matters too.
If you can answer that in detail — if you can see it, describe it, and feel the difference between that picture and what you run today — then you know something important. You know the organization you run is not the organization you would build. And the gap between those two things is the opportunity you are leaving on the table every single quarter.
Now ask the harder question.
Why are you not building it?
Not instead of the current organization. Alongside it. The current factory keeps running. Here is how to plan the sessions. The customers are served. The revenue continues. And a small team — your team, with your vision, operating on first principles — starts building the future.
The money is there. It is sitting in your absorption gap. It is sitting in your coordination overhead. It is sitting in your executive offsite budget. It is sitting in the contractor spend you renew every year because your organization is too slow to build things itself. It is sitting in the headcount you keep adding because you never questioned whether the system that requires that headcount is the right system.
Your fifty million dollars is not a fantasy. It is the budget you already have, spent in ways you would not choose if you were starting over.
So stop transforming. Stop optimizing what you have. Stop trying to make the current system incrementally better through adoption dashboards and training programs and framework tuning.
Be honest about the answer your own question gave you.
You would not build what you have.
So do not call it transformation and pretend you are headed toward the thing you want.
Call it what it is.
A rebuild.
Start building.
The question was never whether you could afford to. The question is whether you can afford not to.
That was always the real question.
