← Articles
August 5, 2026 · 6 minute read

What Isn't Written Becomes Personal

In 2005, ambiguous authority inside companies had a face: two bosses. Today it has no face at all. The question that solved that problem is the same one that solves this one, and almost nobody's asking it.

There was a classic problem in the multinationals of the 2000s, and it had a name: dual reporting. The executive answered to a local boss and a global boss. Both legitimate, both with targets, and the targets not always aligned.

A Brazilian magazine for technology directors covered this in May 2005, in a piece whose headline was exactly the question people were asking in the hallways: where's my boss? The story wasn't about org charts. It was about what happens to a decision when two authorities claim it at the same time.

The most interesting answer in the piece didn't come from structure — it came from a principle. That the code of conduct should set out how to resolve interpersonal conflict regardless of who's sitting in the chair, so the matter never becomes personal.

Hold on to that sentence. It's twenty-one years old, and it describes a problem most companies are facing right now without recognizing it.

Ambiguous authority lost its face

Dual reporting was uncomfortable, but it had one virtue: both sides existed. You could schedule a meeting with the local boss, call the global one, find the formulation that worked for both. It was negotiation between people, and people can be persuaded.

The ambiguity that exists in your company today doesn't have that comfort. A growing share of the decisions coming out of your department is no longer made by anyone. It's produced by a model-assisted process, reviewed in a hurry by someone who couldn't have redone it, and signed by whoever was available.

When that works, nobody asks anything. When it goes wrong, the company looks for a name. And that's when it discovers it never agreed on one.

Why the search for a name always lands on someone

Watch the mechanism closely, because it's silent and it always works the same way.

With no written rule about who answers for what the machine produces, responsibility doesn't disappear: it migrates to the last human in the chain. Almost always someone mid-level, who approved because approving was their step, not because they examined it. And the day of the incident is exactly the day nobody tells the two apart.

Approving without being able to examine has its own name, and it's one of the most expensive things happening inside companies today: the signature exists, the control doesn't. From the outside, the two look identical. From the inside, the difference only shows up when someone has to explain.

That's when the conversation turns to the person. Whether they were careful, whether they should have noticed, whether they raised a flag. Exactly what the 2005 sentence said to avoid. The conflict doesn't become personal because people are petty. It becomes personal because the rule wasn't written beforehand, and someone has to fill the vacuum.

The test, in three questions

If you lead a department where part of the work already runs through AI, three questions separate who has a rule from who has a hope:

Is it written down, anywhere, who answers when this process gets it wrong? Not who operated it, not who approved it: who answers. If the answer depends on asking someone, it isn't written down.

Could whoever signs off actually redo what they're signing off on? If they couldn't, you don't have review, you have a rubber stamp. That might even be acceptable, but it needs to be a declared choice, not a discovery made too late.

Does the rule apply to the seat, or to the person? If it changes when the occupant changes, it isn't a rule, it's an informal understanding. And an informal understanding doesn't survive the first costly incident.

What the rule needs to actually be worth something

Saying "write the rule" is easy and nearly useless on its own, because most written rules don't solve anything. Four things separate one that works from a nice paragraph in the manual.

What the worst effect is, and whether it crosses the company's front door. A wrong draft costs a revision. A wrong decision that reaches the customer costs something else. The same rule can't apply to both, and most do — that's why they don't bite.

Who answers, named by role. Not "the team," not "the department": the position. A rule that names a person ages out at the first team change, and a rule that names a group names nobody.

Exactly where the machine stops. Not "with human supervision," which means nothing. Which decision it makes on its own, which it proposes, and which it doesn't even propose. If that isn't written down, every person will assume a different limit, and all of them will think they were right.

How to undo it, and who can undo it without asking permission. This is the one most often missing, and the one that costs the most. When the path back depends on approval, it doesn't get used at the moment it was needed; it gets used later, once it's already become a meeting.

There's a fifth, and it's about maintenance: when the rule gets reviewed. Without a review date, it keeps applying after the process has changed — and at that point it protects less than having no rule at all, because it gives the impression someone already thought it through.

What was already known in 2005

The temptation, faced with new technology, is to assume the problems are new too. They almost never are. The counterpart changes, the structure stays the same.

In 2005, the ambiguity came from two occupied seats. Today it comes from a seat nobody occupied. In both cases, what decides whether it becomes a lesson learned or a hunt for someone to blame is the same thing, and it's tedious to do because it has to be done beforehand: writing the rule while nobody's under pressure, applying to the position and not to whoever holds it.

It's writing and agreement work, not technology work. It doesn't show up on any maturity ladder, has no vendor, and it's the difference between a company that makes a mistake and fixes it and a company that makes a mistake and goes looking for a name.

The question that closes this is short, and it's worth asking at the next meeting where someone presents a new AI-driven process: if this goes wrong on Wednesday, who answers, and where is that written down?

If the room hesitates, you just found the most urgent thing on your agenda. And it isn't technical.

Where this piece's yardstick comes from

The argument above doesn't depend on jargon, which is why I used none. But it comes from somewhere, and it's worth saying where.

The question "who answers, and is it written down?" is the human half of a yardstick that classifies decisions along two axes. The first is the reach of the error: a draft, an internal effect, an operational effect, and an effect that crosses the company's front door can't live under the same permission. The second is the control left on the human side, which ranges from examining case by case down to just reviewing the record afterward. The rule linking the two fits in one line: the control that remains has to be greater than or equal to the effect's irreversibility.

When the signature exists but the examination doesn't, the yardstick has a name for that, and the piece above describes the whole phenomenon without needing to use it.

The four bands, the ceiling for each one, and the questions that make the yardstick bite are published, with dates, on the method page.

The 2005 article cited is "Cadê meu chefe?" ("Where's My Boss?"), by Juliana Nogueira, INFO Corporate issue 20, May 2005, a magazine for technology directors published by Editora Abril. The print edition is in this piece's author's own files — he was one of the sources interviewed for the story: the line about depersonalizing conflict is his, and it's the reason this piece exists.

This piece's yardstick is published, with dates

The four reach bands, the ceiling for each one, and the questions that make the yardstick bite. None of that is secret: what can't be copied is the practice of applying it case by case.

Read the method
Apply it to your own case