Your Playbook Assumes You Control the Building

Last week we called multi-tenant the harder version and moved on. Here's what actually breaks when your way of working has to run inside companies you don't own. Not just a consultancy problem.

The sentence I moved past

Chuck and I wrote last week about Anthropic's AI-Native SDLC playbook and where it maps onto CRAFT. Somewhere in the middle I put down that their playbook assumes a single codebase, a single team, and one set of institutional norms, and that CRAFT has to work inside businesses we don't own. I called that the multi-tenant version of the problem they solved single-tenant, said multi-tenant is the harder version, and went to the next section.

That deserved more than a paragraph, and it isn't a consultancy problem.

If you run three locations that came in through three acquisitions, you have this problem. If you franchise, you have it. If you're the parent company and your subsidiaries kept their own systems, you have it. If you've ever rolled your way of working into a team that arrived through a deal and watched it quietly not take, you've already lost a round of it. Any time one method has to survive inside units you don't fully control, the rules change, and almost every playbook worth reading was written for the case where you do control them, by a company writing down what works on itself.

The test that counts is whether it still works in a building you don't own, on tools you didn't pick, held up by people who can say no.

Enforcement you own versus enforcement you ask for

Anthropic's gates are hooks. Real code in the tooling that refuses to let work proceed until a check passes. Ours is the Fortify Gate, and Chuck put the difference plainly last week: theirs is a hook, ours is a checklist a human runs. Same law underneath, different mechanism.

That sounds like an implementation detail. Inside a company you control, a rule can be a wall. You own the repo, the pipeline, the laptops, and the performance review of the person who would route around it. Inside a company you don't control, the same rule is a request. It holds because somebody decided it should, and it keeps holding only as long as that stays true.

Nobody announces they're skipping the gate. The company gets busy, one release goes out without the checklist because the person who runs it was on vacation, nothing breaks, and the next one goes out the same way. By the time anybody looks, the gate is a document describing a process nobody runs. Every skip along the way was reasonable.

So if you're running a method across units you don't own, you need to know which of your controls are walls and which are agreements. Both are legitimate. An agreement everybody knows is an agreement gets renewed.

An agreement somebody thinks is a wall gets discovered at the worst possible moment.

Context is the one thing that can't pool

Anthropic's Build stage leans on a CLAUDE.md: the institutional knowledge the model would otherwise re-derive every session. That works because there is one institution to capture.

We wrote in August that the client owns the context layer, and I framed it then as a line we draw on purpose. It is, and it's also forced. The context layer is the compressed operating history of one specific business: who the people are, what a normal week looks like, which exceptions are routine and which should wake somebody up. Two clients in the same industry have contexts that look identical in shape and share nothing in content, and there's no version of pooling them that survives the first conversation about it.

So the asset that would compound fastest is the asset you're least allowed to compound.

What moves between businesses is the shape: that a context layer exists at all, what belongs in it, how it gets kept current. What's inside it doesn't move at all.

Anybody running one way of working across multiple companies eventually tries to solve this with a shared knowledge base everyone points at. What ends up in there is either so general it's a poster, or specific enough that somebody is now reading another company's operating detail. The version that works is a template plus the discipline to fill it in every time, which is less satisfying and the only thing I've seen hold.

Somebody else decides what done means

Single-tenant, you set the bar once. What shipped means, how much risk is acceptable, how fast is too fast. One company, one risk tolerance, and every stage downstream inherits it.

Across businesses the bar is an input. A four-person engineering org and a firm with a compliance calendar don't have the same definition of done, and neither one is wrong. The boutique wealth management firm we wrote about in July and the field service company running trucks and a dispatch board had almost nothing in common, and what ready meant in each was set by their regulator and their customers, neither of which we had standing to override.

The method has to hold its shape while that number moves.

The failure mode here is picking one bar, usually the one from your own shop, and quietly grading everybody against it. That's how a firm ends up telling a client their process is immature when what actually happened is the firm brought its own risk tolerance along and billed for it.

You inherit the stack

Inside your own company you choose your tools. Across businesses you inherit them.

That's the scheduling system that can't see the parts inventory, the decade of client history sitting in one advisor's email, the spreadsheet that turns out to be the real system of record, and the CRM somebody's cousin configured years ago that three people depend on and nobody will touch. You don't get a greenfield, and you don't get to make replacing any of it a precondition, because a coordination layer that only works after a long migration is a proposal rather than a layer.

This is the constraint that kills most internal playbooks the moment they leave the building. They're written assuming the tools named in them. Take those away and what's left is a set of habits with no mechanism behind them. So the question I'd put to any method, ours included: what does this still do for me on day one, before I change a single system I'm already running.

A bad pattern costs more when it travels

Inside your own company, a bad decision is a bug. You find it, you fix it Monday, the blast radius is you. Across businesses, the same bad pattern is already sitting in every engagement that took it, on infrastructure you don't own, and you can't push a correction into systems that aren't yours. You can tell people and hope the call gets returned.

That asymmetry is the real argument for a gate that slows you down on purpose.

A shop shipping only to itself can afford to learn in production. A method that travels can't, because patterns don't roll back the way code does.

Four questions, either direction

If you're evaluating a firm, these are worth about thirty seconds each.

Which parts of your method are enforced by tooling, and which are enforced by agreement? Both answers are fine. Not knowing which is which is not.

What would you change to run this inside my company? Nothing is the wrong answer. It means you're buying a single-tenant playbook with your logo on the cover.

What have you learned from another client that you can hand me, and what form does it arrive in? A person's memory doesn't transfer. What you'd be paying for is that person's availability.

Who sets the definition of done? If they do, their risk tolerance came along with the work whether you wanted it or not.

If you're on the other side of this, running a process across locations or companies you bought, run the same four on yourself. The answers are usually worse, because you've been assuming you control a building you only partly control.

Where we actually are

We haven't solved the version of this I just described.

Chuck said in August that every business we've built this in is under a certain size, and that he doesn't know where the shape breaks. He suspects written intent goes first, because past some headcount you stop having one coherent statement of what a system may decide alone and start having competing ones by department. Still true, still unhit, still coming.

We also still have no answer for two coordination layers built by two different firms for two parts of one company. He raised that in August. We're no closer.

And we're designing the newest piece of our own stack right now, the one that manages what's already running instead of building something new, against the control-band bar we wrote about last week. Drift on somebody else's operational metrics is a question about how their business is supposed to behave, and we don't get to answer that for them.

A method that works where you control everything isn't worth much as evidence. Every company has one, and in most of them it's the habits of whoever is most senior, written down after the fact.

If you're running one way of working across units you don't fully control, leave a comment and tell me which of those four questions was hardest to answer about your own operation. That's the one I want to read.