I.1 Complicated vs. complex systems: Elements only.
Source: Everett Harper and Josh Franklin, 2021.
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.5
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.6 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.7 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.8 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.9 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.10 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.11
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.12 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 global stakeholders. The good news is that we can use a new framework to address complex issues and make better decisions, despite lots of unknowns and uncertainties. Let me introduce a story about one complex issue – diversity, inclusion, and equal pay – and our approach to addressing it using the core practices in Move to the Edge, Declare It Center.
Case Study: Introducing Salary Transparency
Imagine your first day at work, and your business card looks like this:
What would you think? Might you wonder, “Does everybody have their salaries displayed on their business card?” Might you look around and ask yourself, “How do I compare with the other directors?” I suspect you are definitely thinking, “Why on earth would a company do this?”
While we don't have our salaries on our business cards, we did make all salaries transparent in 2017. Why? We wanted to solve a complex problem: racial and gender inequality in compensation. In most labor markets, BIPOC13 people and people who identify with she/her pronouns get paid less than White men for the same job. It is an old, persistent problem, but we treated it as an obstacle we needed to overcome in order to build the diverse, inclusive company we wanted. There weren't many companies to emulate, and we couldn't find any that were doing it explicitly for diversity, equity, and inclusion (DEI) purposes. We were on the edge.
Truss was founded with 67 percent “underrepresented minorities.”14 Our founding team of me – a Black male CEO – and a technical leadership team of a White woman COO and White male CTO was absolutely contrary to the Silicon Valley startup narrative in 2011. Despite degrees from Duke, Stanford, University of California
