Closer

XP¹ got proximity right. The direction was a constraint, not a principle.

When XP told us to put the customer in the room, it wasn’t because the customer needed to be in the room. It was because we couldn’t go to them. The team was eight engineers, a tester, an architect, a lead, and they all needed power, screens, whiteboards, lunch. You don’t relocate a circus. So you bring one customer to the circus and call it agile.

It worked, for what it was. But the customer in the room was always a compromise. Always one person, usually the wrong one, often a proxy for the actual person, and almost never the person whose work the software was supposed to make easier or worse. We knew this. We did it anyway, because the alternative — taking the team out to the customer — wasn’t possible.

It is now.

---

Small¶

A substrate team is small. One person, two, occasionally a few more — small enough that it can actually move.

The exact number isn’t the point. The point is that the team is light. Light enough that you could pick it up and put it somewhere else, mentally or physically, and the cost of doing so is low enough that you’ll actually do it. The eight-engineer squad isn’t moving. A pair might.

The frontend/backend/mobile/ops/data carve-up was always more about the cost of context-switching than any deep truth. AI drops that cost to almost nothing. So the lines blur. So the team gets smaller. So you don’t need the circus.

The first time you watch a small pair, well-paired, with AI as their multiplier, ship something that used to take eight, you realise the org chart you grew up with was a workaround for slow tools. Not a law. A workaround.

And once you accept that, the next question is the obvious one. If the team is light enough to move, which way should it move?

Towards¶

Closer than it is now. Whatever that means for you.

That’s the principle. Not “live in their building”. Not “set up a desk on their floor”. Just: prefer proximity to distance, at every level you have a choice.

A team that never spoke to a customer and now has a monthly call has moved closer. A team on a monthly call that’s now in a Slack channel with that customer has moved closer. A team in a Slack channel that now spends a day a week sitting in their open-plan has moved closer. There’s no terminal state. There’s a direction.

Substrate isn’t a methodology. It’s not a list of practices. It’s a preference. Prefer closer over further, the way you prefer people over code, problem-finding over problem-solving, judgement over process. The preferences compound. The dogma doesn’t survive the next environment.

What’s new is the cost of acting on the preference. XP put the customer in the room because the team was too big to move. Now the team can move — in dribs and drabs or whole-cloth — so it should. Distance is no longer free.

Who’s the customer¶

A note before this goes any further. The customer is whoever actually uses the thing.

In B2B that’s usually a named person — sit in their building, join their stand-ups, share their lunch. Easy to picture. Consumer software is harder. The customer is millions of people you can’t sit next to. So proximity becomes something else: time spent watching real users in their kitchens, design partners you know by name, observability instrumented so you can see what people actually do when no one’s watching, support tickets read by the engineers and not just routed past them.

The shape changes. The direction doesn’t. The further you are from the people using the thing, the more software you’ll write that doesn’t matter to them.

What proximity actually produces¶

Three things, mostly. None of them are “feedback”.

The first is judgement at the edge. As the team moves closer, decisions stop travelling. There’s no telephone game from customer to PM to spec to ticket to engineer. The engineer hears the thing, sees the wince on the face, and makes the call. Sometimes wrong, sure. But fast. And the wrongness gets corrected by the next conversation, which happens tomorrow, not in three weeks across a Jira comment thread.

The slowest step in most software systems isn’t the build, the deploy, or the review. It’s the translation. Customer to PM, PM to spec, spec to engineer, engineer to PR, PR back to customer, customer back to PM. Each step strips context and adds latency. Closing the distance collapses most of those handoffs into a conversation.

The second is problem-finding. Specs lie. Not on purpose. They lie because they’re written by someone who thinks they understand the problem, sent to someone who has to assume they do. Proximity breaks that loop.

I’ve spent a lot of time in customers’ offices. Not for meetings — sitting on their floor, working through the day, listening to what people say to each other when nothing important is happening. Most of it has nothing to do with the project I’m there for. Some of it changes the project entirely. You overhear a complaint about a process you’re not building. You catch a side-comment about a tool someone’s working around. You start to understand the shape of their week, and you realise the spec was written on top of a constraint nobody named. The version of the customer you’d been working with — the person on the call, the person who wrote the brief — was carrying a private model of what was possible. Sitting with the rest of their team, you find that model was much too small.

That’s the thing you can’t get from feedback. You stop limiting your solutions to what someone on the customer’s team thinks is possible, and start working from what actually is.

The substrate essay said problem-finding has no terminal state. That’s true. What it didn’t say is that distance makes it impossible. From far away, you can only solve the problems that have been written down — and the written-down problems are usually the ones the customer has already half-solved themselves.

The third is trust. This is the bit most engineering leaders underrate. As the team moves closer, the customer stops being a feedback source. They become a collaborator. The relationship turns into something you can’t replicate over Zoom and a Notion doc. They tell you the messy stuff. They show you the spreadsheet they’ve been hiding from procurement. They warn you about the thing in their org that’s about to blow up, before it does.

That trust is a moat. It’s the thing a competitor can’t get to with a better demo. It compounds — each conversation makes the next one easier — and it doesn’t survive distance. It’s the most undervalued asset in B2B software, and the easiest to build, if you’re willing to actually be there.

What it asks of you¶

This is harder than it sounds.

It’s harder because most engineers signed up for the work to be in their tools. The IDE is the comfortable place. The call with Jenny from accounts about her invoice flow — the third one this month — is not. Neither is the customer’s open-plan, with its fluorescent lights and the noise you can’t think over. There’s a reason we built a whole industry around the idea that engineers should be left alone to think.

But the engineering you can do alone has been changing. AI ate a lot of it. What’s left — judgement, problem-finding, the bit where you decide what to actually build — is exactly the bit that gets better near the customer and worse far from them.

So a substrate team isn’t just engineers and AI. It’s engineers willing to listen as well as build. Curious about other people’s work. Comfortable with ambiguity. Capable of telling the customer, gently, that the thing they’re asking for isn’t what they actually need, and then sticking around long enough to find out what is.

Hire for that. The syntax is now table stakes. The proximity skills are the differentiator.

It also asks something of the org around the team. Proximity isn’t free. It costs travel, it costs calendar, it costs negotiation with the customer’s commercial side about who’s allowed in the building and when. It asks leadership to send people out instead of holding them in. It asks contracts to bend, billing to bend, the org chart to bend. None of that is technical work — and most attempts at proximity die there, not in the engineering. The teams that get close are the ones whose orgs got out of the way.

What about scale¶

The objection writes itself. Fine for one pair and one customer. What happens when you have fifty customers? A hundred?

You have more teams.

This isn’t a clever answer, but it’s the right one. The instinct to centralise — one big team, many customers, abstracted through PMs — was an artefact of teams being expensive. When a customer-shaped team costs less than the PM layer it replaces, the maths flips. You don’t manage scale by stretching the team thin across customers. You manage scale by giving each customer, or each cluster of similar customers, a team of their own.

The shared substrate — the platform, the libraries, the design system — is what stays central. The judgement stays at the edge. That’s the split. Centralise what doesn’t need context. Distribute what does.

When you can’t¶

Some customer relationships don’t allow proximity. NDAs, regulated environments, security postures, plain-old customer preference. Some customers don’t want you in the room and never will.

The substrate doesn’t argue with that. It just asks: of the proximity available to you, are you taking it? Most teams aren’t. The team locked out of the customer’s building still has a dozen levers it isn’t pulling — the support thread, the renewal call, the quarterly review, the feature retro, the user interview. The objection that proximity is impossible usually translates to: maximum proximity is impossible, and we’ve used that as cover for taking none of it.

The principle isn’t “go all the way”. The principle is “go further than yesterday”.

---

Substrate teams aren’t a methodology. They’re not a framework you can roll out across your org with a slide deck and a steering committee. They’re a consequence — of small teams, AI multipliers, and the willingness to stop pretending that distance from your customer is a neutral choice.

XP saw the principle. We finally have the means it didn’t.

The substrate is people, and the people are over there.

Closer beats further. Move accordingly.

Footnotes¶

1. Extreme Programming. Kent Beck’s late-1990s methodology that put pair programming, test-first, and customer-on-site at its centre. Most of its practices outlived the name. ↩