Logs of Duty: System Ownership
A comprehensive guide to avoiding responsibility at scale.
Rule #1: Assume it is not you. If your changes break something, it’s not your problem, it’s the owner who didn’t review carefully enough.
Rule #2: Ask who the owner is in Slack. And enjoy watching three teams tag three other teams.
Rule #3: Check the Git history. The last commit was six months ago by someone who has already left the company. So is code review still necessary?
Rule #4: Trust the monitoring. If the service has no alerts, metrics, or logs, it’s clearly not an important service. Or an extremely important one. Hard to tell. Proceed with caution.
Rule #5: Ask the Principal engineers. They’ll explain the ideal ownership model, the target state, and the correct process. Even though nothing has ever been implemented like that, and never will be.
Rule #6: Try to shut it down. The owners will manifest soon. If not, don’t bring it up online and brag about your cost reduction capabilities.
Rule #7: Shared ownership is no ownership. You will find out when it becomes everybody’s problem at 3 a.m.
Rule #8: Escalate carefully. If you ask leadership who owns the system, they’ll assign it to whoever asked. Congratulations on your new responsibilities.
Rule #9: Document your findings. Write everything you discover in a Confluence page, but name it in a way others can’t find it, such as "Misc Notes”. That way, technically, you documented it. But nobody will think you’re the owner.
Rule #10: Celebrate resolution. When you eventually figure out who owns it (usually you), update the Confluence and hold a knowledge-sharing session. Then leave the company and let others figure out who will be the next owner.