The Carbon Manifesto

The Operating Model Is the Asset

Seven beliefs about how modern companies are built, and why the ones pulling ahead are structured differently from the ones they are leaving behind.

Companies have never spent more on technology and got less back where it counts. The big technology firms are now pouring more than four hundred billion dollars a year into AI infrastructure, the largest private capital build-out in history. Profits are at record highs. And yet productivity, the actual output a company gets from an hour of work, has grown at a fraction of its old pace for the better part of two decades. Three things that should not all be true at once, and almost never get put in the same sentence.

The easy answer is to point at timing: we are still early in the cycle. Possibly. But the last twenty years have already run this experiment, more than once. Cloud, mobile, software as a service: each arrived, got bought at enormous scale, and took years to show up in the numbers. When it did, the gains belonged almost entirely to the handful of companies that had rebuilt themselves around it. The rest of the market bought the same tools and changed nothing else. Technology was never the missing piece.

The constraint has never been capability. It has always been the operating model: the whole machinery of how a company actually runs. That is the asset. Not the headcount, not the tooling, not the org chart. Get it wrong and nothing downstream can fix it.

What follows is seven beliefs. They are the foundation Carbon is built on. They are drawn from engineering and the work that runs on top of it, because engineering felt the change first, so the pattern is clearest there. But they do not stay there. Nearly every company now runs on software it builds or wires together itself, which makes nearly every company a technology company in the part that is actually changing.

These are not forecasts. They will not be much use to anyone looking for permission to leave things as they are.

01. The operating model is the asset

Most companies optimise the org chart. They move reporting lines, rename divisions, fold one team into another, and call it 'transformation'. But an org chart is a photograph. It tells you who sat where on the day someone drew it, and very little about how the company actually runs.

The operating model is the layer underneath: how decisions get made, where work runs, who does it with what tools, and how the output compounds. Two companies can have the same org chart and the same headcount and run at completely different speeds, because what sets the speed was never on the chart.

This is the part most leadership teams get wrong about technology. They buy the tools, run the pilots, drop the new capability onto the existing workflow, and the workflow does not change. What they get back is the old process, a little faster in a few places, plus a new line item on the budget. A pilot that never reaches production is not a technology failure. It is an operating-model failure, and you cannot buy your way out of it with more tooling. The companies that pull ahead come at it from the other direction entirely, starting with the work and rebuilding it around what the new capability actually makes possible. Same tools, off the shelf, available to anyone with a credit card. What separates the outcomes has nothing to do with access. It comes down to who did the work of restructuring and who did not.

None of this is a hunch. It is one of the better-documented findings in productivity economics. Working through several million company accounts across two dozen economies, OECD researchers found that the most productive firms in each industry kept pulling away while everyone else stalled, and that the gap between the frontier and the rest widened for the better part of two decades. The interesting part was why. The divergence held up even after you accounted for what the firms had spent their money on, the machinery and equipment and software and research, which means the leaders were not winning on what they had bought. They bought from the same vendors as everyone else. They were winning on what they did with it. The technology spread freely; the ability to reorganise around it did not, and that gap compounded year after year.

So the operating model is the asset in a fairly literal sense. It compounds, because each workflow you rebuild makes the next one cheaper, which is why the frontier accelerates while everyone else flattens out. It is almost impossible to copy, because a competitor can buy your exact tools tomorrow and still not run the way you run. Everything else sits on top of it. Headcount, tooling, strategy, all of it runs on the operating model, and when the model is wrong there is no amount of spending further up the stack that fixes what is broken at the base.

If the operating model is the asset, then the typical company is running on a broken one.

02. Most engineering organisations were never designed

Most companies know their engineering organisation is not performing the way it should. Almost all of them are wrong about why.

The usual answer is that it got too big. That is the easy version, and people reach for it because headcount is the simplest thing to count and the simplest thing to cut. But size is rarely the disease. There are small teams that are badly built and there are very large ones that run beautifully. The problem is hardly ever how many people there are. It is how they were put together, where they sit, and what they were brought in to do.

Most engineering organisations were never properly designed at all. They just happened. Headcount went in during hiring booms to take the pressure off, contractors got layered on to cover gaps, teams formed around whatever tool was in fashion rather than around any particular outcome, and the whole arrangement ended up shaped, to the extent it was shaped on purpose, for a way of working that the technology has long since moved past. What you are left with is an organisation full of perfectly capable people doing work the structure around them makes slower than it ought to be. Talent is rarely the issue. More often than not, the wiring is.

Two patterns turn up almost everywhere. The first is capacity hired to fill seats, roles added to push more throughput, staffed to a budget rather than to a bar, on the old assumption that more hands mean more output. They do not, at least not in a straight line. Coordination cost climbs faster than headcount, a thing Fred Brooks described fifty years ago and that has not stopped being true, and past a point the team spends a growing share of its energy managing itself rather than on the work. Strong people hit that wall later than average ones, but they still hit it eventually. Size is something to design, not accumulate.

The second pattern is geography. Engineering gets anchored to wherever the company happened to start, or to whichever expensive city it decided it had to fight in for talent. That constraint was once real. It has mostly dissolved. The talent has spread to places the old hiring map never bothered to look, and the quiet assumption that "our engineers" must mean engineers within driving distance of headquarters is a premium a lot of companies are still paying without ever noticing the bill.

Put those together and the typical engineering organisation comes into focus. Bigger than it needs to be. Built around who was available rather than who was good. Tied to a location that stopped mattering as much years ago. Running, underneath all of it, on an operating model from an earlier era. None of which is the fault of the people inside it, who are mostly doing their best inside a structure that was never built for the work they now face. And because it took years to grow into its current shape, they are in a poor position to tear it down and rebuild it from the inside. That is the harder problem, and the one most companies never get to the bottom of.

03. AI rewards mastery

If the typical engineering organisation is built wrong, the question is what the right one looks like. It is not the same thing, only smaller. Cut a bloated team in half and you have a smaller bloated team. The shape that wins is different in kind: a small number of genuinely strong engineers, fluent in the tooling, organised around the work rather than around the headcount budget. Fewer people, each producing a great deal more, and the leanness comes out as a result rather than a target anyone set.

This cuts against the old instinct that more engineers mean more output. It also cuts against the newer and louder one, that AI has made any engineer productive enough that talent no longer matters much. Both are wrong, and the most-cited piece of evidence on AI tooling, the one usually read as proof that it does not work, turns out to show why.

When researchers ran a controlled trial of experienced developers on current AI tools, the developers expected to come out roughly a quarter faster. Afterwards they were sure they had. They were actually about a fifth slower, the time the tool saved coming straight back out in reviewing and correcting output that was almost, but not quite, right. That looks like a case against AI. It is the opposite. It is a case against bolting AI onto a way of working you have not changed. Look at who did get faster: the one developer who had already put serious hours into the tool. The gain was real. It was sitting behind a wall of mastery the others had not yet climbed.

That is the part that should govern how you build a team. The tool is an amplifier, not a leveller. It does not close the distance between a strong engineer and an average one, it widens it, because it multiplies whatever judgment is already there, and judgment is most of what separates a good engineer from a passable one. The highest-output organisations have noticed, and keep drifting towards the same shape: small teams of strong engineers who treat the tooling as native ground, inside a structure built around it rather than forced to tolerate it. Output per person runs high enough to keep the team small, and the team stays small enough that coordination does not eat the gains.

The catch is that almost no existing organisation can assemble this from where it stands. It takes a calibre of engineer most companies struggle to hire, a fluency most teams have not built, and a structure the current one will actively fight. Which is exactly the problem the next belief runs into.

04. No organisation resets itself

A company can read all of this, nod along, and still not change. It can accept that the operating model is the asset, that its own is built wrong, that the answer is a smaller team of strong engineers built around AI. It can decide, in good faith, to become that company. And it will almost certainly fail anyway. Not because it didn't mean to. The reason is structural, and intent has almost nothing to do with it.

The transformation industry has a favourite number, that seventy percent of transformations fail. It has been passed around for decades, and when anyone goes looking for the source, there isn't a solid one. It survives because it is useful to the people selling the cure, and because it matches what everyone has seen happen. The figure is invented, but the thing underneath it is real enough: most transformations come in well short of what they set out to do. And they come up short for the same reason almost every time. The company changed the tools, the org chart, the processes, and left the way people actually work exactly where it was.

This is the part almost everyone underrates. A new operating model is not a new diagram. It is a change in what people do on a Tuesday afternoon, the habits they fall back on, the calls they make without thinking, what they have quietly decided is normal. That layer does not budge because someone announced a transformation at an all-hands. It moves only when the behaviour around it is rebuilt, and behaviour is the thing an organisation is worst at changing about itself.

The reason is incumbency. The people who would have to run the reset are usually the same people whose roles, status, and daily routine the reset puts at risk. Tenure protects itself. Every process that exists has someone whose job is to keep it running, and a reorganisation that threatens the process threatens them too. None of this takes bad faith. It is just the ordinary behaviour of an organisation defending how it already works. Asking a company to reset itself from the inside means asking it to overrule its own instincts. And the tooling only pays off once that reset is real, because the tools sit on top of the old behaviour until the behaviour itself is rebuilt, and the old behaviour wins.

So you end up with a company that knows what it needs but can't easily build it alone. It has tried already, and watched the attempt stall. The question stops being what to build. It becomes who can build it, and then leave.

05. If you can't measure the uplift, it didn't happen

Everything up to here is a claim about what works. None of it counts until you can point to what changed.

This is where most transformations quietly come apart, and where the industry would rather not look too closely. A programme kicks off against a business case. The budget is approved, the team is staffed, the tools are brought in, and there is no shortage of activity to point at. But the business case is rarely reopened. Success gets declared on the strength of motion, the pilots that ran and the systems that shipped and the demos that landed well, while the question that actually matters, whether the thing that justified the spend has moved, tends to go unasked. It goes unasked because asking it is the one step that can turn a celebrated programme into a failed one.

The more honest approach is to ask it anyway, and to do so before the work begins. Every engagement should open with a number it is accountable to: the cost it should take out, the cycle time it should cut, the output it should lift, the revenue it should free. Not a general ambition to improve things, but the specific figure that made the spend worth approving in the first place. That number becomes the contract with reality. If the work moves it, the work happened. If it does not, then whatever else was produced along the way, the work did not do what it was there to do.

Measuring it honestly is hard. Pulling apart what the work moved from what the market moved, from the reorganisation that landed the same quarter, from the other things leadership changed at once, takes real effort and rarely comes out perfectly clean. But difficulty is not usually why the question gets skipped. More often, the difficulty becomes the reason not to ask at all. A number you have committed to can be missed, whereas a vague ambition cannot, and that is what makes vagueness so useful to anyone who would rather not be measured. Avoiding hard measurement is rarely carelessness. It is closer to caution, of a kind that protects the firm doing the work rather than the client paying for it.

The opposite approach is harder, because it lets you fail in public. Define the business case before anyone designs a system, benchmark against it, and report what actually happened, whether or not it flatters the people who did the work. That is uncomfortable by design, because it means the work can be judged against a line drawn at the start rather than one quietly moved to meet the result. It is also the only version of this work worth doing. An uplift you cannot show in a number the business already cares about is not really an uplift. It is a story about one.

Which puts a test under everything the earlier beliefs described. The operating model, the small high-output team, the cultural reset, all of it has to clear the same bar in the end: did the number move. A worldview that cannot be measured is just an opinion.

06. Ownership beats access

The market is full of firms and platforms that will rent you a capability. Almost none of them will leave you owning it.

This is the part of the model that matters most and gets talked about least. When a company brings in outside help to build something, whether because it cannot build it alone or simply needs the capacity, it walks into a choice it rarely makes on purpose. Either the capability stays with the firm that built it and the company keeps paying for access, or the capability comes across and becomes the company's own. The first is the default almost everywhere. It is how SaaS works, it is largely how the frontier models are sold, and it is increasingly how service providers position themselves: for the ongoing relationship rather than the finished job. For commodity infrastructure that is a perfectly good arrangement. For anything close to how the business actually runs, it is a poor trade, and the reason is structural rather than anything to do with goodwill.

Rented capability rarely compounds for you, and it stops the day the relationship does. This is not an argument against using outside firms or tools. It is a question about where the long-term value ends up. Everything the earlier beliefs were about, the rebuilt operating model, the small high-output team, the cultural reset that finally holds, is valuable precisely because it compounds inside the company over time. A capability that lives inside a vendor compounds for the vendor. The client gets the output and never the thing itself, and when the engagement ends, what was learned walks out with the people who were holding it. The company is back roughly where it started, only now it is dependent. Access makes you a tenant. Ownership makes the asset yours. Only one of them is building anything that lasts.

This is what Carbon is built to deliver, and it takes two shapes because the work does. When the thing that has to be rebuilt is the engineering organisation itself, the model is build, operate, transfer. We assemble the capability, teams of strong engineers, native to modern AI tooling, organised around the work, run it ourselves until it is hitting the standard the business case asked for, and then hand it over. The team, the systems, the way of working, all of it becomes the company's own. When the thing that has to be rebuilt is a workflow buried somewhere inside the business, the shape is different but the principle does not change. The capability gets built around the client's own operation, runs on the client's own infrastructure, and stays there when the project is handed over. Either way the engagement is finite by design. The point was never to wire ourselves permanently into the client's operations. The point is to leave behind something the client owns outright and can run without us.

This turns the usual incentive on its head. A firm paid for access has every reason to make itself necessary, to cultivate the dependency that keeps the meter running. A firm paid to transfer has to make itself unnecessary, to build something solid enough to hand over and walk away from. We are built around the second incentive, because it is the only one that points the same way the client does. The measure of the work is not how long we stay. It is what is still standing after we have gone.

Which points back at the thing underneath all of it. What was ever worth owning was not the model, or the tool, or the licence. It was everything built around them.

07. The model was never the hard part

The model is where all the money is going. That spending is exactly what is turning it into a commodity, which is why it matters least.

Hundreds of billions are pouring into building better models, and the competition between the frontier labs is about as fierce as anything technology has seen. It is natural to assume the thing the whole industry is straining to build must also be the thing that decides who wins.

When a crowd of well-funded competitors all build near-identical versions of the same thing, the price drops and the gaps between them close. That is not some risk hanging over the model business. It is the predictable result of it, and it is already well underway. The cost of running a capable model has fallen something like tenfold a year. Open-weight models out of China now do most of what the expensive ones do, and the distance between the leading model and a cheap or open one has narrowed to the point where, for the capability most businesses actually need, it rarely decides who wins. Several companies will sell you one. You can stand up a near-frontier model on your own hardware for the cost of the hardware. There will always be a frontier worth paying for, some hard edge of capability the labs are still fighting over, but it is a thin slice, and almost no company's advantage was ever going to come from owning it. The ferocity of the competition is not a sign that the model is the prize. The war is being fought to commoditise the very thing it is being fought over.

We have run this play before. Electric power was one of the great capital races of its age, with fortunes poured into dynamos and generating stations. And for roughly three decades after the factories electrified, productivity barely moved. The owners had pulled out the steam engine, dropped an electric motor in its place, and changed nothing else about the building. The real gains did not arrive until the 1920s, once factories were finally redesigned around what electricity allowed, every machine with its own motor, the floor laid out for the flow of the work instead of the reach of a central driveshaft. Everyone had electricity. The advantage was in rebuilding the work around it.

The same thing is true now, for the same reason. If everyone can reach the same models, the model is not where your advantage comes from. The advantage is in everything built around it, the workflow it runs inside, the data it can reach, the judgment of the people pointing it somewhere. Hand the same model to two companies and one comes out transformed while the other comes out running its old process at a higher monthly bill. The variable was never the model. It was everything around the model, which is just the operating model under a different name.

That is the part you cannot buy, and it is why the work is hard. A model is something you purchase. A workflow rebuilt around it is something you make, by hand, inside one specific business, with all the particular friction that business carries. Nobody sells a version that already understands how your company works. Sometimes the thing that has to be rebuilt is the engineering organisation itself, the capability that ends up building everything else. Sometimes it is a single process buried deep in the business, one that AI can transform only if somebody redesigns the work around the tool instead of bolting the tool onto the steps that were already there. Both are the same act at different scale, taking a capability anyone can buy and building, around it, something specific and owned that turns it into an advantage.

The constraint was never capability. It was always what you did with it.

Standing still is a choice

Most companies will treat that as the safe option. It is the one choice guaranteed to lose. The gap between the firms that rebuilt how they operate and the ones that did not has been widening for twenty years, and it does not wait for anyone to make up their mind. It grows whether you move or not. Which means standing pat is not the neutral, low-risk position it feels like from the inside. It is falling behind at the speed of everyone else's progress.

The tools are available to everyone. The models are cheap and yours to run if you want them. Capital is not the constraint, and neither is capability. The one variable still genuinely in a company's own hands is whether it will do the hard, specific, unglamorous work of rebuilding how it operates, or keep buying tools and bolting them to a structure that was never going to use them.

This is not work most companies can do to themselves, and there is nothing embarrassing in admitting it. The organisations that pull ahead are not usually the ones with the most conviction. They are the ones that brought in the capability to do it, held it to a number, ended up owning the result, and then kept going.

That is the work Carbon exists to do. Not to run a pilot, not to sell a tool, not to settle in and stay. To build the capability, prove it against the number, and hand it over, so that what is left standing afterwards is yours.

The operating model is the asset. The only real question left is whose hands build yours.

‍

Carbon builds nearshore engineering Hubs and embeds AI capability inside client operations, for scaling technology companies and PE-backed organizations. Operational infrastructure, built to last.

Own the Build™

‍

‍