Here’s a wild idea for you.
When the United States was formed as the first modern democracy, its founders had some pretty crazy ideas about how the democratic system would work. People would be elected and leave their jobs to become lawmakers for several years, and then return to their jobs and let someone else take a stab at it. It was an efficient approach to getting the perspectives of the people who made up the nation to collaborate on laws.
But how would they have written the Constitution if they had today’s technologies and insights? Would it have been different?
Enter Jos de Blok, CEO of Buurtzorg, a nursing organization that turned the business of home-care on its head. Unlike traditional leadership that does extensive strategizing and change planning, de Blok has a blog. When he’s planning a change in operations–usually a small, incremental change rather than a massive treatise–he posts it on the blog and allows 24 hours for response from an organization of nearly 8,000. Based on feedback, he proceeds, amends, throws out, or gathers a task force to hammer out the details.
The specifics of Buurtzorg’s approach will not apply for every organization, but the concept is sound: Centralized (non-hierarchical) management of an open-sourced approach.
Open-sourcing has provided not just stable software but some of the most secure software in the world, despite the early concerns over its transparency and malleability. Yet the approach has yet to make much of a leap to other fields, despite being at its core a knowledge method and not a software-specific method. (Wikipedia is among the few notable examples.)
There’s a lot to be learned from the way open-source groups guide development. Many have small development teams that are able to invest and focus on key features that aren’t getting as much attention on the outside. Some companies identify features that have to be developed in a closed environment in order to be valuable, and embed them within a different version of the product. But there are often so many eyes on every line of the source code that it’s difficult to deliberately sabotage the effort, and developers who comb through the code before a final release are typically able to pull out unnecessary operations and tie up loose ends.
These open-source software projects are at work in the wild, accessible to billions of people, and many of the developers working on them have very little personal stake in the outcome except their own excitement about and investment in the project.
Suppose these same techniques were used to guide your organization, every member of which is deeply invested in your policies and decisions. Instead of investing in a complex analysis of the state of your company, you’d get immediate feedback from the people who know it best. Instead of deciding on a change plan and having to get buy-in from every last member of your organization, you’d already have a good chunk of your organization on board. Instead of having to course-correct in the middle of an enormous project, your incremental changes would correct themselves.
If it sounds idealistic, that’s because it is. Don’t misunderstand: It’s a completely practical approach, and may even become a necessary approach to managing large organizations in ten or twenty years. But it’s also idealistic because it requires leaders to relinquish power, and perhaps just as importantly it puts them on uncertain footing. Leaders not only want power for its own sake, they want power because they don’t trust their people, and this approach to an organization’s policy and strategy relies absolutely on trust.
Fortunately there are ways to develop that trust, some of which I’ve already written about. You can treat your employees as partners. You can remove the stigma of failure. You can establish shared values. And as always, you should approach it in the way that works best for your specific organization. But as with any change, at some point you will have to make a leap without knowing exactly where you will land. It can be terrifying, but it’s the only way we accomplish any meaningful change.
Perhaps the Founding Fathers wouldn’t have open-sourced America’s laws even if they’d had the tools. But on the whole they were the kind of people who were always trying to improve upon the work of others. We’d be doing them a disservice if we didn’t try to improve upon theirs, even if it’s only within our own small organizations.
I’m looking forward to discussing your insights and concerns in the comments below.