Pick Your Own Referee

A quick test for any approval process at your company: Who picks the approver?

In most of the tools I’ve used, it’s the person asking for approval. You write the document, the change, the expense, or the policy update, and then you pick who signs off from a dropdown. It feels like a control. There’s a request, there’s an approval, and there’s a timestamp, and auditors love timestamps.

I ran into this again recently. I was redesigning how our product documentation gets organized and approved, and I sat down with the vendor’s docs on its approval feature. My reaction, by text, was about as short as it gets: “Well that’s kind of weird. If I have to select the approver, then I could select myself or anyone, not the required person.”

That’s the problem. If I can choose who signs, I can choose the friendliest name on the list. I can choose the person who’s too busy to read carefully, or the person who owes me one. In some tools I can choose myself. None of that requires anybody to be dishonest. It just takes normal human behavior. People route things to whoever will say yes fastest, because they want to get their work done.

At that point the approval has stopped being much of a control. What you have is a signature. It records that somebody looked at the thing, maybe, and said okay. It doesn’t record that the right person looked at it.

A real approval binds the approver to the content. A change to the payment system goes to whoever owns the payment system, every time, no matter who wrote it. A contract over a set amount goes to finance. A security exception goes to security. The requester doesn’t get a vote on who reviews their work, the same way a player doesn’t get to pick the referee.

This is an old idea. Separation of duties goes back about as far as bookkeeping does: the person who writes the checks shouldn’t be the person who reconciles the bank statement. Software has its own version. Lots of teams require code review from someone other than the author, and the better setups route changes to certain files straight to the people who own them. The check has to live in the structure, because the good intentions of the person being checked were never the point.

The trouble is that a lot of document and workflow tools quietly break this. They make approvals easy to add, which is good, and they let anyone pick any approver, which is the problem. And because the workflow looks right, with requests and approvals and timestamps, nobody notices it isn’t doing the job. You end up with an audit trail of preferences. It tells you who the requester wanted to ask. It can’t tell you the right person signed off.

If your tool can’t enforce who has to approve, be honest about what you’ve got. It’s a record, and records are useful. Just don’t call it a gate, and don’t point to it when someone asks how you control risk.

The fix usually isn’t complicated. On the first page we piloted, we did this: one named owner, edit rights limited to three people, and all three of them as required approvers. If the tool won’t bind the approver, you can shrink the list of people who could pick one. I’m honestly not sure that holds up past one page, though. Three required approvers on everything could get slow enough that people start routing around it, which is the exact behavior I’m trying to stop. The bigger tool question is still open.

Wherever you land, decide which kinds of content need which approvers, and encode that in the tool if it can do it. If it can’t, write the rule down and have someone check it, even if only on a sample. And never let a requester approve their own work, no matter how much faster it would be.

Look at the last approval you routed and ask whether you picked the right person or just the one who’d say yes.