Software Operating Models Are Quietly Getting Rebuilt

The team-shape shift hiding inside every reorg

Walk through the engineering orgs that ship the fastest right now and a pattern shows up before anyone mentions strategy: fewer generalist squads, more tightly scoped platform teams, and a new layer of people who only exist to integrate. McKinsey's 2024 software productivity survey found that high-performing engineering organizations spend roughly 35% of capacity on platform and developer-experience work, nearly double the share at laggards. The takeaway is not "write more documentation." It is that the operating model is the product, and most teams have not updated theirs in five years.

The trigger is rarely a strategic memo. It is usually a runaway bill from a SaaS stack that grew by acquisition, a CI pipeline that nobody can debug, or an AI-assisted coding tool that changed the ratio of reviewers to authors overnight.

Build vs. buy is no longer the interesting question

Three years ago, the build-vs-buy decision consumed most architecture reviews. Today, the real question is what to wrap, fork, or configure. Stripe reported in late 2024 that more than 60% of new merchant integrations now start from a template rather than raw API calls. Linear, Retool, and a growing tier of internal-tools platforms have pushed the build option further down the stack, into the genuinely differentiating layers. For most product teams, that means the operating model has to decide where the boundary of "ours" actually lives.

What looks like a tooling decision is really a resourcing decision. Every hour spent customizing a third-party platform is an hour not spent on the part of the software that customers can feel.

AI is rewriting the cost curve, not the org chart

GitHub's own data shows that developers using Copilot merge pull requests about 55% faster on routine tasks, while the impact on architectural decisions is essentially zero. That asymmetry is the entire story. AI compresses the cost of writing and reviewing code, but it does not compress the cost of deciding what to write, how to test it, or how to ship it without breaking a regulated workflow. The teams that absorb this cleanly treat AI as a capacity expander for the boring 70% of their backlog, then reinvest the savings into fewer, sharper product bets.

The teams that lose are the ones who treat faster code review as a license to take on more surface area. They end up with more software, not better software, and the operating model has no answer for it.

Implementation trade-offs the slide deck will not show you

Most operating-model redesigns fail at the migration phase, not the design phase. Three trade-offs recur in the post-mortems of teams that botched them. First, platform consolidation: centralizing tooling looks efficient on a spreadsheet, but every migration is a tax on the engineers who have to do it. Second, the on-call rotation: shifting from product-aligned to platform-aligned incident response can cut mean time to recovery by 40% according to incident.io benchmarks, but only if you also rewrite the runbooks. Third, vendor lock-in as a feature: the same API that lets you ship in a quarter is the one that makes a re-platform cost a year. Leaders who pretend this trade-off does not exist tend to discover it during their next financing round.

The honest version of the operating-model conversation includes a line item for the cost of changing your mind later. Most do not.

What the next eighteen months actually look like

Expect three shifts to compound. First, more engineering budgets will move from headcount to software spend, which means procurement and architecture are about to share a seat at the table. Second, the "platform team" label will keep spreading downward into mid-market companies, where the function used to live inside a single senior engineer's calendar. Third, the metric boards will change: DORA metrics will be augmented, not replaced, by cost-per-merged-PR and AI-attributed throughput, and the companies that instrument those early will set the hiring bar everyone else chases.

Teams that publish engineering benchmarks publicly, including through a single-checkout publishing setup like the one at Osmosis, are starting to treat operating-model transparency as a recruiting advantage rather than a leak.

The operating model is the most consequential piece of software a company builds, and unlike the rest of the codebase, it ships without a changelog.

For teams looking to ship this without the operational overhead, the end-to-end publishing setup is a useful reference.