Shared resource coordination — don't move what others are standing on

A general principle about changing shared resources. Learned from experience; applies far beyond IT.

The principle

Before you rename, move, remove, or repurpose anything that someone else is actively relying on, you need three things:

1. Their explicit sign-off — not an assumption that they won't mind.
2. An agreed time — ideally a quiet window, not mid-day while they're working.
3. A rollback ready to execute — if it breaks, you must be able to restore in minutes, not hours.

The synonym/alias/proxy approach is almost always safer than renaming or moving the original: it adds a new name pointing at the old thing and leaves the original completely untouched until everyone agrees to switch. Only remove the original after the cutover is confirmed clean.

The second failure: not being ready to recover

The first failure is making the change without coordination. But there is a second, independent failure that compounds it: not having the rollback ready before you start. Even if you decide the risk is acceptable, you owe it to the other person to be able to undo the change in under a minute — commands tested, verified, ready to paste. If you cannot guarantee that, you are not ready to make the change.

This applies beyond IT too. A surgeon who opens before checking the blood supply situation. A builder who disconnects the gas before confirming the isolation procedure. A manager who moves someone between teams before lining up the handover. In each case the act itself may be unavoidable — but being caught without a recovery plan when things go wrong is a separate and avoidable failure. Confidence that it will work out quickly is not the same as having made it so.

IT analogues

• Renaming a database table, column, or schema that another app or developer is using — their queries break immediately.
• Moving or renaming a shared file, directory, config file, or API endpoint.
• Revoking a permission, token, or credential that a service is using.
• Changing a shared DNS entry, load balancer rule, or network route.
• Restarting or redeploying a shared service during business hours without a maintenance window.
• Dropping a shared Git branch another developer has checked out or is basing work on.

Non-IT analogues

The same pattern appears wherever multiple people share a resource or depend on something being in a known state:

• Moving someone's tools, files, or equipment at work without telling them — they reach for it and it's gone.
• Rearranging a shared kitchen, office space, or workshop while others are mid-task — they can't find what they need.
• Cancelling a shared calendar event or meeting room booking without notifying attendees.
• Changing a shared document, spreadsheet, or process that others are actively editing or following.
• Redirecting a shared email address, phone number, or postal address without coordinating with everyone who gives it out.
• In a shared car: moving the seat/mirrors without telling the next driver — minor, but the same structure.
• In construction or renovation: turning off power or water to a building without notifying all occupants.
• In a team sport: changing the agreed formation or signal mid-play without communicating it to the rest of the team.
• In a shared household: disposing of something (food, an item) that someone else was relying on.
• In a project: reassigning a resource (a person, a budget line, a piece of equipment) that another workstream is depending on.

The common thread

In every case the failure mode is the same: one person makes a change to a shared thing under the assumption that it won't affect others, or that the impact is small, or that they can fix it quickly if it does — and someone else pays the cost immediately without warning. The fix is always the same too: communicate before the change, not after.

See also: principles/workstream-note-structure — organising a substantial undertaking so nothing is lost.