Make the Shared Thing Visible Before You Automate It

When two independent pieces of work keep quietly colliding over the same shared resource, the instinct in most engineering teams is to build something cleverer to stop it happening again. Sometimes the better answer is much smaller than that: make the resource visible, and give people an easy way to say "this one's mine right now." A shared list that everyone can see and trusts beats a locking mechanism nobody remembers exists.

I watched this play out recently on a team wrestling with a recurring, low-grade annoyance. Two different pieces of work needed the same external slot at the same time — a shared test account, a fixed external identifier, the kind of thing there's only one of and that nothing in the system enforces exclusivity around. Neither side knew the other existed until something failed in a confusing way, someone spent an hour working out why, and the answer turned out to be embarrassingly simple: two people had reached for the same thing at once.

The first instinct was to solve it properly. Build a reservation system. Add a lock. Write a service that tracks who's using what and blocks a second claim automatically. It's the instinct most of us have been trained into, and it's not a bad one in general — automated coordination is usually more reliable than asking people to remember things. But "usually" is doing a lot of work in that sentence, and it's worth noticing when it doesn't apply.

The team didn't build the reservation system. They opened a shared spreadsheet with a column for the resource, a column for who was using it, and a column for how long they expected to need it. That's it. No validation, no locking, no notifications. Just a place everyone could see and a habit of checking it before reaching for the shared thing.

It worked, and it's worth being honest about why, because the reason matters more than the anecdote. The actual problem wasn't a lack of enforcement. It was a lack of visibility. Nobody involved was being careless or territorial — they simply had no way of knowing someone else was already using the thing they were about to use. A locking mechanism solves that by refusing the second request. A shared list solves it by letting the second person see the first person's claim before they ever make the request. Both remove the collision. Only one of them requires you to build and maintain software to do it.

This is the part that's easy to miss when "more automation" is the default answer to every coordination problem: automation solves the case where people already know the rule and need it enforced. It does nothing for the case where people don't yet know there's a rule to follow, because they've never had reason to think about the resource as something shared at all. Building a locking system for a problem like that adds real value once, at the moment of enforcement, but it also adds ongoing cost — something else to maintain, something else that can have its own bugs, something else that needs someone to remember it exists and understand why. A spreadsheet has none of that overhead, and it has one advantage a lock doesn't: everyone using it can see the whole picture, not just whether their own request was accepted or refused. They can see what's coming, plan around it, and — just as importantly — notice patterns a computer wouldn't flag, like the same two things always wanting the resource at the same time of day, which is usually the real problem worth fixing.

There's a broader habit worth taking from this, and it isn't "avoid automation" — plenty of coordination problems genuinely need it, and a spreadsheet would be the wrong answer to most of them. The habit is to ask what kind of problem you actually have before reaching for a solution shaped like the last one you built. Some problems are enforcement problems: people know the rule, and it needs to be impossible to break. Some problems are visibility problems: people would happily follow a rule if they knew it existed and could see enough to act on it. Treating a visibility problem as an enforcement problem gets you working software that solves the wrong half of the difficulty, at several times the cost of the version that would have actually worked.

It's also a useful check on a habit that shows up well beyond software. Meeting rooms, shared budgets, on-call rotations, a single expert everyone wants time with — these all fail in the same shape. Something is genuinely scarce, more than one person needs it, and nobody has a clear, shared view of who's claiming what. The reflex is to build process: approval chains, booking systems, escalation paths. Often what's actually missing is much smaller — a single place everyone trusts to look, and a norm of looking before you reach.

None of this is an argument for leaving every shared resource to goodwill and a spreadsheet forever. If the stakes are high enough, or the team is large enough, or the cost of a collision is severe enough, build the lock — the informal version is a starting point, not a permanent answer, and it's worth outgrowing on purpose rather than by accident. But it's worth resisting the urge to skip straight past it. The cheapest, fastest, most honest fix for a lot of coordination problems is just letting people see each other's intentions before they act. Automation earns its cost once people already understand the rule it's enforcing. Until then, the rule itself is the missing piece, and a rule doesn't need to be built into software to work. It just needs to be visible.