A Role Without Enforceable Authority Is a Title

The role descriptions existed. They were on Confluence. Nobody had ever used one to settle anything.

An audit of the QA function found that Test Manager and Test Coordinator were indistinguishable in practice — not in the documentation, where they were carefully separated, but in how the project actually ran. Neither role's decisions were treated as binding.

Two roles, two written scopes, one observable outcome: whatever either of them decided was a suggestion.

When Everyone Can Decide, Nobody Decides

This is the mechanism, and it is worth being precise about it.

Authority is not a property of a job description. It is a property of what happens after a decision. If a decision can be reopened by anyone who disagrees, without a defined route and without anyone having to justify the reversal, then it was never a decision. It was an opinion with a job title attached.

That state is stable, which is why it persists. Nobody has to fight it. Each individual reversal is reasonable in isolation — a deadline, a priority, a good argument from someone senior. The pattern only exists at the level of the month, and nobody looks at the month.

Meanwhile the effect compounds. Every reversal teaches the organisation that the role's output is negotiable, which makes the next reversal cheaper, which makes consulting the role beforehand feel increasingly optional.

The Diagnostic

There is a short test for whether a role in your project has authority or a title.

Name one decision from the last month that only that role could have made, that was made, and that still stands.

Not a decision the role contributed to. Not one it was consulted on. One where the role's answer was the answer, and where someone who disagreed had to go through a defined route to change it.

If you cannot name one, the scope document is describing a position that does not exist in the running system. That is not a failure of the person holding it, and treating it as one is how these situations get personalised and then never fixed.

What Gets Cut, and Who Was in the Room

The decision to reduce testing's share of the project was taken without consulting the Test Manager.

Two things are visible in that sentence, and only one of them is about budget.

The first is the familiar one. When something has to be cut, testing is a frequent candidate, and the argument usually arrives in the same form: projects used to run without dedicated testers. That is true. Cars used to run without seatbelts.

The second is the diagnostic, and it is sharper. Nobody skips consulting a role whose agreement they need. The absence of that conversation is not rudeness — it is accurate information about where the role sits in the decision path. If the Test Manager's sign-off were structurally required, the meeting could not have concluded without it.

So the cut is the symptom. The empty chair is the finding.

The Colleague Who Does Not Make Mistakes

The same project produced a third version of the same failure.

Someone had come to be treated as infallible. Not through any claim of their own — through accumulated reputation and a run of good outcomes. And a tester was not planned for a piece of work on the grounds that this person does not make mistakes.

That reasoning contains a misunderstanding about what testing is for.

A tester does not only look for errors in code. They look for errors in the process, in the communication between people who think they agreed, in the decision that made sense to everyone in the room because everyone in the room shared the same assumption. Those failures are not correlated with individual skill. A highly capable person produces exactly the same category of defect as anyone else, and often produces it faster.

The infallibility assumption is itself an error. It is also the most expensive one in this article, because it removes the only mechanism that would have caught it — and it costs far more than the tester it was used to avoid.

Writing a Scope That Actually Binds

A scope document that lists responsibilities changes nothing. A scope that lists decisions changes behaviour, because a decision has a holder and an outcome you can check.

• Write decisions, not responsibilities. "Owns test strategy" binds nobody. "Decides whether a release meets exit criteria" names an event, a holder and a moment where the answer is visible.
• Define the override route explicitly. Any decision can be overruled — that is normal and often correct. What matters is that overruling requires a named person and leaves a record, because a reversal nobody has to sign is indistinguishable from the decision never having existed.
• Put the role structurally in the path. If something cannot proceed without the role's input, the consultation happens without anyone needing goodwill. Goodwill is not a control.

Why This Survives Every Reorganisation

Because it never appears as a problem. It appears as a series of individually defensible moments.

Nobody writes down "we bypassed the Test Manager again". There is no ticket for it, no metric that moves, no retrospective item, because at no point did anything visibly break. The cost shows up months later as defects that nobody had the standing to insist on preventing — and by then it is a quality conversation, not an authority conversation.

The role description is not the problem. The gap between the description and the day is.

Write the scope. Then honour it — starting with the next time it is inconvenient, because that is the only occasion on which honouring it means anything.

Name the last decision your QA lead made that nobody reopened. How long did you have to think?