What is a delegation-of-authority matrix, and why does it drift?

Policy–system drift

Almost every organisation has a matrix. Approved, circulated, and enforced by nothing.

So purchase orders route by whoever happens to be in the workflow rather than by value. A disposal below net book value gets the same approval as one above it. A cross-department budget transfer takes the path that a single department’s transfer takes. None of this is anybody’s fault, and all of it is invisible — until somebody asks for evidence that the matrix was applied, and there is none, because it never was.

The second-order failure is worse

Suppose you do encode the matrix in the system. If changing an approval threshold then requires a development ticket and a release cycle, the organisation will simply stop changing them.

And the matrix will drift away from the business quietly, for years — which is the same failure as before, arrived at from the opposite direction. That is the argument for no-code configuration: not convenience, but the fact that a governance rule which is expensive to change is a governance rule that will become wrong and stay wrong.

What a matrix must actually encode

Value thresholds, obviously. But more importantly the CONDITIONS that escalate regardless of value: a disposal below net book value, a related-party purchaser, a transfer crossing departments, a vendor with an expired licence.

Because the amount was never the risk. A system that can only route on value will approve the transaction you were most worried about, correctly, at the lowest level in the organisation.

Terms

• Delegation of Authority (DoA)