Two Portfolio Companies Cut to Five-Person Engineering Teams. Only One Keeps the Savings.

Two portfolio companies can make that cut in the same year and book the same reduction. When the buyer's technical team arrives, one hands over a repository and a measured number. The other has to send a person into the room, and the buyer prices what happens when that person leaves.

Gartner made the structural call on July 7: 60% of organizations will adopt smaller software engineering teams at scale by 2029, up from 15% in 2026. Today's version runs four to five people, and Gartner expects teams of two to three to become more common as engineer skills and AI capability mature. Fifteen percent is the operative half of that pair. Most of the market has not moved, so the structure is still a differentiator, and that window closes over the next three years.

Gartner is careful about the framing. "Tiny teams are not a cost optimization tactic," the release states. "This is a restructuring of teams to best take advantage of both human and AI capabilities and strengths." It is equally specific about what the restructuring requires: "As tiny teams are supported by robust platform engineering teams, they can focus on high-value work by providing standardized, automated workflows and self-service AI tools and capabilities."

The same release cautions that slowing junior-level hiring inhibits knowledge transfer and pushes recruitment toward more expensive senior roles, and predicts that by 2028, organizations that rely on AI to cut junior roles will hollow out their own software engineering talent pipeline.

Two weeks earlier, on June 24, Gartner forecast that AI coding costs will overtake the average developer's salary by 2028.

Engineering is one of the largest controllable cost lines in a software company and one of the few EBITDA levers that works without a market cooperating. Bain's Private Equity Midyear Report, published June 8, explains why that matters more this vintage than last. The implied capital cycle now runs roughly seven years, well beyond historical norms. A deal that would have gotten by on 5% annual EBITDA growth a decade ago now requires 12% over a five-year hold to produce the same 2.5x. And software marks inside PE portfolios fell roughly 8% in the first quarter of 2026, 8.9% in the US.

The unit is five people. The operating system around it is not.

Gartner's platform-engineering condition is the part most likely to get skipped in a portfolio setting, because it reads as overhead. Capability moves out of the product teams into a shared function: standardized delivery, automated environments, security guardrails, observability, and the internal AI tooling the small teams consume. A sponsor who models this as every product team dropping to five people, with nothing else changing, discovers the shortfall only after the smaller teams are already carrying it, where it presents as a talent problem and gets solved by hiring.

DORA's 2025 report arrives at the same place from a different direction. Ninety percent of organizations now run an internal developer platform, and 76% have dedicated platform teams. But DORA's finding is conditional on quality rather than presence: where platform quality is high, the effect of AI adoption on organizational performance is strong and positive, and where it is low, the effect is negligible. DORA also associates higher AI adoption with greater delivery instability: acceleration without strong automated testing and fast feedback loops turns additional change volume into additional risk.

This sets the real test of the model, and it is an accounting test. The cost of moving from six product teams to one platform function is amortized rather than removed. The margin case holds only where the platform serves enough teams to pay for itself. A single-product company running one five-person team and a four-person platform group has reorganized its org chart while keeping its cost base. Token spend belongs in the same reckoning: smaller today, with no guarantee it stays small. Gartner's June 24 read is that developers optimize for speed over cost, so token discipline will not arrive through their choices alone.

Carry the engineering line fully loaded: salary, inference, the platform function, and the guardrail and observability infrastructure the model depends on. Those numbers frequently sit in separate cost centers and are rarely evaluated as one fully loaded engineering line, which is how a real 40% reduction gets presented as a 55% one.

Gartner's junior-hiring caution runs on a different horizon, and its finding is narrower than the version usually quoted: an organization that stops developing juniors hollows out its own pipeline. The industry-scale version follows on its own logic. If enough companies make the same choice, the shared senior-talent market eventually thins, on a clock longer than any single hold. A portfolio company still has to decide what structure it can sustain across its own hold without creating a liability a buyer will price. Both concerns are sound, and they sit on separate balance sheets.

Which leaves the objection that carried real weight for twenty years. It has moved.

The case against small teams was always concentration: systems end up with one person who can safely change them, and losing that person costs two quarters. Part of that has weakened materially. In my experience, a coding agent reconstructs an unfamiliar service faster and more completely than a newly assigned engineer managed a few years ago, and it does it again next week without fatigue or memory drift. What it cannot reconstruct is the commercial, regulatory, and architectural context that never entered the artifacts.

Key-person risk relocated. It used to live in code comprehension, and it now lives in decision context, and that relocation is the entire argument for small teams. A storage problem is directly engineerable. A human comprehension bottleneck was far more expensive to engineer around.

Ask a coding agent why billing reconciliation runs as an hourly batch instead of an event stream. It will accurately describe the batch, trace the job, explain the retry semantics, and provide a migration plan. Every word of it is correct, and the answer is still wrong, because the reason is a vendor rate limit negotiated three years ago, and that fact was never committed to the repository.

That gap is the portion of residual risk the codebase cannot address, and it is narrower than the concentration problem it replaces. Vendor terms, a commitment made during a renewal, a regulatory interpretation counsel signed off on, an architecture tried in 2023 and abandoned for a reason nobody wrote down.

The repair is a decision record committed with the change that implemented it, retrieved whenever an engineer or an agent touches the system. Staffing redundancy alone is an expensive and unreliable substitute for durable decision context. A second engineer provides review, coverage, and judgment, but a critical constraint should not depend on either person remembering it correctly, and a file does not misremember or take another job.

Three other inputs set how fast a stranger can work, and in most portfolio companies they matter more than documentation does.

Tests that state the contract. A suite that asserts intended behavior lets an engineer or an agent safely change a system on day one. A suite asserting current behavior locks in whatever happens to be there, turning every change into an archaeology project. Mid-market portfolio codebases frequently have the second kind, built against a coverage target instead of a contract, and pointing an AI agent at a coverage percentage makes it worse fast: assertions that mirror existing behavior are the easiest thing in the world to generate and the least useful thing to own.

Environment reproducibility. Time from a clean machine to the system running locally against realistic data. In mid-market portfolio companies, it is often measured in days; it rarely appears in the operating review, and no volume of documentation moves it.

Blast radius containment. On money, authentication, and tenant isolation paths, whether a wrong change is caught by the system or by a person who remembers. A five-person team moves at the speed the structure promises only when the guardrails are mechanical. The clearest return on the list, most often deferred, because it ships nothing a customer can see.

Buy-side technical diligence asks for a walkthrough of those same systems. The standard answer is a person, and a person is what gets priced: their tenure, their retention package, their willingness to stay through an integration. A company that has built the context layer hands over the repository, the decision records, and a measured number for how long an engineer who has never seen the system needs to ship a safe change to it. That gives a buyer the evidence to reduce a discount its peers still carry, and a seller who starts early enough in the hold has time to build it.

Whether in-repo decision records escape the fate of every other documentation practice, which is drift, I have not watched run long enough to say. The argument for them is that the agent reads them on every task, so a stale record produces a visibly wrong answer within days instead of surfacing during an incident two years later. Plausible mechanism, unproven.

The metric. Elapsed time and active engineering effort for a competent engineer with no prior exposure to a system to implement, validate, deploy, and observe a predefined change to it, using the tooling the team has in front of it. Track both. Elapsed time prices the process; active effort prices the code, and a wide gap between them points at a release window instead of at comprehension.

What safe means. The change passes contract and security tests, clears normal review, reaches production or a production-equivalent environment, carries an observable success criterion, and rolls back mechanically. A company unable to meet all five on a routine change has found something more urgent than its team size.

How this differs from what you already track. If the company runs DORA metrics, change lead time is the closest relative and the floor under this number. DORA starts counting at the commit, so it measures how efficiently an identified change moves through the delivery system. It does not measure the work before that commit: locating the change, understanding what it depends on, recovering the decisions behind it, and establishing what constitutes safe behavior. The Replacement Clock introduces an engineer with no prior exposure and is priced accordingly. A company with strong lead times and a long clock has an efficient pipeline and a transferability problem, and its existing dashboard will not show it.

Measure per system and report per system. The clock varies more across services within a single company than across companies, because a CRUD service and a deeply integrated legacy billing path are different problems. A blended number hides the weakest critical path, and that is the one a buyer asks about. One exercise gives a first baseline; board reporting wants the median of several comparable changes on that same system.

1. Environment reproducibility. Clean machine to running system with realistic data. The floor under everything else, and a three-day setup makes every other improvement invisible.

2. Contract tests. Whether the suite asserts what the system is supposed to do or what it currently does. This is the difference between a small team and a slow one.

3. Decision records. The vendor limit, the alternative rejected, the condition under which the call should be reopened, captured when the decision was made. It preserves context that neither the code nor its runtime behavior can reconstruct.

4. Blast radius. Whether a wrong change on a money, auth, or tenant path is caught mechanically. This sets how fast the clock can safely run.

Track it as a value creation metric. Moving a critical system from six weeks to four days takes multiple quarters of platform work that also makes the current team faster. It also settles the argument that team size otherwise turns into. A company that has moved its clock that far has materially reduced its concentration risk and strengthened the case for a smaller team; a company still measuring in weeks carries concentration whether it employs fifteen engineers or fifty. No threshold holds across systems, which is why the movement is the evidence rather than the number. The clock stays silent on the rest of that case: roadmap load, on-call coverage, and whether the engineers you have want the product ownership the structure hands them.

1. Measure the clock on one critical system before the next board meeting. Run a timed exercise, not a survey. Take a recent hire or a contractor, pair them with the coding agent the team uses, hand them a predefined change to the billing or authentication service, and record elapsed time and active hours until it reaches production safely. Start with one system and one bounded change, and let it run as long as it runs; the exercise finishing slowly is the finding. Repeat with two comparable changes on that same system before the number goes in a board deck.

2. Make decision capture a merge requirement on the critical paths. Any change to a money, authentication, or tenant isolation path carries a short record: the constraint that shaped the decision, the alternative rejected, and the condition under which it should be reopened. Four sentences, written by the engineer who made the call, committed with the code. Cheapest item on the list, and it preserves context that neither the code nor its runtime behavior can reconstruct.

3. Re-point the test suites on those same paths from coverage to contract, and drop coverage percentage from the operating review. Coverage measures how much code executes during a test run, and AI-assisted test generation has made it weaker still as evidence that intended behavior is protected. Keep it as an engineering diagnostic if it earns its place there; what makes a small team safe is a suite that fails when the system stops doing what it promised. Rewriting the assertions on three or four critical services is a quarter of work with a permanent return, and the largest lever on the clock after the environment.

Fund all three as value creation line items with named owners and dates. Filed as engineering hygiene, they lose every prioritization fight, because nothing customer-visible ships at the end.

Your Replacement Clock: one metric, reported separately for billing, authentication, and tenant isolation. Days, measured this quarter, measured again in six months, and tracked in the value creation plan beside the revenue initiatives.

No credible external benchmark exists yet, so the comparison that carries weight is against your own prior reading. A clock that falls while headcount falls is a margin improvement a buyer can underwrite. A clock that holds flat while headcount falls is the version of this trade that gets discounted at exit.

Portco Brief translates one technology signal a week into an enterprise-value decision for operating partners and portfolio CEOs, CFOs, COOs, CTOs, and Technology Leaders. Forward it to the operator who keeps saying the audit came back clean.

Sources: Gartner, "Gartner Predicts 60% of Organizations Will Adopt Smaller Software Engineering Teams by 2029," July 7, 2026. Gartner, "Gartner Predicts AI Coding Costs Will Surpass Average Developer's Salary by 2028 as Token Consumption Surges," June 24, 2026. Bain & Company, Private Equity Midyear Report 2026, June 8, 2026 (software valuation data attributed by Bain to MSCI). DORA, State of AI-assisted Software Development 2025; DORA, "Platform Engineering"; and DORA's published definitions of its software delivery performance metrics.

Subscribe at portcobrief.com.