Brave New Work

Home > Other > Brave New Work > Page 10
Brave New Work Page 10

by Aaron Dignan


  What does it mean to be Complexity Conscious about resources? Accept that you cannot predict the future. Choosing how and where to spend your money a year in advance is folly. Minimize long-term commitments where appropriate to maximize discretionary funds. Ignore annual rhythms and allocate resources dynamically based on real-time information.

  INNOVATION

  How we learn and evolve; the creation of something new; the evolution of what already exists.

  Growing up, my father would say to me, “Two wrongs don’t make a right, but two Wrights make an airplane.” Perhaps no story better epitomizes the idea of American innovation than the story of Orville and Wilbur. Over the course of three years and numerous attempts, they invented, built, and flew what is generally credited as the world’s first successful airplane. The flight was just fifty-nine seconds and 852 feet, but the aeronautical engineering that went into it—including the invention of three-axis control—is still with us today. Our modern perception of innovation is synonymous with their story. Mad men. Isolated. Focused. Relentlessly pursuing their vision through years of trial and error. Innovation, we believe, must be done by innovators in the laboratory. The rest of us should just keep our heads down. Innovation isn’t a distributed phenomenon; it’s a department.

  But innovation doesn’t have to be so intentional. It often occurs when things are used in ways we did not intend. Paleontologists Stephen Jay Gould and Elisabeth Vrba coined the term “exaptation” to describe the phenomenon of a biological trait being co-opted for another purpose beyond its initial advantage. Exaptation isn’t limited to biology, though; it happens in business too. Corning invented Gorilla Glass in 1960 and shelved it for more than forty years. It wasn’t until Steve Jobs came calling that they realized it was perfect for smartphone screens. Alexander Graham Bell invented the precursor to the telephone in order to help deaf students visualize sound. Percy Spencer invented the microwave when a magnetron melted a chocolate bar in his pants pocket. Play-Doh was supposed to be a cleaning product for wallpaper until kids started “misusing” it. While we like to think of modern life as the result of human ingenuity and eureka moments, the truth is that accidental breakthroughs have led to as much success as their more intentional counterparts. Randomness and innovation are good friends.

  Of course, this presents a problem. One of the primary goals of global brands and institutions is to eliminate variation and ensure conformity. That’s the only way to provide a consistent experience. But eliminate variation and you’ve stopped evolution dead in its tracks. While a centralized innovation hub might be able to produce a few hits, it severely limits the likelihood of exaptation. And importantly, product innovation isn’t the only kind of innovation we need. Not even close. Every activity in the organization is a black box of potential energy. If every team isn’t constantly learning and improving in ways big and small, we’re missing our chance to pursue our purpose with everything we’ve got. Innovation can happen intentionally or unintentionally, centrally or out at the edge. We need to ensure that we’ve thought about, and made space for, evolution at all levels.

  Thought Starters

  Innovation Everywhere. Because of our obsession with efficiency, most organizations like to keep innovation and operations separate. They build things and they run things. But within the last decade, DevOps has emerged as a software engineering culture and practice that has completely upended that notion. As teams release software faster and more frequently, the interaction between development, quality assurance, and operations was stressed. Developers want change. Testers want risk reduction. And operators want stability. The solution was to bring these functions together into one continuous process. When teams are truly empowered, customer focused, and functionally integrated, it can be hard to say where “innovation” happens. Amazon recently confounded the Securities and Exchange Commission when it refused to disclose its research and development spending in the same way other major public companies do. At present, the company discloses only “technology and content” spending of more than $20 billion. When pressed as to why it couldn’t break out R&D spend, the firm’s worldwide controller wrote, “Our business model encourages the simultaneous research, design, development, and maintenance of both new and existing products and services. For example, our teams are constantly working to build new Alexa skills and simultaneously maintain current skills, and these activities are within a continuum of those described in ASC 730–10–55–1 and 2 and are not easily distinguishable operationally.” The point? We do so much innovation so frequently in so many places here at Amazon that it’s not worth tracking project by project the way other companies do.

  Watch What Spreads. In his book Reinventing Organizations, author Frederic Laloux shares a story of innovation at Buurtzorg that highlights how innovation moves when we don’t try to force it. A group of nurses within the organization had noticed that when their elderly patients suffered a fall, they often broke their hips, which reduced their autonomy (sometimes permanently). So they created a new program focused on accident prevention and delivered it in their local market. They were so excited with the results that they brought them to Buurtzorg CEO Jos de Blok. This program should be rolled out across the entire company, they said. But instead of assigning a task force or piloting the program in other regions or announcing it as a company-wide initiative, he did something else entirely. He asked the team to write a story about what they’d created and publish it to the company’s internal social network, along with a guidebook for how to stand up the program. If the idea was good, he reasoned, it would spread. Before long thousands of Buurtzorg’s nurses were working in what are now called Buurtzorg+ teams—delivering home care and accident prevention. If teams are truly free to try new things and adopt what works, innovation can become organic. Next time you hear a great idea or see a winning approach, don’t roll it out, offer it up.

  Biological Barbells. Sometimes it’s hard to know how much variation or innovation is necessary. Should you put your resources behind what is working right now or invest in the future? Nature offers us some clues. By studying complex adaptive systems such as ant colonies, scientists like Deborah Gordon have discovered that ants increase and decrease the randomness of their collective explorations using algorithms that balance information and risk. If a colony is released into an empty room (low/no information) they will fan out in increasingly random patterns. Introduce an apple (valuable information) and they will quickly converge upon it. Interestingly, most but not all of the ants will seize on the “sure thing” the fruit represents. Their built-in algorithms ensure that some percentage of their membership continues to look for the next big thing. This harkens back to Taleb’s barbell strategy. When we have a sure thing on our hands, we should deploy most but certainly not all of our resources there. When we don’t know what’s going to work—in a startup or new division, for example—we need to increase exploration, randomness, and variation, even if it feels a little counterintuitive.

  Innovation in Action

  Defaults vs. Standards. It’s easy to get in the habit of cementing practices, methods, tools, and products as standards. Standards tend to be enforced. We use this tool and only this tool. We evaluate leads using this process and only this process. And so on. The great thing about standards is that they show us a proven way to do something and they are reliable (for the most part). The problem with standards is that they undermine our ability to use judgment, innovate, and learn. Instead of enforcing standards, think about proven practices as defaults. Defaults are exactly like standards with one exception: you don’t have use them. A default says: If you don’t know what you’re doing, do this. If you don’t have time to think, try it our way. But if you’ve achieved some level of mastery in an area and you think you see a better way, feel free. Let us all know how it goes, because either you’ll generate further proof that our default is sound or you’ll sow the seeds for a new default that we can all benefit from. In the case of
my firm, we maintain a default fee structure for our services. If an experienced member wants to try something different—a price premium, a discount, an equity swap—there are no rules against that, but we want to learn from it. Our members know they can take a risk and go their own way, but only when they think that we all stand to benefit.

  Twenty Percent Time. Google famously offered its early employees the opportunity to spend 20 percent of their time pursuing personal projects that might or might not have a clear connection to their daily work. We have this program to thank for products such as Gmail, Google Maps, Google News, and even AdSense. All of them grew out of projects started in employees’ spare time. Valve Software, as we’ve discussed, went one step further. They offer employees 100 percent time. Work on what compels you; change it up at any time. Now, you may not be ready to go that far, but consider applying Google’s model in your team for a ninety-day trial period. Remember, the day-to-day workload is going to undermine this program at every turn. That’s what happened at Google in recent years. You’ll have to model and support this practice with discipline and passion to realize its many benefits.

  The Lean Startup Method. Inventing the future is hard. The early days of any startup (including new ventures inside established companies) are all about the search for product/market fit. The problem is that we fall in love with our initial vision and spend months and years perfecting a product that never sees the light of day. When we finally share it with customers, we’re astonished to find that it doesn’t really meet their needs or that their needs have changed. The Lean Startup method offers a more scientific approach to new-product development. Developed by Eric Ries, the method proposes a feedback loop containing three stages: build, measure, and learn. To get started, pick a problem you are interested in and have the agency to solve, and build a minimum viable product (MVP) that will allow you to get user feedback as quickly as possible. You’re going to be engaged in what Ries calls validated learning. Instead of trusting your assumptions and barreling ahead, you’re going to identify them and ask one of the most powerful questions in innovation: how might we validate that?

  Innovation in Change

  OS transformation rarely starts with a focus on the practice of innovation, because other domains are typically what hold our creative energy back. But in the end, finding our way to an Evolutionary OS is all about change. We want our organizations to be more agile and adaptive. What that means in practice is that we want to get better at learning, better at finding and trying new things. This applies at the product level, of course, where we meet the market, but it’s equally important in our way of working. The act of working on any dimension of your OS is an act of disruption and invention. So while you might not get around to talking about the system-wide approach to novelty right away, rest easy knowing that you’re working on it.

  Questions on Innovation

  The following questions can be applied to the organization as a whole or the teams within it. Use them to provoke a conversation about what is present and what is possible.

  What is our philosophy on innovation?

  Where, when, and how does innovation happen?

  Who participates in innovation? Who has the right to innovate?

  How do we approach incremental and disruptive innovation?

  What is the role of failure and learning in innovation?

  How do we evaluate new ideas, approaches, and products?

  How do we balance the short term and the long term?

  How do we manage our portfolio of ideas, prototypes, and products?

  What does it mean to be People Positive about innovation? Recognize that people are inherently creative given the right conditions. Trust them to sense opportunity and pursue it fluidly. A true culture of innovation is one where we can’t tell the difference between operations and invention.

  What does it mean to be Complexity Conscious about innovation? Accept that innovation is inherently uncertain. A healthy amount of variation and divergence is necessary if you want a vibrant ecology of self-renewal. Have the discipline to make bets in good times and bad.

  WORKFLOW

  How we divide and do the work; the path and process of value creation.

  When Henry Ford introduced his moving assembly line in 1913, he changed the flow of work through the factory. The process was divided into eighty-four discrete steps, and none other than Frederick Taylor himself helped to optimize each of them. The build time of a Model T went from twelve hours to just two hours and thirty minutes. Nearly half a century later, Taiichi Ohno and the Toyoda family developed the Toyota Production System, a just-in-time approach to manufacturing that sought to eliminate muri (overburden), mura (inconsistency), and muda (waste). Once again, automotive workflow was forever changed for the better, and not just in the factory but throughout the entire organization. Improving workflow, the way value is created, is a continual source of advantage for the firms that do it. They gain speed, quality, efficiency, and in many cases simplicity. Yet it’s routinely overlooked in favor of cosmetic changes to structure that rarely change how work gets done.

  But wait a second, aren’t structure and workflow the same thing? If we have clear roles, doesn’t that tell us how we create value? Perhaps. Let’s explore that through the lens of a coffee shop. For the sake of argument, let’s consider just two roles: cashier and barista. The cashier handles the money. The barista handles the coffee. That’s clear enough. But who will take the orders? The cashier could take them, charging customers while the barista works in the background. Or the barista could take them and make them while customers wait in line to settle up with the cashier. Both have their pros and cons. But regardless of which we choose, by establishing that accountability, we are shaping the workflow, how an order becomes an espresso. Behind that decision are a hundred more. Should the order be written down, called out, or entered into a system? How should the equipment be arranged in the space to support the process? If the line gets too long, what then? These questions must be answered, whether they’re answered in agreements about roles or process or established as emergent norms through trial and error. Visit three different coffee shops. You’ll find that they all have similar roles, and they all make coffee, but each in their own way. Workflow, it would seem, is the fuzzy logic between our value-creation structure and our value-creation process. It’s how the work flows through the organization. And it’s how the work flows through the teams themselves.

  Making a perfect cup of coffee is complicated, but it’s manageable compared to making an Airbus A380, an aircraft with more than 2.5 million distinct parts produced by 1,500 different companies around the world. Just imagine that workflow and all the permutations of it that exist. How many projects are nested inside a product-development effort that massive? The answer, of course, is too many to keep track of. And this is true far beyond the world of aviation. In my experience, very few organizations have a handle on all their projects, how they move through the organization, or how they’re managed day to day. This is, in many ways, a by-product of functional division. When you nurture large functions—engineering, marketing, human resources—you create an environment where important projects have to cut across the matrix and necessitate the participation of a wide variety of disconnected people. In terms of workflow, that’s like salmon swimming upstream. So how do we make sure these people do what they’re supposed to do? Enter project management. Since the team working on the project isn’t really a team, we appoint a project manager to shepherd the herd. Of course, they lack the authority to really lead the effort, because all the participants’ allegiances lie with their functions. Still, it gives us someone to hold accountable. And while we’re at it, wouldn’t it be nice if all these projects used the same “efficient” process? All hail the project management office (PMO), yet another group that will define and maintain the standards that our project ma
nagers enforce. This is what passes for workflow innovation in corporate America today—an additional layer of bureaucracy.

  Of course, there are alternatives. Spotify, the Swedish music-subscription service, is often lauded for its structural innovation—the squads, tribes, chapters, and guilds that have been copied (often badly) by other firms around the world. It’s true that a network of multidisciplinary teams working on self-contained projects is part of the company’s special sauce. But what’s really impressive about Spotify’s workflow is how it ensures that teams are “loosely coupled but tightly aligned.” This concept, previously introduced in the Netflix Culture Deck (an employee handbook on steroids), suggests that we maximize strategic alignment but minimize dependencies and red tape among teams. When you’re building a single piece of software used by seventy million paying subscribers, that’s easier said than done. Early on, Spotify realized that if it treated its product as one monolithic application, the coordination required among teams would be too great. So the company cut it up and created the infrastructure to support a modular approach. Now teams own a specific piece of the experience (or the infrastructure) and have the autonomy to develop and deploy it independent of one another, in service of a continually renewed collective vision. Instead of one massive ocean liner winding its way through a series of functions, Spotify’s workflow looks more like a regatta of speedboats heading in the same general direction. It’s not perfect, but it’s deliberate—prioritizing the things that matter to the company. May we all be so intentional.

 

‹ Prev