There’s a relatively new concept being practiced by leading high-tech companies. It’s called devops. Devops is a portmanteau of the words “development” (as in, writing software) and “operations” (maintaining that software and the infrastructure that supports it.) Traditionally, these two functions were distinct. Software developers would beaver away for months, maybe years, and when they were done they’d turn the new software product over to operations to be put into production. Even bug fixes tended to happen episodically so that a batch of them could be thoroughly tested before rollout.
As anyone who has tried to install information systems knows all too well, traditional development methods are slow, expensive, and often deliver software that is out-of-date before installation. And despite this seemingly methodical process, systems are often still buggy because of the complexity of the changes being introduced.
Silicon Valley firms like Google and Facebook have started a trend where software updates are delivered frequently, oftentimes on a daily basis. Development and operations are mushed together, hence “devops.” If something breaks, they just roll back the changes by a day and start over. The risk of going in the wrong direction for very long is considerably reduced.
One of the biggest proponents of the devops philosophy is Jim Whitehurst, CEO of Red Hat, a 7,500 person open-source software company. He’s evangelizing these concepts to CIOs, providing them with a message of hope that they can remain relevant in world that wants solutions delivered faster, cheaper, and better.
But does devops really work? One of the critiques of this philosophy is that systems built using this method aren’t architected; because they grow in thousands of incremental steps they just turn into a messy amalgam. But proponents like Whitehurst counter that it’s not that you don’t have a vision for the system you want to build, it’s just that you don’t need a big bang to get there. As he puts it a recent article: “You start with small, iterative improvements. You release [changes] early and you release them often. That’s what devops is about. It’s a cultural shift. You recognize that big change is hard but little changes are easy. But a whole lot of little changes add up to bigger changes.”
Does the devops concept have lessons for strategists? Could a “stratops” philosophy allow strategies to be seamlessly implemented without having to be operationalized through traditional change management? Would such a philosophy result in more robust (less buggy) strategies delivered faster and with less expense?
I had the privilege of interviewing Whitehurst when writing Strategic Conversations, a book focused on reducing the pain of strategic change by engaging employees early and often in the strategy process. Without calling it “stratops”, Whitehurst was clearly running his company using its principles.
While Whitehurst certainly had a clear vision for where he wanted Red Hat to go, he was also well aware that he couldn’t know the best way to get there because of the complexity, and ever changing nature, of the market. But he was a firm believer that “all strategy problems are shallow with enough eyeballs.”
So, he invites everyone in the company to contribute to innovating Red Hat’s business model. Whitehurst shares the vision and plans of the company widely. If an employee has a good idea, and can convince others to join him or her, then they’ll get an audience. So, instead of a few C-Suite people, perhaps with the help of some consultants, figuring out the strategy, Red Hat engages 7,500 people acting as a kind of social computer. (Actually, even more people participate than that; customers are also brought into the conversation.)
What does this process look like in action? What does business model innovation really mean?
Any business model is constrained by both internal and external forces, otherwise it could grow infinitely. The job of the strategist – and in the stratops model, this potentially includes all employees – is to relax or overcome constraints in order to increase the organization’s opportunity space.
The opportunity space is the company’s market potential given its environment, including such factors as the demand for its products, the cost and availability of inputs, and the legal and legislative climate. In the diagram, the opportunity space is represented by the space inside the solid lines. The different lines represent the constraints on the business model coming from multiple directions. Vendors may be pressuring with the firm with higher prices, competitors may be attacking a market segment, etc.
Often, a business model doesn’t fully exploit its opportunity space. For instance, without changing its business model at all a business might have the opportunity to expand into a geographic region – say Ikea into Beijing – to meet unfilled demand.
A company’s opportunity space is constantly shifting and under attack. The strategist’s job is to parry these attacks and make its own bold moves. The business may be able to shift some of the relevant constraints – R&D progress might have some impact on the firm’s methods of production, changing its price and delivery options. Alternatively, negotiations with suppliers might have some impact on the firm’s price and delivery schedules. Businesses are also able to shift their emphasis and products and services to move into different market segments; Apple has been especially adept at this, going from computers to music distribution, to phones, and now perhaps cars.
The point of stratops is that no longer are just senior leadership responsible for figuring out how to deal with all of this messy complexity, they can rely on the collective intelligence of employees as well, the very people who deal with customers, vendors, and competitors every day. The firm’s social computer is always on.
But besides fostering better business models, stratops also speeds the innovation to market since the very people that need to implement it, employees, have been intimately involved in its development. The need for change management is radically reduced. Or, in the case of Red Hat, it’s actually been eliminated. Whitehurst told me point blank that he never uses change management. He has no need to gin up a sense of urgency, create guiding coalitions, or even spend much time explaining changes because his employees are every day highly engaged change agents.
How effective is the stratops philosophy? McKinsey has found that projects that use a traditional strategy development process have an about 30% success rate in achieving the stated goals of the change. But if employees are meaningfully involved, success rates are closer to 80%.
Maybe this means that your strategists should drink more Jolt Cola, attend more Star Trek conventions, and read more Magna cartoons. The coders have a good thing going.