When Structure Is the Innovation
On October 1, 2009, something quietly historic happened in London. The Supreme Court of the United Kingdom officially opened its doors—taking over judicial functions that had, for centuries, been held by the House of Lords. Same judges, largely. Same cases. But a fundamentally different structure. The highest court in the land was finally separated from the legislature, operating in its own building (the beautifully restored Middlesex Guildhall), with its own identity and its own mandate. No fanfare. No revolution. Just a long-overdue untangling of roles that had gotten blurry over hundreds of years.
Here's the thing that strikes me about this: the problem it solved wasn't a new problem. Legal scholars had been pointing at the awkwardness of having the nation's top judges sitting inside Parliament for decades. Everyone knew the separation of powers felt compromised. But institutions are sticky—they persist long after the original reason for their design has expired. What finally changed in 2009 wasn't the argument. The argument had been won long before. What changed was the willingness to actually do the structural work. To move the furniture. To make the org chart match the intention.
I see this constantly in software teams and growing tech companies. The blurry boundaries that made sense when you had six people are quietly strangling you at sixty. A lead developer who's also doing client calls, writing documentation, and making hiring decisions isn't "wearing many hats"—they're a system waiting to fail. The invisible handoff between your product team and your dev team isn't "staying agile"—it's technical debt, except it's organizational technical debt. The UK didn't need smarter judges in 2009. It needed the courage to draw a clear line. Your team probably doesn't need more talent right now either. It might just need the same thing: someone willing to finally separate the courts from Parliament.