Here is a meeting that happens every two weeks at a portfolio company near you. Eight people sit in a room (or, more likely, a Zoom). There is an architecture review board, or a change advisory board, or a technical steering committee. The names vary. The ritual does not. Someone presents a proposal. The group asks a few questions. The proposal is approved. Everyone leaves. Nothing changes.
I have sat in dozens of these meetings across PE-backed engineering organizations. I have never once seen one of them kill a project.
That is the tell. If your governance body has a 100% approval rate, it is not governing anything. It is notarizing.
The approval machine
Most engineering governance frameworks are designed around a single function: saying yes. An architecture review board exists to bless a design before it moves to implementation. A change advisory board exists to approve a release before it hits production. A steering committee exists to nod along to a quarterly roadmap that was finalized before the slide deck was opened.
These bodies feel like governance because they have the trappings of it. There are agendas, attendees, minutes, action items. There is a process. There is a cadence. There is even, occasionally, a spirited debate about naming conventions or API versioning. But the fundamental question of governance, "should we be doing this at all," almost never gets asked. And when it does get asked, the answer is always yes, because by the time something reaches the review board, enough people have invested enough effort and enough political capital that killing it would be more disruptive than letting it proceed.
This is governance as theater. And both PE operating partners and engineering leadership are complicit in staging the production.
Why nobody kills anything
Canceling work in progress is the hardest decision in engineering leadership. It is harder than a layoff, harder than a reorg, harder than adopting a new tech stack. A layoff is painful but legible: the business needs to cut costs, and everyone understands the logic even if they hate the outcome. Canceling a project that a team has been working on for six months tells that team, and its leadership, that the work was a mistake. That the judgment that initiated it was wrong. That the resources consumed are a sunk cost.
Nobody wants to be the person who says that out loud.
So instead, troubled projects get "rescoped." They get "reprioritized." They get moved to a different team, or folded into a larger initiative, or quietly shifted from "strategic investment" to "maintenance mode" where they can die slowly enough that no single person has to sign the death certificate. I once watched a platform rewrite consume 18 months and seven engineers before anyone with authority acknowledged what every IC on the team already knew: it was never going to ship, because the requirements had shifted so far from the original justification that the project no longer solved a real problem. It didn't get canceled. It got "paused indefinitely." The JIRA board is probably still open.
This avoidance has a name in behavioral economics: escalation of commitment. But in portfolio companies, it has a more specific cause. Engineering leaders don't kill projects because killing projects makes them look bad to operating partners. Operating partners don't force the issue because they don't have enough technical context to know which projects deserve to die, and they don't want to undermine the CTO they just hired. The CTO doesn't kill projects because they inherited most of them and don't want to start their tenure by telling the board that their predecessor's strategy was wrong. So everyone agrees that the infrastructure migration is "on track," the platform modernization is "making progress," and the data pipeline rewrite will deliver value "next quarter."
The governance committee meets. The governance committee approves. The money keeps burning.
What governance actually requires
Real governance is not an approval workflow. It is an accountability structure that should have teeth. The distinction matters because approval workflows optimize for throughput (how many decisions can we ratify per meeting?) while accountability structures optimize for outcomes (are we spending engineering capacity on the right things, and are we willing to stop when the answer is no?).
A governance body that works needs three things that most engineering organizations will resist giving it.
The authority to cancel. Not to "recommend deprioritization." Not to "raise concerns for leadership consideration." The explicit, recognized authority to stop work in progress. This means the governance body needs a mandate from whoever controls the budget, which in a PE context usually means the operating partner or the board. Without that mandate, the body is advisory, and advisory bodies get ignored the moment their advice becomes inconvenient.
Access to real data. Most governance meetings run on slide decks prepared by the people whose work is being reviewed. This is like asking a defendant to write the prosecution's case. Effective governance requires independent access to engineering metrics: actual cycle times, actual deployment frequency, actual cost run rates, actual progress against milestones measured in working software rather than percentage complete. If the only information the governance body sees is filtered through the team it's supposed to be governing, the body is captured before it starts.
The political cover to use both. This is the piece that almost everyone skips. You can grant a committee the authority to kill projects and give it access to every dashboard in the organization, and it will still rubber-stamp everything if the people on it face career consequences for making unpopular calls. The operating partner has to make it explicitly safe to say "this isn't working and we're stopping it." Not safe in the abstract, feel-good, "we have a blameless culture" sense. Safe in the specific sense that the person who recommends killing a $2M infrastructure migration will not find themselves managing a smaller team next quarter.
The projects that need killing
If you run an engineering organization of any meaningful size, you have at least one project right now that should be dead. You probably know which one it is. Here are the patterns I see most often:
The zombie migration. A database migration, cloud migration, or platform migration that started with a clear business case, hit unexpected complexity in month three, and has been "almost done" for longer than the original timeline. The team working on it is demoralized. The business case has eroded because the cost has doubled and the competitive landscape that motivated it has shifted. But stopping it feels like admitting the whole thing was a mistake, so it continues.
The jobs program. A platform, internal tool, or framework that exists primarily because a senior engineer or engineering manager built their identity around it. It may have been justified at inception. It is no longer justified by the value it delivers relative to the engineers it consumes. But the person who owns it has organizational power, and nobody wants to have that conversation.
The hedge bet that became a commitment. Someone said "let's spike on this for two weeks and see if it's viable." That was eight months ago. The spike became a prototype, the prototype became a project, the project acquired a product manager and a roadmap, and now it has enough organizational gravity that killing it requires an executive decision that nobody is willing to escalate.
In every case, the pattern is the same. The information that the project should stop exists at the team level. It flows upward in diluted form, through status reports and steering committee updates, until it arrives at the governance body as "the project has some risks we're actively managing." The governance body, which meets for an hour every two weeks and reviews six other projects in the same session, has neither the context nor the incentive to challenge that framing.
Governance as a forcing function
The fix is not to create a better committee. It is to build a governance mechanism that forces the uncomfortable conversations before the money is gone.
In practice, this means something closer to an investment review than an architecture review. Every major engineering initiative, anything consuming more than a threshold of engineering capacity over more than a quarter, should face a periodic continuation decision. Not "is this project on track" but "knowing what we know today, would we start this project from scratch?" If the answer is no, the default should be to stop, and the burden of proof should fall on continuing, not on canceling.
This is how PE firms evaluate their own portfolio companies. They don't hold an asset just because they bought it. They hold it because the forward-looking return justifies the capital. Engineering work should face the same test. The sunk cost is gone. The only question is whether the remaining investment will generate the expected return.
I realize this sounds obvious when stated as a principle. The reason it doesn't happen in practice is that applying it requires someone to sit across from a team that has been working hard on something for months and tell them the work is stopping. It requires that person to absorb the anger, the disappointment, and the political fallout. It requires a leadership culture that treats killing a bad project as an act of responsible stewardship rather than a failure of vision.
Most governance bodies are not built for this. They are built to distribute responsibility so widely that no individual has to bear the weight of a hard call. The approval is collective. The accountability is diffuse. And the project that everyone privately knows should be dead gets another quarter of runway, because the committee met and the committee approved and the process was followed.
The cost of politeness
There is a number attached to this dysfunction, and it is larger than most operating partners realize. I have seen portfolio companies carry three to five zombie projects simultaneously, each consuming two to five engineers, each producing little to no business value. That is potentially 10 to 25 engineers, in an organization that might have 50 to 80 total, doing work that the organization's own leadership would not fund if they were making the decision fresh.
Run that math against fully loaded engineering compensation. Then add the opportunity cost of what those engineers could be building instead. Then add the cultural cost: the corrosive effect on morale when good engineers are trapped on a project everyone knows is going nowhere, watching the governance committee smile and approve the quarterly update.
That is the price of governance without the willingness to govern.
A challenge, not a framework
I am not going to close this with a neat five-step process for fixing your governance structure, because the problem is not structural. You can redesign the committee, change the cadence, update the templates, and add new metrics to the dashboard. None of it matters if the humans in the room are unwilling to do the thing that governance exists to do: make a decision that somebody won't like.
If you're an operating partner reading this, ask your CTO a simple question at your next board meeting: "Which engineering projects have we killed in the last 12 months, and why?" If the answer is none, you don't have governance. You have a calendar invite.
If you're a CTO reading this, look at your portfolio of active engineering work and ask yourself which projects you would not start today if you were starting from zero. Then ask yourself what, exactly, is stopping you from ending them. If the answer is "the governance process" or "the steering committee," the governance process is the problem, not the solution.
The hardest part of running an engineering organization is not deciding what to build. It is deciding what to stop building. Governance that cannot do the latter is just overhead with a meeting agenda.