34 min read
Here is my fifty million dollar question.
Someone walks into your office tomorrow and hands you a check for $50 million. You keep your current IP. You keep every customer. Your existing revenue stream is guaranteed for the next two to three years — same contracts, same renewals, same cash flow. The old factory keeps running. Nothing changes on that side.
Now. With that money, that IP, and that runway — what do you build?
Think about it. Really think about it. Because I am willing to bet the answer that just formed in your head looks nothing like your current organization.
You would not rebuild what you have. Not just the engineering org — the whole thing. You would not stand up the same HR department that takes ninety days to post a role and another sixty to extend an offer and argues with you about compensation for elite talent. You would not re-create the legal team that reviews every vendor contract for six weeks while the market moves without you. You would not build the same procurement process that turns a $5,000 software purchase into a quarter-long odyssey through three approval committees. You would not hire the same layers of project management, the same QA and Security organizations, the same architectural review boards, the same change advisory committees.
You would not rebuild the sales organization that runs a nine-month enterprise cycle designed in 2015 — where the CRM is a graveyard of stale opportunities and the forecast is fiction dressed up in a Salesforce dashboard. You would not re-create the marketing team that takes four weeks to approve a landing page. You would not stand up the compliance function that requires a six-month audit cycle to change a data flow.
You would not re-create the thing that takes fourteen months to ship a feature your competitor ships in four weeks. And you know it is not just engineering that takes fourteen months. It is legal and procurement and hiring and security review and budget approval and the seventeen other functions that all have to say yes before anything moves.
You would build something lean. Something fast. Something that starts with the outcome and works backwards — without all the scar tissue your current organization accumulated over the last fifteen years.
That instinct is correct. And you do not need $50 million to act on it.
Here is the thing you already know but have not said out loud: the only reason you have not done this is because the cost of doing it was always too high. Not the intellectual cost — you figured out what needed to change years ago. The operational cost. The busy work. The sheer volume of organizational debt that has to be unwound before you can build something new. New employment contracts. New compliance frameworks. New vendor agreements. New security policies. New financial controls. New hiring pipelines. New sales playbooks. Thousands of documents, processes, and structures — each one individually small but collectively paralyzing. The kind of work that fills calendars for eighteen months and produces nothing a customer ever sees.
That was a legitimate excuse until about twelve months ago. It is not anymore.
The same AI that is rewriting how you build software can rewrite how you build organizations. The policy documents, the compliance mappings, the contract templates, the onboarding workflows, the security frameworks, the financial models — the mountain of organizational busy work that made starting from scratch feel impossible — that mountain just got a lot smaller. Not because the work does not matter. Because the work that used to take a team of consultants six months can now be drafted, reviewed, and iterated in weeks. The organizational debt that felt unpayable? The interest rate just dropped to near zero.
You always knew what you would build if you could start over. Now you can actually start.
The Transformation Trap
Every executive conversation I have starts in the same place. “We need to transform our engineering organization for AI.” The word transform comes up in the first five minutes, every time. It is the default verb. The board says transform. The consultants say transform. McKinsey has a framework for it with a name that probably includes the word “accelerate.”
Here is the uncomfortable truth: you cannot transform your current organization fast enough.
I am not saying this to be dramatic. I am saying it because the math does not work. And I am not just talking about engineering.
Your entire company — the one with two hundred or five hundred or a thousand engineers, yes, but also the HR department and the legal team and the sales org and procurement and finance and compliance and marketing — was not designed to change. It was designed to produce. To maintain. To manage risk. Every process, every role, every incentive structure in that organization exists to keep the machine running as it runs today. That is not a bug. That is what you built it to do.
Be honest with yourself. Think about what happens when you need to hire someone. A manager identifies a need. HR reviews the headcount plan. The job description goes through legal review — because it has to, because the last one was written in a way that created liability. Compensation has to benchmark the level. The role gets posted. Recruiting runs a pipeline. Candidates go through four to six interviews across three weeks. The offer goes through another approval chain. Background check. Start date negotiated. Onboarding scheduled.
Best case — the person you needed three months ago starts next quarter. And that is if the candidate accepts. In a market where AI-native engineers are the scarcest talent on the planet, they probably took a different offer two weeks into your process.
That is one function. One hire. Multiply that friction across every function in your company and you start to see the real problem. It is not a coding speed problem. It is not even a technology problem. It is an organizational physics problem. Every function was designed to be slow enough to be safe — and now safe is the most dangerous thing you can be.
And it is spectacularly good at resisting change. You already know this. You lived through it.
But here is the part that makes this hard to talk about. Your organization is not resisting change because it is broken. It is resisting change because it is loyal to you.
You built this machine. You hired these people. You wrote these policies — or you inherited them from someone who wrote them to protect the company you both care about. Every gate, every review cycle, every approval chain exists because at some point, someone you trusted said “we need this” and they were right. Legal reviews contracts for six weeks because the last time they did not, it cost you seven figures. HR runs six interview rounds because the last bad hire took eighteen months to manage out and demoralized an entire team. Finance requires quarterly budget approvals because the last time a leader had discretionary spend, they burned through it and left the company holding the bag.
These processes are not bureaucratic accidents. They are scar tissue from real wounds. And the people who maintain them are not obstructing you. They are protecting you. They are doing exactly what you asked them to do — keep the company safe, keep it compliant, keep it running. They are loyal to the mission you gave them.
That loyalty is the hardest part. Because you cannot be angry at it. You cannot fire your way through it. You cannot send a memo that says “stop being careful” to a legal team whose caution has saved you millions. You cannot tell HR to move faster when the last time they moved faster, you got sued.
The organization will resist this transformation the same way it resisted the last three — not out of spite, not out of ignorance, but out of faithfulness to the mandate you gave it. It was told to be stable. It was told to manage risk. It was told to protect the business. And it is doing that. Brilliantly.
That is why transformation does not work. You are asking a loyal organism to betray its own purpose.
Your organization survived digital transformation. It absorbed the consultants, attended the workshops, renamed a few teams, bought some cloud infrastructure, and emerged on the other side looking remarkably similar to how it looked before. The CEO declared victory. The Gartner subscription renewed. Nothing fundamental changed.
Your organization survived agile transformation. You hired scrum masters. You renamed your project managers. You bought Jira licenses. You started doing standups. And your engineers — the smart, rational people they are — learned to play the new game while building software exactly the way they always had. Two-week sprints that somehow still take six months to deliver anything meaningful. The Agile Manifesto on the wall. Waterfall in the spreadsheet.
And it was not just engineering that absorbed the change and stayed the same. Sales kept running the same pipeline process with the same stage definitions. Legal kept reviewing contracts clause by clause with the same turnaround times. Finance kept running the same quarterly budget cycle that treats every new initiative like a capital expenditure that needs eighteen months of justification. HR kept posting roles the same way, running the same interview loops, and measuring time-to-fill instead of quality-of-hire. The whole company developed antibodies against transformation — not because people are resistant to change, but because the system rewarded stability. And it still does.
Now you are thinking about AI transformation. And somewhere in your organization, the same person who led the agile transformation — or their direct successor — is being asked to lead this one too.
Think about that for a moment. The person whose job was to change your organization — whose organization did not, in fact, change — is now responsible for the most consequential technology shift in a generation.
This is not their fault. They are a rational actor in a system that rewards the appearance of change over the substance of it. But you need to see the pattern. Because if you run the AI transformation the same way you ran the digital transformation and the agile transformation, you are going to get the same result: a slightly modernized version of exactly what you have now.
And this time, that is not good enough.
The Five Percent Trap
Here is what the transformation playbook actually delivers.
You roll out AI tooling to your existing teams. Copilot, Cursor, Claude — pick your favorite. Adoption is great. Engineers like it. PRs go up. Somebody runs a study and finds a fifteen percent improvement in code generation speed. Your head of engineering presents this to the board as evidence of progress.
Then what?
Maybe you get five percent more cost efficiency out of your current operation. Maybe ten percent if you are aggressive and the stars align. You shave some time off code generation. A few boilerplate tasks get automated. Some internal tooling gets built faster. The quarterly report looks better than last quarter.
But your sales cycle is still nine months. Your legal review still takes six weeks. Your procurement process still turns a simple software purchase into a quarter-long negotiation. Your HR department still takes ninety days to hire an engineer — if the candidate has not already accepted a competing offer. Your compliance team still requires a full audit cycle before a new data flow goes live. Your finance org still budgets annually, which means any new initiative that was not planned in October is dead on arrival until next fiscal year.
You made coding five percent faster inside a company that moves at the speed of its slowest approval chain. Congratulations.
Here is the part that will make your next board meeting uncomfortable. Your head of engineering is going to stand up and present a thirty percent improvement in engineering velocity. And they are not lying. Within engineering — inside the four walls of that team — things genuinely moved faster. Code got written faster. PRs got merged faster. Deployments increased. The metrics are real.
Then your CFO is going to look at the P&L and see five percent. Maybe less.
Where did the other twenty-five percent go? It did not disappear. It got absorbed. It got eaten by every other function in the company that did not change. Engineering shipped faster, but legal still reviewed at the same pace. Product still scoped at the same pace. Security still audited at the same pace. HR still hired at the same pace. Finance still approved budgets at the same pace. Sales still closed deals at the same pace.
Your engineering team sprinted ahead — and then stood at the gate, waiting for the rest of the company to catch up. The same loyal systems that protect the business, the ones we just talked about, are now the reason your thirty percent improvement shows up as five percent on the balance sheet. The engineering gains are real. The organizational gains are not. Because the organization did not change. Only one department did.
Your CFO is not wrong. Your head of engineering is not wrong either. They are both reading different instruments on the same aircraft — and the aircraft is not climbing.
Put a dollar figure on it. Take a $20 million engineering organization. Your engineers report a thirty percent velocity improvement — that is $6 million in potential value. Your CFO sees five percent on the P&L — that is $1 million in realized value. The difference — $5 million a year — is engineering productivity that your organization converts into wait time, not output. It is sitting in legal review queues, procurement cycles, budget approval wait states, and HR hiring pipelines. It is the twenty-five percent that your loyal systems ate.
The parallel factory does not have those queues. That is not a five percent improvement. That is $5 million in annual value your current structure physically cannot capture. And the longer you run the transformation playbook, the longer that $5 million stays locked in organizational friction instead of showing up on the balance sheet.
In 2019, that five percent would have been a career-defining win. You would have gotten a promotion. A keynote slot. A case study in Harvard Business Review.
In 2026, that five percent is a rounding error.
Not because five percent does not matter. Because the organizations that are not playing the five-percent game — the ones that started clean, built AI-native from day one — are operating at a fundamentally different speed. They are not five percent faster at coding. They are five times faster at everything. They did not just give engineers AI tools. They rebuilt how the whole company works — how they hire, how they sell, how they manage risk, how they approve spend, how they launch products. The entire value chain, not one stage of it.
Your five percent improvement is real. It is also irrelevant. You optimized your loyal horse while your competitor bought a Mustang. One with an engine.
The Leader With Two Hands
Let me give you a different model.
Imagine the leader — you — has two hands. Two distinct jobs that require fundamentally different approaches.
Your left hand manages your current operations. The loyal factory. And I do not just mean the engineering floor. I mean the whole loyal machine — the hundreds of engineers, yes, but also the sales team and the marketing department and the legal group and HR and finance and procurement and compliance and customer success and the operations team that keeps production running. You spend maybe thirty percent of your attention here. You keep the lights on. You keep customers happy. You make sure payroll runs and deploys do not break production on a Friday afternoon.
You do this because you know something important about that factory: it is a magical mystery box. And not just the codebase — the whole company. You probably do not fully understand how your sales org actually closes deals. You know what the CRM says, but you also know the CRM lies. You do not fully understand why legal takes six weeks on a contract that should take three days. You do not understand why HR insists on six interview rounds when your best hires were all obvious after two. You do not understand why procurement requires three competitive bids for a $10,000 tool when the engineering team has already built a workaround that costs more in engineer-hours than the tool itself.
The whole organization evolved organically over years. The tribal knowledge is distributed across dozens of heads, some of whom have already left the company. The system works because it works, not because anyone designed it to work this way. And changing it — really changing it, not just bolting something onto the side — is somewhere between expensive and impossible.
Maybe you can squeeze some efficiency out of it. Maybe AI tooling gets your teams shipping a little faster. Maybe you automate some testing, some deployments, some of the mechanical work that slows people down. Good. Do that. But be honest about what it is. It is maintenance. It is optimization. It is not transformation.
Now. Your right hand. The dominant one.
With your right hand, you build something new. A parallel organization. Lean. Small. AI-native from the first commit. Not a team within the existing org. Not a “Center of Excellence” that reports into the same structure. A separate entity with its own governance, its own hiring criteria, its own incentive model, and its own mandate.
This new organization does not inherit your technical debt. It does not inherit your process debt. It does not inherit your cultural debt — the learned helplessness of engineers who have been trained over a decade to optimize for the appearance of productivity instead of actual output.
This new organization builds the next thing. The next product. The next platform. The next version of whatever your company does — built the way it would be built if you started today, knowing what you know about where AI is heading.
And yes, sometimes that new thing reaches back to the old thing via APIs. It consumes data from the legacy platform. It integrates with the existing customer experience. But it does not live inside the loyal factory. It does not get slowed down by the loyal factory’s processes, politics, or permission structures.
You fund the new organization with the revenue from the loyal one. The loyal factory is your cash cow. It earned that. Respect it. But it is not your future.
This Is Not Bimodal IT
If you have been in technology leadership for more than ten years, you just read the last section and thought: this is bimodal IT. Gartner sold us this in 2014. We tried it. It did not work.
You are right to be skeptical. And you are wrong about the comparison. Here is why.
Bimodal IT failed for three specific, structural reasons.
First — same leadership, same incentives. Mode 2 reported to the same CIO as Mode 1. The same budget cycle funded both. The same executive team evaluated both. And because Mode 1 generated revenue and Mode 2 generated demos, Mode 1 always won the resource fight. The parallel organization converged back into the loyal factory because the gravity was never separated. The parallel factory model requires structurally separate governance — separate budget authority, separate reporting line, separate success metrics. Not because separation is philosophically better. Because the last time you tried this without separation, the loyal factory ate it alive.
Second — no tooling advantage. In 2014, the only way to go faster was to hire better people and hope they resisted organizational gravity. That is a human-effort bet, and human-effort bets revert to the mean. Every time. What is different now is not willpower. It is tooling. AI-native workflows create a structural speed advantage that is not dependent on heroic individual effort. The parallel factory is not faster because it has more motivated people. It is faster because it has fundamentally different capabilities. That distinction matters.
Third — no kill criteria. Bimodal IT ran for years at some companies because nobody defined when to stop. The parallel factory model has pre-committed termination conditions. If the team has not shipped a production capability by month four, you conduct a formal review. If nothing ships by month six, you shut it down and reallocate the capital. Bounded investment, bounded risk, clear decision gates. The board should know exactly when and how this gets evaluated — and exactly when it gets killed if it is not working.
This is not bimodal IT the way a Tesla is not a horse and buggy. They both have wheels. The similarity ends there.
Why You Cannot Just Fix What You Have
Let me walk you through what happens when you try to transform the existing organization. And I want you to follow the bottleneck all the way through — not just through engineering, but through the whole company. Because that is where it actually goes.
You start with coding. You give engineers AI tools. Code generation gets faster. Great. But now your code review queue is drowning because you tripled the volume of PRs without adding review capacity. So you fix the review process.
Now code is getting written faster and reviewed faster. But your QA team is the bottleneck. They are testing at the same speed they always did. Agents are shipping code faster than humans can validate it. So you invest in test automation.
Now coding is faster, review is faster, and testing is faster. But your product organization cannot write requirements fast enough to keep up. The backlog is empty for the first time in a decade — not because you shipped everything, but because nobody scoped the next thing yet. Product becomes the constraint.
So you fix product. You get requirements flowing faster. Now the deployment pipeline is the bottleneck. So you fix that. Now security review is the bottleneck — two people reviewing every release for a company that used to ship monthly and now wants to ship daily. So you staff up security.
Now security is faster. But legal has to sign off on anything that touches customer data. Legal is a three-person team with a four-week turnaround and no intention of changing that, because the last time they rushed a review the company got hit with a regulatory finding. They are not being difficult. They are being rational. The incentive structure punishes speed and rewards caution. So you are stuck.
Let us say you fix legal. You streamline the review process. Now marketing cannot launch the feature fast enough. The go-to-market process requires collateral, enablement materials, sales training, and a pricing review. The pricing review requires finance approval. Finance only meets biweekly. Two weeks of dead time — not because anyone is lazy, but because that is the cadence the organization runs on.
So you fix the cadence. Now the sales org cannot absorb the new features fast enough. The sales engineers need training. The account executives need new talk tracks. The customer success team needs updated playbooks. But the sales enablement team is a shared service that supports four product lines, and yours is third in the queue.
And now you need to hire more people to staff all these changes. But HR takes ninety days to hire. And the talent you need — AI-native engineers, modern product managers, designers who understand what AI-native UX looks like — is the scarcest talent in the market. Your comp bands are outdated. Your leveling framework does not have a title for the role you actually need. Your benefits package is competitive for 2021 but not for 2026. And the recruiter assigned to your req is also covering twelve other open positions because the recruiting team was downsized last year.
You are chasing the bottleneck across your entire organization. Not just across engineering — across the whole company. And every time you solve one, the next one appears. This is not a new observation — Eliyahu Goldratt described it in 1984. The Theory of Constraints. The bottleneck moves. It always moves.
But here is what makes this worse than a manufacturing constraint. You are not just chasing a bottleneck through a factory. You are chasing it through a human organization that has been explicitly designed — through years of hiring, process, incentives, and culture — to resist exactly the kind of change you are trying to make.
Your change advisory board is not going to get faster because you want it to. Your security review process is not going to shrink because your engineers started using Cursor. Your legal team is not going to approve releases on the same day just because the code was written by an agent. Your HR department is not going to collapse its hiring process because you need someone yesterday. Your finance org is not going to switch to rolling budgets because your engineering team now ships weekly.
Every one of those functions was built to be a gate. A checkpoint. A place where work slows down so that risk gets managed. And every one of those gates has a person or a team whose identity, budget, and career advancement depend on that gate continuing to exist.
These are not bad people. They are not the enemy. They are not “blockers” on your transformation roadmap. They are human beings who showed up every day and did the job you gave them. Your legal counsel sat through depositions so you did not have to. Your HR leader had the conversation at nine on a Tuesday night with the director who was harassing a junior employee — and then managed the investigation, the termination, the legal exposure, and the team’s recovery while you slept through it because they did not need you to know. They redesigned your comp bands after you lost three senior engineers to a competitor, and you never knew it was happening until the attrition stopped. They talked your VP off the ledge during the reorg, mediated the conflict between your two strongest directors, and built the onboarding program that turned your last three hires from confused to productive in half the time. Your finance director said no to spending that would have sunk you, and you never even knew about it because the crisis never happened. Your security team stayed up on a Saturday night patching a vulnerability while you were at your daughter’s soccer game.
They kept the company alive. They earned their place. And now you are reading an article that says the organization they built needs to be superseded by something new. That is a hard thing to sit with.
So let me say this clearly: the people in the loyal factory deserve to be treated like what they are — people. Not headcount to be “rationalized.” Not resources to be “reallocated.” Not a cost center to be “optimized.” People. With mortgages and kids in school and fifteen years of institutional knowledge that no agent can replicate.
Some of them will move to the new factory. The best ones — the ones who understand the domain deeply, who know why the system works the way it does, who have the institutional memory that makes the difference between building something smart and building something that looks smart — those people are gold. They are not the problem. They were never the problem. The system was the problem, and they did their best inside it.
Some of them will stay in the loyal factory and keep it running, because someone has to, and that work matters. Some of them will retire on a timeline they choose, with dignity, because they spent twenty years earning that right.
None of them should wake up on a Monday and find out their job is gone because someone read a blog post about AI transformation. That is not what this is.
They are loyal. Every single one of them. And that is exactly the problem — because what you asked them to be loyal to was stability, and now you need them to be loyal to speed. That is your job to solve. Not theirs.
You are not fighting a technical problem. You are fighting a loyal organization. And that loyal organization has already beaten your digital transformation. It has already beaten your agile transformation. It will beat this one too — not because it wants to fail you, but because protecting you is what it knows how to do.
The Margin Lesson Nobody Wants to Learn
Let me tell you what happened in the coding agent space over the last year. Because it is a preview of what is about to happen in your industry.
An incumbent — one of the big established players — came out early and was winning. Enterprise contracts. Mindshare. The default choice. They had the market.
Then an AI lab released a competing product. Built by a focused team with deep model expertise. It was better. It took market share overnight.
Then a startup showed up. Smaller team. Narrower focus. Faster iteration. It started beating the AI lab’s product on the benchmarks that mattered.
Then five engineers at a project called Kilo Code came along and built an open-source alternative that started beating the startup.
Five engineers.
This entire cycle — from dominant incumbent to five people threatening the dominant incumbent — happened in roughly a year. Everyone is still employed. Everyone is still making money. But think about the margin compression. Think about what happened to the pricing power of the company that was winning twelve months ago. Think about how much of their moat evaporated because someone with fewer people, less capital, and better tools decided to compete.
Now apply that pattern to your industry.
The cost of software is approaching zero. It will never be zero — there will always be cost in design, in architecture, in understanding the problem, in operating the system. But the cost of producing the code itself — of turning a specification into a working implementation — that cost is collapsing. And it is collapsing fast.
If you are a pure software company, this is existential. If your primary asset is your codebase and your primary moat is the complexity of rebuilding it — that moat is draining. What used to take a team of fifty engineers eighteen months can now be built by five people in a quarter. Not the same quality. Not the same scale. But close enough to compete. Close enough to take margin. Close enough to make your board ask uncomfortable questions.
If you sell a physical product or a service with software around it, the timeline is longer but the direction is the same. The software layer that differentiates your offering — the one that took years to build — is getting cheaper to replicate every month.
You do not need the organization you have at the scale you have to produce what you produce. And every month you wait, that statement becomes more true.
What We Actually Do
So here is the approach. We call it Map, Build, Transfer — not because the name matters, but because you need to be able to describe it to your board in one sentence. “We map the value stream, build the parallel factory, and transfer ownership to our team.” That is the sentence. Here is what it means.
Map: we map what you build and how you build it. We walk your value stream end to end. Not the theoretical one in the process documentation that nobody has updated since 2021. The actual one. How does an idea become software that a customer uses? Who touches it? Where does it wait? What are the real bottlenecks — not the ones people complain about in retros, but the ones the data shows?
This is not an assessment that produces a PowerPoint deck and a maturity score. This is a working session that produces a map. A brutally honest map of how your factory actually operates.
Build: we build the parallel factory. We do not try to fix the existing organization. We stand up a new one alongside it. And not just the engineering part — the whole thing.
Small team. AI-native workflows from day one. The right governance model — not the one you inherited from your agile transformation, but one designed for a world where agents write code and humans make decisions. Guardrails, not gates. Constraints encoded into the tooling, not enforced by committees.
A note on gates — because not all of them are scar tissue. Some gates exist because a federal regulator put them there. NERC CIP in utilities. HIPAA in healthcare. CMMC in defense. FDA 21 CFR Part 11 in pharmaceuticals. Those are not organizational habits to be bypassed. Those are legal obligations to be respected absolutely. The parallel factory eliminates the other kind — the gates that were created by analogy, the process that was designed for your most regulated system and then copy-pasted onto everything else. In most organizations, seventy percent of the gates are habit. Thirty percent are law. Your job is to know which is which. The parallel factory respects the law and eliminates the habit.
The right support structure. Not a project manager and a scrum master and a release manager and a program manager. An architect who understands the domain. A product person who can write clear requirements. Engineers who own quality, security, and deployment as part of their workflow — not as handoffs to other teams. A hiring process that moves in days, not months. A legal framework that was designed for the new operating model from the start. A go-to-market motion that fits what you are actually building.
That is the team. That is the organization. Small enough to be fast. Complete enough to ship without asking the loyal factory for permission.
We work with your People leader from day one. Not as an afterthought. Not as a “change management workstream” that runs parallel to the real work. Your CPO or CHRO is in the room when we map the value stream, when we design the parallel factory’s governance model, and when we plan the transition. Because the technology is the easy part. The people are the hard part. And we have learned — sometimes painfully — that ignoring the People function is the fastest way to kill a parallel factory before it ships a single line of code.
Transfer: we recommend you operate it separately — and then we hand it to you. Not because separation is philosophically superior. Because proximity kills it. If the new team sits inside the loyal organization, the loyal organization’s antibodies will attack it. Not out of malice — out of love. HR will impose its leveling framework because that is how it protects people. Finance will impose its budget cycle because that is how it protects capital. Legal will impose its review cadence because that is how it protects the company. The meetings will consume the team. The culture of learned caution — the one that kept your employees safe through every previous “transformation” — will wrap itself around the new thing and suffocate it. Gently. Loyally.
Separate governance. Separate cadence. Separate metrics. The new factory talks to the loyal factory through APIs when it needs to. But it does not live there.
You build the next thing. A new product. A new platform. A rearchitected version of your core offering. Whatever the thing is that you would build if you started today — that is what the new team builds. They build it the way it should be built, unencumbered by the decisions you made in 2014.
And you fund it with the cash flow from the existing factory. The old organization is not dead. It is your revenue. It is your customer base. It is your foundation. But it is not your future. The new factory is your future.
Some people call this bimodal. Some call it two-speed IT. Some have fancier names for it. We addressed why this is different above. The name does not matter. The principle does: you cannot turn the aircraft carrier. But you can launch a speedboat from the deck.
The Bottleneck Is Not Where You Think
Let me be precise about why the parallel approach works and the transformation approach does not.
When you try to transform the existing org, you are implicitly betting that you can change every function — engineering, QA, product, design, security, legal, operations, marketing — fast enough to avoid the bottleneck cascade. That bet has never paid off in the history of organizational change.
When you build in parallel, you start clean. You design every function for the AI-native reality from the beginning. You do not have to convince the security team to change their review process. You build a new security process for the new team. You do not have to retrain the QA organization. You hire engineers who own quality as part of their workflow. You do not have to negotiate with the change advisory board. You build deployment automation that makes the change advisory board unnecessary for the new product.
You do not have to fight with HR over comp bands and leveling frameworks that do not fit the roles you need. You build a hiring process designed for speed and signal — two structured interviews, one technical and one values, plus a compensated working session on a real problem. Every candidate evaluated against the same validated rubric regardless of background. The process is faster because it is focused, not because it is abbreviated. You do not have to wait for procurement to approve your tooling. You give the team a budget and let them buy what they need. You do not have to educate the legal team on why your deployment cadence changed. You build compliance into the pipeline so legal reviews the policy once, not every release.
You do not have to convince sales to change their process. The new product launches with a new sales motion — one designed for the market as it exists now, not as it existed when the original GTM playbook was written. And when the new product starts generating revenue, it does not validate the old process. It replaces it.
Every function that would have become a bottleneck in the transformation approach is designed correctly from the start in the parallel approach. Not because you are smarter. Because you are not dragging fifteen years of organizational scar tissue into the design.
The loyal organization keeps doing what it does. It produces revenue. It serves customers. It maintains stability. Honor that. The people inside it keep doing what they do — with respect, with fair compensation, with a clear understanding of where the company is heading and what their place in it looks like. No surprises. No Monday morning ambushes. You owe them that.
And slowly — over months, over a year or two — the new organization absorbs the loyal factory’s responsibilities. Not through a big-bang migration. Not through a layoff dressed up as a reorg. Through gradual, deliberate transfer of capability. The new factory builds the next product, then takes over the next service, then absorbs the next customer segment. People transfer when they are ready. Roles evolve as the work evolves. The humans come first, because they always should have.
By the time the loyal factory winds down, the new one is already running.
The Question Behind the Question
You are reading this and thinking: “This sounds right. But my board will not fund two organizations.”
They already are. You have an existing engineering budget north of $10 million, probably north of $20 million. A meaningful percentage of that budget is spent on coordination, communication, and overhead that exists solely because your organization is large and complex enough to require it. Meetings about meetings. Status reports about status reports. Program managers whose job is to understand why the other program managers’ projects are late.
The parallel factory does not need that overhead. A team of five to ten AI-native engineers with the right governance model will produce output comparable to a team of fifty to a hundred in the loyal organization. The economics are not theoretical.
We watched it happen. Nathan ran a SaaS platform with a growing codebase, a vendor dependency he could not escape, and an ownership group that wanted to hire ten more engineers at a fully loaded cost north of $2 million a year. Instead, he paired one engineer with AI-native workflows. Total spend for the year — engineers, tooling, reduced vendor costs, everything — came in under $500,000. Deployment cadence went from monthly to multiple times per week. The backlog that had been stacking up for years started clearing. A feature the previous vendor quoted at tens of thousands of dollars and a week of work was built in an afternoon.
The ownership group looked at the output and asked the question that should keep every traditional org awake at night: why would we hire eight more people? Read the full story →
You are not asking for more money. You are asking to redirect a fraction of your existing spend toward something that produces at a fundamentally different rate. Your board will understand that math. Especially when you show them what the parallel team ships in its first quarter.
Taking this to your board? Here is the memo template: Board Memo: Parallel Organization Investment Case →
Back to the Fifty Million
Let me come back to the question.
You do not have $50 million. You do not need it. You have your existing revenue, your existing IP, and the knowledge you have accumulated about your customers, your market, and your domain. That is worth more than $50 million because no competitor can replicate it.
What you need is the courage to stop trying to transform the untransformable and start building what comes next. The left hand keeps the loyal factory running. The right hand builds the future. Not in two years. Not after a readiness assessment. Not after the transformation office publishes its roadmap.
Now.
Your competitors are not waiting for their existing organizations to transform. They are building new ones. And the companies that will take your market share are not scrappy startups in a garage. They are well-funded, well-led organizations that started clean — with modern governance, AI-native engineering, and none of your organizational debt. Some of them used to be your peers. Some of them are being built right now by people who used to work for you.
If you are in a regulated industry — utilities, healthcare, financial services, defense — the threat is different but no less real. Nobody is disrupting the electrical grid from a co-working space. The barriers are physical, regulatory, and legal. But the threat is not disruption. It is erosion. Distributed energy eating your rate base. Fintech capturing your most profitable customer segments. CMS reimbursement changes that render your cost structure unviable. The timeline is longer than a software company’s product cycle. The consequences are existential in a way that a revenue miss is not.
Here is why the timing matters more than you think.
We have done this. We have been in the room where the parallel factory gets stood up. We have made the mistakes. We know what works and what looks good on a whiteboard but falls apart in week three. And here is what we can tell you: you do not have to get it right the first time. Not right now. Not in 2026. Right now, the industry is early enough that you can start, learn, adjust, and start again. Your first attempt will teach you more about your company than any assessment ever could. Your second attempt will be sharper. By the third iteration, you will have something real — something that ships, something that compounds, something your board cannot ignore.
But that window is closing.
If you wait until 2028 — if you spend the next two years on readiness assessments and steering committees and pilot programs that never graduate — you will not have the luxury of learning in public. By 2028, there will be a handful of companies that got this right. They will have case studies. They will have playbooks. They will have battle-tested leaders who have actually built AI-native organizations from scratch — not in theory, not in a workshop, in production. And those leaders will be on the market. Available. With experience your current leadership team does not have.
Your board is going to notice. They are going to look at the companies that moved in 2025 and 2026, and they are going to look at yours, and they are going to ask the question you do not want to answer: why did we wait?
And by then, you will have to get it right the first time. Because your board will not fund a second learning cycle. They will fund a new leader who already learned it somewhere else.
Right now, you have permission to experiment. You have runway to iterate. You have the rare advantage of being early enough that imperfect is acceptable — because everyone is imperfect. The industry is figuring this out in real time. There are only a handful of real transformation stories out there. That is your opening. That is your edge. Not that you know more than everyone else — but that you started before everyone else.
Do not waste that.
The loyal organization that survived your digital transformation, survived your agile transformation, and will happily survive your AI transformation — that organization is not the vehicle for what comes next. It is the funding source. It served you well. It kept you alive. The people inside it kept you alive. Now let it do what it does best — generate revenue — while the new thing does what it does best — generate the future.
Build the new thing. Fund it with the loyal thing. Run them in parallel until the new thing is ready. Then let the loyal thing rest. And take care of the people who carried it — because they carried you too.
That is not a strategy slide. That is what works.
The only question left is the one I started with. You have the IP. You have the customers. You have the revenue. What would you build?
If you know the answer — and I think you do — stop transforming. Start building.
Talk to Us
We map your value stream, stand up the parallel factory, and transfer it to you — AI-native governance, lean team, real output from the first sprint. Not a roadmap. Not a maturity assessment. Shipped software that moves a number your board cares about.
If the fifty million dollar question kept you reading this far, it is worth thirty minutes to talk through what the parallel factory looks like for your organization.
Book a Call — 30 Minutes, No Pitch Deck →
Related Reading
- Customer Zero: Two Engineers. One Year. More Output Than Ten.
- You Added AI. Congratulations — You Now Run a Slop Factory.
- The Financial Case for the Parallel Factory — The numbers behind the model. For CFOs, boards, and anyone who needs to answer “what does this cost?”
- Board Memo: Parallel Organization Investment Case — Taking this to your board? Here is the memo template.
- Executive Brief: The Parallel Factory Model — The one-pager you forward to a fellow board member.
- The Parallel Factory for Operations Leaders — What the model looks like when your factory has trucks and warehouses, not codebases.
- The Parallel Factory for Regulated Industries — Utilities, healthcare, defense, financial services — where the gates are federal requirements, not organizational scar tissue.
New here? Start with our guide to find the right articles for your role.