Operating model design is usually evaluated by how clean the resulting org chart looks — clear boxes, sensible reporting lines, no obvious redundancy. I'd argue this is close to irrelevant to whether the design is actually good, because a clean chart says nothing about whether decisions move faster or more accurately than before.
The design work that actually matters happens before any chart gets drawn: mapping how specific, real decisions moved through the organisation in the recent past, and identifying exactly where that path added delay or ambiguity without adding genuine value. A process map shows how work is supposed to flow. A decision map shows who actually had to say yes, and that second map is almost always messier and more revealing.
I've reviewed operating model redesigns that produced a genuinely elegant chart while leaving the actual decision bottleneck completely untouched, because the bottleneck lived in an informal relationship between two people that no chart could ever capture. The redesign looked successful and changed nothing that mattered operationally.
Good operating model design starts from the decision map, not the org chart, and treats the chart as a downstream artifact — a way of documenting decision rights once they've actually been resolved, not a design tool in its own right.
The test I use with clients is simple: after the redesign, can you name a specific decision that used to take three weeks and now takes three days, and explain exactly why? If the answer is a description of the new chart rather than a specific decision, the redesign hasn't actually done its job yet.