Everyday Chaos
Page 15
4. McGrath’s transient competitive advantage approach to strategy sees possibilities as real, imminent dangers and opportunities that come and go based on the constantly changing interactions among all the pieces in all of the domains in which business operates: markets, customers, suppliers, employees, management structures, and so on. Being alert to these possibilities requires avoiding the assumption of the fixity of any element of one’s world. Where scenario planning looks out for planet-scale changes, McGrath urges us to be aware of the small changes that, because of the delicate interrelationship of every aspect of life, might push a business over the edge or give it a new handhold up. The possibilities that open up arise from the interactions of everything, which is to say, from the interoperability of all.
5. Finally, flip-chart scenarios treat possibilities as mere possibilities: whatever is imaginable and desirable should, for the duration of the exercise, also be considered possible. And because these exercises are intended to boost morale, the possibilities are always positive, so at the end, no group’s Time magazine cover contains phrases such as “bankrupt,” “doomed,” or “prison time for CEO.”
If strategies reveal how we think about possibility, then we ought to now see some strategic responses to interoperability’s throwing possibility open.
Strategies Wide Open
Strategies facilitate decision making by telling an organization what to focus on, and what not to: focus on the iPhone by getting its operating system competitive with Android while—judging by Jobs’s conspicuous silence on the topic in his slide deck—letting the Mac just glide along for a year or two. Strategizing has thus been typically conceived as a limiting operation. It identifies the possibilities and chooses the ones the organization wants to make real.
But now we’re seeing some organizations think about strategies not in terms of winnowing and reducing possibilities. In an interoperable world, we can succeed at least in part by allowing others to make more of our offerings than we can anticipate. Here are three cases of organizations thinking differently about strategizing and possibility in a world of newfound complexity.
Drupal: Distributing Strategy
Dries Buytaert’s slide deck for the annual Drupal conference outlines a very different type of strategy from the one Jobs did in his email to Apple’s top one hundred.22
That’s to be expected. Buytaert lists himself not as a CEO but as the “founder and project lead” of Drupal, an enterprise that in its structure is just about a perfect reverse image of Apple. Drupal is an open-source content management system developed by more than one hundred thousand loosely affiliated volunteers who share their work and enthusiasm.23 Because of Drupal’s ability to be modified and extended, it’s used by over a million websites.
Buytaert’s slides were intended for the 2017 DrupalCon, the annual gathering of thousands of Drupal developers, held that year in Vienna, Austria. As founder, his words are listened to carefully. But unlike with Jobs’s presentations, the developers are perfectly free to ignore them. “People work on what they want to,” Buytaert told me in the Boston headquarters of Acquia, his for-profit company that provides Drupal-based solutions.24
Buytaert could not compel the community of developers to march toward some goal even if he wanted to. They don’t work for him. They work for the companies that are using Drupal. So, he says, “I don’t give them a roadmap.” What good is a map to a destination if you’ve got one hundred thousand people who want to go to their own happy places?
This, for Buytaert, is a feature, not a bug. “I open sourced Drupal,” he says, “so other people would take it in directions I didn’t expect.” As an example, he cites the Howard Dean presidential campaign’s use of it in 2004 to create DeanSpace, one of the first social networks for political campaigns. Since then Drupal has been used for everything from creating a community out of the fans of Spain’s Sevilla soccer team to providing a self-service site for Australian taxpayers.
Even if Buytaert had the power, desire, and personality required to stand on a stage and dictate a strategy, he knows that doing so would only limit Drupal’s possibilities, making it less able to address the particular needs of each particular site. So in 2017 he did what he does every year: in substantial detail—103 slides at the Vienna meeting—he described the current state of the distributed project that is Drupal (the 22 percent increase in the number of bugs that were fixed in 2016, the 28 percent increase in the number of contributors), how the businesses that provide Drupal services have been doing (they’ve been getting more deals at higher prices), and the competitive landscape (Drupal’s market share is healthy but decreasing).
In his talk, Buytaert did discuss areas of the product he thinks the community should work on, just as Jobs did. But there are two major differences. First, Drupal developers will implement these changes only if they want to. They will not be punished for pursuing different goals. In fact, they are likely to be celebrated for it. Second, Buytaert and the attendees of DrupalCon do not assume the zero-sum approach to resources that is behind traditional strategies’ aim of focusing the business on some possibilities at the expense of others. The Drupal ecosystem is one of abundance.
Buytaert uses the development of an image gallery feature for Drupal to illustrate his point. “There may be five good ways of doing that, but,” he acknowledges, “only one or two will win.” “Winning” in this case means being adopted by many other Drupal users and perhaps becoming a de facto standard for how image galleries are implemented. But that’s not the only way the Drupal community measures success. The other attempts may well find a home with others who share their circumstances and needs; an ecosystem like Drupal’s supports infinite biodiversity.
It’s not easy to create such an ecosystem. “It’s not ‘If you build it, they will come,’ ” Buytaert says. But that ecosystem is of strategic importance, for it multiplies Drupal’s value to its users. Building community and, at least as challenging, avoiding the many ways that online communities can go wrong require care and investment.
This was the topic of Lisa Welchman’s 2013 keynote to the global conference, held in Prague that year. She asked, How do you manage growth of an open organization? Her answer: “This community is like a ginormous fungus.” In particular, it’s like a huge, underground fungus that had recently been discovered in Oregon. A Scientific American article explained the fungus’s growth by saying, in Welchman’s paraphrase, that it has “good genes and a stable environment.” The Drupal community’s good genes are its “standards-based framework,” she explained. The stable environment is the community’s set of social conventions and norms for conduct, ethics, collaboration, and decision making.25 These conventions and norms enable technical and personal interoperability.
With that infrastructure in place, the project doesn’t need a traditional strategy, for a strategy drives toward a particular goal. Far better to simultaneously drive at all the goals that segments of the community deem valuable.
While strategies typically are about removing possibilities to maximize the effort put behind the chosen ones, Buytaert eschews limiting the scope of Drupal developers’ focus. He does so by executing his own personal strategy: “I try to get out of the way of the community.” That facilitates independent developers opening possibilities made real by Drupal’s architecture and that serve the real needs of users. These are, as we will discuss further, real possibilities.
Tesla and Google: Letting Go
On June 11, 2014, the walls of Tesla Motors’ headquarters in Palo Alto were covered with more than one hundred patent awards. On June 12, they were gone, replaced by a wall graphic that paraphrased a meme based on a bad translation in an early video game: “OEMs [original equipment manufacturers]: All our patent are belong to you.” Tesla’s CEO, Elon Musk, had decided to open source the company’s patents: anyone could use its inventions without asking permission or paying for the privilege.
In a blog post, Musk explained his reasoning: �
��Tesla Motors was created to accelerate the advent of sustainable transport. If we clear a path to the creation of compelling electric vehicles, but then lay intellectual property landmines behind us to inhibit others, we are acting in a manner contrary to that goal.” Also, because the major automotive companies were making so few electric cars, Tesla probably did not feel threatened by them. Also, open-source projects draw many of the world’s best engineers. Finally, a patent is “a lottery ticket to a lawsuit.”26 So Mr. Musk tore down that wall.
Tesla still takes out patents, including some highly valuable ones for battery technology, but it abides by its pledge not to sue any company that uses its technology in “good faith,” which means that if a company uses Tesla’s patents, it agrees to let Tesla use that company’s own technology, creating an open-source environment for patented technology.27 It also means that you agree not to use Tesla’s patents to create a knockoff product; if you want to name your electric vehicle company Tessla Moters, you’re going to have to invent your own technology.
Musk has claimed that some companies are using Tesla’s open-source patents, but there are no details available about which companies and which tech. So Tesla’s move may turn out to have been an empty gesture. Nevertheless, it was a gesture with a strategic intent. It is to Tesla’s advantage to have a robust market for electric vehicles, both to create more customers and to advance the infrastructure required to support electric cars. Tesla’s open sourcing of its patents can also help to establish its interfaces as standards.
Google has gone the same route with greater success with a technology not as much in the public eye: in 2015 it open sourced TensorFlow, its machine learning software. It did this even though machine learning is now essential to almost all that Google does, including how it searches, translates languages, sorts photographs, suggests responses to text messages, maps routes for cars, and drives its autonomous vehicles … not to mention beating the world’s greatest go players.28
At a symposium in September 2017 put on by Google PAIR (People + AI Research),29 Zak Stone, then the product manager for TensorFlow, told me why Google made such crucial software freely and openly available.30 As with Tesla, the reasons mix self-interest and commitment to an ideal. By providing open access to the software, the community extends and debugs it for free, which lets Google serve its users better. As with a minimum viable product, Google learns what TensorFlow needs by seeing how people actually use it, and how they use it in ways that Google would not have thought of on its own. As with Tesla, TensorFlow’s libraries and application programming interfaces (APIs) can become de facto standards, enabling Google’s work to interoperate with products it did not create.
Uptake has been far better than with Tesla’s open-sourced patents, in part because adopting a software library is far less expensive and risky than building a factory to produce cars that conform to particular specifications; also, Google does not demand a company reciprocate by opening up its tech.31 Finally, Google understands the lesson expounded by Drupal’s Dries Buytaert: open APIs and standards won’t get adopted unless the organization works hard on building and maintaining a community.
It seems to be working. On the first anniversary of the open sourcing of TensorFlow, Stone posted at the Google Research Blog that 480 people had contributed to the software, including many outside Google; two years later, that number was up to 1,600.32 In that first year, Google released substantial libraries of code for doing high-value tasks such as identifying the objects in images. Crucially, Google engineers and other members of the community had put in the time to answer thousands of questions on the public Q&A sites used by engineers—over 18,000 at Stack Overflow as of December 2018.33 This concerted effort by Google is having the desired effect of jump-starting the AI market, making the work that’s created interoperable and thus ever more useful, and establishing Google as a vital center of development even for work done outside Google.34
This has happened because Google adopted a strategy in the traditional sense: the leadership decided to put machine learning at the heart of the company’s development efforts and turned resources toward that goal. But the forces this strategy is marshaling are not only Google’s. And it’s marshaling those forces not by giving them marching orders, or by pulling levers with known results, but by attracting others through the gravity that shapes networks.
* * *
In adopting these new strategic approaches to strategizing, all three of these organizations have decided to embrace the essential unpredictability of the interoperable universe, rather than resist it. Drupal carefully cultivates open software platforms and a community of developers so anyone on the planet can build something that adds value to the Drupal project; the interoperability of what gets built—a custom image browser that works for one installation is likely to work for all of them—then multiplies that added value. Tesla and Google are building ecosystems that make their products and services more widely usable, and they are doing so by releasing code and tools that will help others populate those ecosystems with value. The two companies understand that widely accepted standards create markets that attract more players, establishing those markets more rapidly. Of course, it also improves Tesla’s and Google’s market positions if their standards become these new industries’ standards.
There are, as always, risks and downsides to these approaches. An open platform faces the same competitive pressures as any other offering; developers are unlikely to flock to the goods and services you’re making openly available unless you’re offering something of truly unique value. It also requires a commitment to maintaining the platform for the long haul; otherwise, developers that depended on your platform will find their work is now broken. And, of course, if you’re not a Tesla or a Google, you may well not be able to drive standards for your industry. All of this costs money, with the risk that you’ll back the wrong standards, or you’ll be stuck maintaining an open API that only a few people have built anything with. Openness isn’t free. But closedness has its own costs.
Step 2
Step 1. Collect underpants.
Step 2. ?
Step 3. PROFIT.
This “business plan” from a 1998 episode of South Park has been the subject of thousands of memes because, even so many years ago, it was clear that fresh-faced high-tech startups were failing to recognize how hard it is to get from a good idea—granted, “collect underpants” is not one—to a functioning, profitable business.
Part of the joke is its Newtonian framework: the missing step that connects the cause with the effect. It’s not simply that the underpants entrepreneurs—who in this episode happen to be gnomes—don’t know what Step 2 is. It’s that they think there is a Step 2: something that will lead to profit as surely as propelling a cue ball at just the right speed and angle will sink the eight ball. But, as we have seen throughout this book, refusing to know can itself be a highly effective strategy.
* * *
We have been confused about how to think about possibility for a long time. Actuality is easy: it’s the stuff we stub our toes on. But possibilities can be many different sorts of things. They can be what has not happened yet. They can be what could be even if they never will never be. They can be fantasies, dreams, fears, predictions, desires, or delusions. But overall, possibilities have been defined by the single thing they have in common: they are the not-real, which can include the not-yet-real, the never-will-be-real, and the never-could-be-real.
Interoperability makes possibilities very real. We know this if only because we stub our toe on noninteroperable systems every time we buy the wrong charger for our phone or the wrong tip for our electric toothbrush.
The serious strategic approaches we’ve looked at—military, RAND game theory, scenario planning, transient competitive advantage—each go through a phase in which the range of possibilities is expanded, only to then be reduced to the single one that will be acted on—McGrath’s less so. The aim is to winnow, to narrow, the f
uture. Such is the tyranny of decisions.
This approach is right at home in the Age of Newton. You don’t want to disperse your limited supply of energy. You want to focus it because the more force you put behind the arrow, the more energy it will travel forward with. So say Newton and McNealy. Likewise, when talking about changing a large organization’s strategy, we sometimes say, “It’s like turning a battleship,” a direct application of Newton’s first law: an object in motion will tend to remain in motion in its current direction. The more massive it is, the more energy it will take to alter its course. Strategies have been our corporate battleships because physical and organizational resources have been so difficult to reassign—sometimes because we’ve optimized logistical and organizational processes to support long-term, nonagile strategies because we have assumed the future will be orderly. That’s the assumption that gave rise to the idea of strategy in the first place.
But now we are able to decouple decision making from strategy, at least to some degree. Drupal, Tesla, and Google are making this strategic move when they provide tools and services that enable people outside the company to decide to create things beyond the companies’ anticipation. Likewise, companies that adopt some form of agile development, that structure their software around an internal API, that put minimum viable products into the market, or that adopt McGrath’s advice, are using strategies that purposefully avoid or minimize the cost of making decisions, of saying yes to this and no to all the rest.