Violating “unity of command” stifled healthcare.gov

Here’s an interesting reference to the story about the “tech surge” to fix healthcare.gov. The story is interesting from a tech perspective, of course. It highlights interesting themes in the tech world about a discernable power law in the performance of great, versus merely good, developers. 

But that’s not why I’m writing this. I’m hearkening back to a much earlier post about the 9 principles of war. One of those is Unity of Command. This quote says it all:

What Abbott could not find, however, was leadership. He says that to this day he cannot figure out who was supposed to have been in charge of the HealthCare.gov launch. Instead he saw multiple contractors bickering with one another and no one taking ownership for anything. Someone would have to be put in charge, he told Zients. Beyond that, Abbott recalls, “there was a total lack of urgency” despite the fact that the website was becoming a national joke and crippling the Obama presidency.

 Unity of Command: For every objective, ensure unity of effort under one responsible commander.

It’s more than just a “failure of leadership.” Leadership is a vague, fuzzy word that we use when we want to lay blame or don’t want to sort out what’s going on. 

But here, a specific failure can be identified. Unity of Command. This project had a pretty clear mission, an Objective. There were substantial resources available. Harry S had it right: the buck stops here.

—-

My last point isn’t that it’s automatically the President’s “fault.” The government is, um, big. But someone should have been in charge of this project and those resources. If resources come from different groups with different bosses, a problem gets moved up the ladder and sorted out at that level. But some ONE has to be in charge. Or it just doesn’t work. That culture of assigning responsibility, or “seizing responsibility” if you’re a Wolfhound or a Ranger, isn’t automatic. It comes from the top, which is leadership by example.

—

I will be adding this to the book’s section on Unity of Command. It raises an interesting question of how this principle, Unity of Command, gets observed in crowdsourced efforts. Off the top of my head, I’d say first that many crowdsourcing contributions are tightly constrained so that not everyone is in charge — you add a rating on Yelp, sure, but Yelp decides what their information structure is, how to add pictures, and what you can and can’t contribute. Open source? Someone owns the project — Linus for the Linux kernel, and then him delegating down to committees and creating or approving rules that say how they’ll approve other changes. And the projects where anyone can contribute sort of anything, like Google Wave collaboratively written short stories, are art projects where the objective is to execute the process, not to build a bridge that won’t fall down or a website that hosts 50,000 concurrent users trying to buy health insurance.