The Two Systems Never Once Disagreed. Somebody Still Had to Explain the Gap.

At a company I worked for, I ran the system that handled workflow and approvals for the analysts who authored event presentations: session names, speakers, and content moved through it before anything was final. A separate team handled the systems used to run the events: scheduling, room assignments, and the live logistics on the ground. We had an agreement about how data moved between us, and what stage a presentation needed to reach before it crossed over to them.

Our system was steady. Theirs could not be. Conference wifi is unreliable, so their team built a version of their software that ran self-contained on-site, disconnected, so a session or a speaker could change on the floor in real time and the event would not fall apart around it. If you remember the old Mac-versus-PC commercials, we were the PC. They were the Mac. Neither one of us was wrong. We needed different things from our own systems because we were doing genuinely different jobs. That is a Structural Bearing: two legitimate systems, neither one wrong, meeting at a boundary neither side fully controls. The Edge Case walks through how to map one precisely. That is not what this piece is about.

The rules for how data passed between the two systems kept moving, usually without a real conversation, just an adjustment somebody made to handle whatever the conference floor threw at them that week. Most of the time it worked. Some of the time, a change made live at the event never made its way back into my system afterward. More than once, I was the one who had to explain the mismatch, to someone above me who did not particularly care which system had actually caused it.

The internet's current advice to anyone thinking about management is blunt: stay an individual contributor. Management carries more responsibility than power, and if you have to choose between firing the manager or the engineer, fire the manager first, because the engineer is redistributable and the manager just absorbs whatever goes wrong. Most technical leaders who have ever sat in that exact meeting have felt the truth of it, even if they never said it out loud.

Here is what that advice never explains: why the gap exists at all. A manager's authority is granted along the lines of an org chart: a team, a budget, a box. Accountability is granted along the lines of an outcome, and outcomes do not respect the org chart. They are produced by whatever actually crossed the boundary to get there. My workflow system and the events team's live system never had to fight for this to be true. We were each fully authoritative inside our own box, and completely unauthorized inside the other's, and the actual result attendees saw depended on both. Nobody had to be wrong for the gap to open. The gap was built into what a box can grant versus what a result actually requires.

This is also why, when something does break at a boundary like that, an organization rarely traces the real distributed cause. That takes time, and time is expensive during a live conference or a live quarter. It reaches instead for the one legible name it can point to. In my case, that was whichever system was the official record. In a management org, that is almost always the manager, not because they contributed least to the outcome, but because they are the cheapest name to hold accountable for something nobody upstream can fully trace. This is what I have called The Accidental Manager elsewhere: not just someone unprepared for the job, but someone handed a box that was never sized to match what the outcome would eventually require of them.

You cannot shrink your accountability surface. Outcomes will never respect your box, no matter how the org chart is redrawn. What you can do is name, out loud, in the room, before anything breaks, exactly where your authority ends and the other system's begins. That does not make the gap disappear. It gives blame somewhere real to land besides your name by default.

Think of the last outcome you were held accountable for that depended on a system or a team you did not control. Did anyone above you know, at the time, exactly where your authority ended and theirs began? If the answer is no, you were never really the accountable party in the way anyone assumed. You were just the most legible name in the room.

Quiet Confidence has more on the difference between a gap that is real and a gap that is yours to fix alone, and why confusing the two is the quiet part of this job nobody warns you about: http://TheQuietConfidenceBook.com