Fayol's Principle: You Own the Problem. You Just Can't Touch It.

You are handed a job nobody could argue with, and the one thing you need to do it belongs to somebody else. Nobody in that conversation did anything wrong. This episode is about what happens when you own a problem you can't touch, and a management rule more than a century old that says it should never happen. The rule comes from Henri Fayol, a French mining engineer who ended up running a large mining company and wrote down fourteen principles of management. Two of them matter here. Authority and responsibility: responsibility is the natural counterpart of authority, and where authority is exercised, responsibility arises. Run it in the other direction and you get responsibility handed to someone with no authority attached, which is half of a pair: the gauges without the levers. And unity of command: an employee should receive orders from one superior only. When the job comes down one chain of command and the authority to do it sits in a different one, neither team is the problem. The seam between them is. The episode follows one live, unresolved example: a cleanup assigned to a team that was not given the access its first step requires. The best on offer was an offer to help, and the narrower route that does exist is a project of its own, needing several teams and weeks, that nobody owns. It lands on that team for a simple reason. Accountability follows visibility, and authority follows ownership. Nothing in an organization makes those the same team. The source team that can fix a data problem is not failing either. It is doing its own job against its own priorities, and the team that gets asked is not the team that sets the priority. Then what alignment buys. The same team owned a heavily used report, its model, and the SQL feeding it, so it could move calculation logic out of the model and into the SQL layer. The nightly job finished half an hour later, still well before anyone opened for business, and the refresh fit a cheaper tier, saving thousands of dollars a month. Split that across two teams and the trade dies in a meeting, because nothing in the SQL team's world can see the savings on the other side. Optimizations like that live at the boundaries between layers, and you can only take them if one team owns both sides. If you hold the responsibility and not the authority, the gap has three honest resolutions: someone grants the authority, someone moves the responsibility to whoever already has it, or someone decides, knowingly, to live with it. The one that is not legitimate is nobody deciding at all, because a gap nobody decided on does not disappear. It defaults to whoever is most visible. So make it a decision and make it easy to make: keep a record of what you were asked to own, what you asked for, what you were told, what you hold and what you lack, and put it in front of the people who sit above both teams. If you are the one handing out the job, you owe the authority, or an honest account of why it is not coming. And before you accept a responsibility, ask whether you hold authority over its inputs. If not, do not refuse. Say what it would take, or say what you could own instead. You may own the problem and not be able to touch it. That is not a verdict on you or your team. It is a decision nobody has made yet. Source: Henri Fayol, General and Industrial Management (the English edition of Administration industrielle et générale). Subscribe to The Foundation Layer for more on why the data and AI problems your org keeps hitting are usually the same problem wearing a new name. WATCH NEXT • Conway's Law: Your Data Model Is a Map of Your Org Chart:    • Conway's Law: Your Data Model Is a Map of ...   • Master Data Management: The Gold Record Doesn't Enforce Itself. Ownership Does.:    • Master Data Management: The Gold Record Do...   • The full series, in order:    • The Foundation Layer: Full Episodes