What to share and what to keep local

The story

A whiteboard, five capabilities, one argument.

Tomás Reyes had a proposal, and he was nervous about it. He had spent a week reading the two annex reports, Warranty's and Dispatch's, and he thought both teams should stop patching their own document readers and use one. Build it once, he said. Fix the scanned-annex problem in one place. Then each team could adjust it to its own work.

Priya Natarajan's reply came in under a minute: "Which team's mistakes will it make?"

It was a fair question. Warranty Claims reads contracts and annexes to decide whether a repair is covered, and a missed exclusion is not a small error. Field Repair Dispatch reads manuals and service logs to route crews; it wants speed, and a dispatcher checks every suggestion anyway. Same kind of document, different cost of being wrong. Dan Whitfield wanted the faster, cheaper reader. Priya wanted the one that was never wrong, even if it was slow. A single model tuned for one of them would underserve the other.

Maya Okafor did not take sides. She asked for an hour and a whiteboard, and she drew two lines. Across the bottom: how often does this need come back? Up the side: how different are the local needs? Then she listed everything Hartwell was currently paying for, or about to, and asked the room to place each item.

Multilingual chat for Customer Support went to the bottom left, rarely recurring across teams and not very different, so: buy it. R&D's wear-prediction models, built on sensor data nobody else touched, went to the top left: leave them where they are. Removing personal data from documents before any model reads them went to the bottom right, since every team needs exactly the same rule: build it once. And reading documents went to the top right. It came back often, in at least two teams, and the needs differed.

"That one," said Maya, "is the only one we argue about."

She was right, and the rest of this chapter is about that corner.

The problem

"Share everything" and "share nothing" are both lazy.

Companies tend to arrive at one of two positions. In the first, every AI project is a one-off, and teams solve their own problems their own way. This is how Hartwell ended up with the second invoice. In the second, the company declares a single platform, a single model or a single standard, and teams are told to use it. This is how Priya ended up with two centres of excellence and a slide deck.

Neither position starts from the right question. The right question is not should we share? but what, in this particular case, is worth doing once, what is worth buying, and what should stay at the team that needs it? The answer depends on two things you can estimate: how often the need recurs, and how much the local needs differ. That is the whole matrix.

What the research shows

Recurrence pays for the setup; difference erodes the saving.

Start with the sharing equation from the first lesson. Doing something once beats doing it separately when the number of teams times the saving per team exceeds the fixed cost of building the shared thing plus coordination, waiting and the mistakes the shared version causes. Here is how Hartwell's whiteboard conversation looks in that language, with the first lesson's numbers. They are illustrative; think of one unit as about $5,000.

Each team doing it alone costs about 40 units, roughly $200,000. That is what Warranty paid, and what Dispatch paid. A shared document base costs 60 to build and maintain. Coordination costs 5 and waiting in the queue costs 15. The lesson sets the loss from the shared version being wrong now and then at zero, and Maya did the same, because nobody could price it yet. So the shared route has a one-off cost of 80 in all. Each team still has to adapt the base to its own work, at 10 units per team, so each team that joins saves 30.

With one team, the saving is 30 and the cost is 80. Sharing loses. With two teams, the saving is 60 against 80. Sharing still loses, by 20. The break-even is 80 divided by 30, about 2.7 teams, so sharing wins from three. Maya looked for a third: Finance Analysts had bought document tools that already worked and read different documents, Customer Support had bought a chat product, and R&D's data was its own. Then Tomás pointed down the corridor. Service Engineering, inside the Dispatch unit, writes the repair procedures and reads the same scanned manuals, and had been about to ask a vendor for a reader of its own. With three teams the saving is 90 against 80, a win, though only just. That is why the whiteboard conversation was worth having. The recurrence axis is simply n, the number of teams that really need the same thing, and the equation says it is decisive. It also says the margin is thin, and that two teams were not enough. Maya wrote both down.

The second result is on the other axis. Better expertise, worse fit shows that a shared method with more accumulated experience can lose to a local one when the job differs enough. The further the shared base sits from this job, the more errors it adds, and past a crossover local work wins. The research does not say where the crossover is for Hartwell; that is what Priya's tests are for.

The third is the warning from how much to invest: sometimes the learning never recovers its setup cost, and the right amount of shared work can sit well below what the available capacity would allow. In matrix terms, a need that recurs rarely does not repay a build, however attractive the build feels.

Now the honest status of the design I am about to recommend. The research compares a shared method with a local one. It does not test the particular pattern of a shared base with local tuning, and the business article says as much. That pattern is my proposal. It is a design that follows the research's shape: sharing where it recurs, local where it differs. It is not a result.

Two convictions

What I would do with the matrix.

Share, Tune, Buy, Leave

Two questions place every capability.

Here is the matrix as I use it. The horizontal axis counts how often the need comes back: the number of teams that need it, times how often, over the next twelve months. The vertical axis asks how different those teams' needs are: their data rights, their tolerance for error, their vocabulary and their acceptance test. Place each capability honestly, and the cell tells you the default.

Share means run it once, as a standing service. It is the right default when the need is the same everywhere and comes back often. The cost is a fixed one, and a service needs a Technical Owner who vouches for it and a platform owner who accepts its upkeep.

Tune means share the base and let each team adapt it. This is the hard corner. It earns its place when the base saves real development and the local adaptation stays cheap. It fails when the adaptation approaches the cost of starting over, which is what the third scenario in the research's cost comparison shows: when local requirements diverge enough, each product redoes much of the work.

Buy means use a vendor or a platform you already have. Rarely recurring or alike are two ways of saying that someone else probably built it.

Leave means keep it local. The capability is rare and specific, so the right amount of connection is a conversation on demand. Leaving is a deliberate choice, and it deserves a place on the map.

Use it in a meeting. Write the capabilities on sticky notes. Ask the room to place each one, and watch where they disagree: the disagreement is the interesting part. Two people who place the same item in different cells usually have different information about either how often it recurs or how differently the teams would use it. That is the discovery work, done in twenty minutes.

The capability tensor

The company on one page, in three directions.

The matrix tells you what to do with one capability. The next figure tells you where all of them sit. For twenty years, large companies have drawn themselves as a grid: business units down one side, functions across the other. A product manager in Warranty Claims and an engineer in Dispatch each sit in a square, and the square means ownership. It worked. It gave clarity and accountability.

What the grid cannot show is that a document-reading capability is not in any one square. It lives in a stripe through several of them. The warranty analyst and the dispatcher each use it, and each of their teams is paying for a piece of it. Add a third direction, the capability program, and the grid becomes a block. Each small cube is one team's contribution to one capability. A cube alone is just a local copy of the work. Taken together, cubes along one capability form a plane, and the plane is what the company is actually building, whether it knows it or not.

I call this a tensor, which is a word I otherwise avoid. It is just a block with three labelled directions. The word is useful here because the idea is useful: see the plane.

At Hartwell the lit plane is reading documents. It runs under all five business units, but today only two of them use it, Warranty and Dispatch, which includes Service Engineering: the same three teams the sharing equation counted. Customer Support sits on the multilingual chat plane, through a product it bought. Data protection runs across everyone. R&D is in the block, but its work stays on its own. Use the buttons to light each plane in turn.

A word of caution that matters. The tensor is a map, not an org chart. I have seen companies take a picture like this and give each plane a manager, a team and a budget. That produces six small departments, each defending its plane. The AI Capability Manager's job is to see the planes and to ask for each: is this one worth running once, and is there a named Technical Owner? The answer for Hartwell today is yes for two planes and not yet for the others.

Back at Hartwell

The base and the two tests.

Three months later, Tomás had a base. It was not elegant. It handled the two-column annex pages and the faxed stamps, and it came with a dated, versioned record of what it had been tested on, which Priya insisted on and which turned out to be the most valuable thing he wrote. Priya's team tuned it against her test: zero missed exclusions across a held-out set of 400 annexes, 100 of them chosen to be hard. It passed on the third attempt. Dan's team tuned it against his: nine right crew assignments in ten, with a dispatcher checking. It passed on the first, and Dan was irritated that Priya's version took so much longer. Service Engineering tuned it for its scanned manuals and passed on the first attempt too.

Customer Support bought its chat product. Finance kept the document tools it had bought. R&D kept its wear-prediction models. A small rule that strips personal data from any document before a model sees it went live for everyone, and nobody has thought about it since, which is what you want from a Share.

It would be neat to say this was a clean success. It was not entirely. Priya's tuning cost more than the 10 units the whiteboard promised, closer to 15, because her hard annexes needed extra labelling. With her real cost the three teams' saving was 85 against 80, still a win, but by 5 where the whiteboard had said 10. Maya added the real number to the record, and next time the estimate for a team with Priya's error tolerance starts higher.