Move to the Edge, Declare it Center. Everett HarperЧитать онлайн книгу.

FIGURE I.2 Complicated vs. complex systems: Impact of adding one new element on relationships.

       Source: Everett Harper and Josh Franklin, 2021.

      The Mismatch

When we apply complicated problem solving to complex problems, there's bound to be a mismatch. For example, problem solving in a complicated system is often about optimization, where the goal is to fine‐tune a process to reduce wasted time, materials, errors, or friction, while achieving the same outcome. For example, if I want to ensure I get exercise before going to work, I set my alarm, prep my water bottles, and lay out my workout clothes before going to bed. These are steps to optimize my system and reduce the likelihood that I will hit the snooze button.⁵

      Returning to the example of building a plane, once a builder understands the relationships between the elements, from parts, to suppliers, to builders, then the focus is appropriately on building systems to optimize different factors in construction. The focus on becoming efficient saves millions of dollars, and so very sophisticated systems manage these relationships. The key is the valid, tested knowledge of the interactions between each of the elements in the system.

In contrast, complexity affects many industries, but I will focus on an industry where I am most familiar: software development. At one time, software was considered a linear process with well‐understood inputs and outputs. As a result, it could be managed using the same Taylor‐derived principles. The Waterfall method, named after the Gantt chart of successive blue bars of tasks stretched over a linear calendar, was the best practice from the days of mainframes. It gave managers the comfort of prediction, and a stick to enforce compliance when the Waterfall schedule went off‐kilter.⁶ The response to missed deadlines was to double down on the easiest variable to control – add more hours or add more workers.

There are two significant assumptions in this methodology that do not account for complexity.⁷ The first assumption is that the relationship between those elements is correct. The second assumption is that there aren't any other factors affecting the system. Add a factor – you just hired three new engineers who are still learning, your code becomes noncompliant due to a new regulation, or your customer needs a new feature to keep up with a competitor's latest release – and it throws the system completely off.⁸ The project becomes horribly late, way over budget, or is delivered to a customer who rejects it. As engineering leader Leslie Miley told me, “Systems can either be complicated or complex, with the latter exhibiting nondeterministic [unpredictable] behavior. If your system is exhibiting the latter, Perhaps it's time to rethink.”

In software development, one of the most influential responses to the unknown and unexpected of complex systems was iterative development, commonly referred to as “Agile.” Agile refers to the Agile Manifesto, developed over three days in 2001 by 17 industry thinkers and practitioners.⁹ Among many declarations, two of the key principles are “Individuals and interactions, over processes and tools” and “Responding to change, over following a plan,” which is further elaborated as “Welcome changing requirements, even late in development.”

Over the next 20 years, this framework has been adopted, adapted, codified, and, most importantly, shown to deliver value, especially in complex systems.¹⁰ Putting people‐first while welcoming the unexpected is a powerful prescription in uncertain times with complex problems. It is no accident that these processes emerged at the same time that computing power was rapidly increasing in complexity, both in terms of scale and impact. Lean Startup extended the same type of thinking into the innovation and entrepreneur communities, bringing an explicit perspective of learning like a scientist into the creation of software, business models, and companies.¹¹

Even organizations that embodied formal hierarchy – often called command‐control – experienced the shift in leadership models and frameworks. For example, in Team of Teams, General Stanley McCrystal documents how the old centralized strategic model was repeatedly failing in Iraq.¹² The Iraqis were more agile and consistently stymied the progress of his forces. Rather than adding more forces and more weapons, he shifted his model to allow different military units to create experiments, to engage enemy forces in their own way and evolve their local knowledge. He invested in communication systems to accelerate rapid feedback, and to spread successful experiments to other troops. It was this shift that enabled his forces to make significant progress. The principles of agility, communication, iteration, experiments, and rapid feedback are core practices to deal with complexity, uncertainty, and unknowns.

In sum, we've inherited models of management, leadership, and performance that are based on the assumption that systems are complicated, we can predict how the elements in the system will interact, and there is a “right answer.” Unfortunately, this assumption is not effective in an era of increasing complexity, unpredictable elements, and diverse