The systems we design and operate in technology and business often face challenges that reveal their true nature. Of course, this is not new. In fact, President Woodrow Wilson made the same observation about the U.S. government — a pretty large system itself:
“The trouble with the theory is that government is not a machine, but a living thing. It falls, not under the theory of the universe, but under the theory of organic life. It is accountable to Darwin, not to Newton. It is modified by its environment, necessitated by its tasks, shaped to its functions by the sheer pressure of life.”
This quote offers an insightful way to think about the systems around us. Systems that are Newtonian in nature are akin to physics: Regardless of environmental conditions or outside forces, a set of constant, unchanging rules and constraints govern the whole.
In this quotation, Wilson warns against thinking about government as a set of rules that can simply be assembled once, and, like a machine, run in perpetuity. Instead, he introduces the notion of systems that are Darwinian in nature, where the system itself will necessarily adapt to the conditions around it, finding new optimal solutions over time.
What Is a Darwinian System?
A Darwinian system, drawing on the theories of Charles Darwin, is one designed to change and adapt to its environment over time. The dynamic nature of business means the best systems are Darwinian in nature.
Darwinian Systems in Practice
The hidden truth of most systems is that the dynamic nature of the environments in which they operate shape them. This is particularly true of anything with a human component. Understanding and embracing this quality can lead to the creation of more resilient and adaptable systems.
Realistically speaking, most systems we design and operate in business are more accountable to Darwin than they are to Newton. When we design these systems, whether they’re software, product or organizational, we instinctively believe that they’ll behave according to a set of rules as we understand them today. So, we define abstractions, models and processes that likewise follow these well-defined rules.
Unfortunately, when we do that, we’re also, whether implicitly or explicitly, embedding our assumptions about the current and future state of that system. Let’s take the example of a small startup on its growth journey where many of the key assumptions that influenced how leadership built the system have started to break down. The company now consists of a handful of cross-functional product development teams, but many of the processes and systems in place were formed when the company was much smaller, and few were deliberate.
The team and the product are growing — as is the revenue! — but things are becoming less stable, outages are becoming more frequent, and customers are starting to complain, sometimes publicly. As a leader in this organization, how would you start to put together a proposal for how to bring things back to where they need to be?
Start With Principles
To build systems that can thrive amidst uncertainty, we must start with fundamental principles. Identify the essential requirements that make the system function. For instance, in a software development context, a core principle might be choosing a programming language or framework that optimizes the sharability of code. Or, in a system related to company performance reporting, a core principle could be that all reporting data is stored in the same centralized system.
Identifying these core principles provides a stable foundation upon which you can build the system while also identifying areas where you don’t need to be overly prescriptive. Understanding where to draw the line comes down to being very intentional about the goal and what the principle is achieving.
In the previous example, the centralization of reporting data could be a principle because it forces all data to be housed together, making it easier to provide self-service access to data, derive insights, and report more frequently to the executive team. Prescriptiveness in this area might not extend to, say, the visualization of the data, since individual teams’ needs could be different and evolve over time.
These principles should be intentional, only featuring what’s necessary to support the rest of the system, and can be thought of as the environmental conditions that other parts of the system can evolve around.
Principles in Practice
As you start to dig into some of the issues plaguing your organization, a few things catch your attention. When the company was much smaller, everyone understood that the founder would review and test every new feature. As the company grew, this approach didn’t scale, so each team began to launch new features on its own, uncoordinated from the others, leading to customer confusion and system instability.
Understanding that teams have likely diverged into very different operating models, you may be tempted to define a prescriptive process for everyone to follow to get back on the same page. Instead, you should simply start with two foundational principles that every team adopts:
- All teams participate in Demo Day to show off their new features to other teams prior to launch.
- All teams launch their new features in predefined deployment windows to stay coordinated.
By defining these two base principles, you will bring consistency across the organization to solve an urgent need without changing too many things. Further, the teams can likely retain many of their existing processes that are already working for them, and they will adapt and evolve other existing processes to accommodate the new things you have put in place, possibly finding new optimal ways of operating.
Beware Premature Abstraction
Although you have to define core principles, you also must beware of premature abstraction. In software engineering, a concept known as “DRY” stands for “Don’t Repeat Yourself.” This principle means that, if the same thing is being done in more than one place, “abstract it away” (i.e., make a central version of it), and have that now be the standard version that should be used everywhere.
This idea isn’t limited to software developers, however. We all crave consistency and predictability, and when we find a new solution, process, or tool we like, the tendency is to prescribe it as the new standard. Overly rigid abstractions like this can stifle adaptability and hinder the system’s ability to respond to local conditions and specific situations. A one-size-fits-all approach often falls short in diverse environments.
Instead, you should design systems with guidance and suggestions that allow for local adaptations. Encouraging experimentation and embracing variability while adhering to the foundational principles can lead to a more resilient system. This approach fosters innovation and helps identify best practices that can scale across the system.
Abstraction in Practice
The teams have started to adopt the principles you’ve put in place, and you’ve seen them mature. So, you’ve often considered bringing even more standardization to their day-to-day operations. Teams have different ways that they plan and talk within their company about new features, prioritize their backlogs, and even structure their working days.
But you’ve noticed that one team in particular has demonstrated a lot of success with a set of documents they’ve been using recently to plan their projects. So, you share this with the larger organization and encourage others to try it out — not as a mandate, but as an opportunity to see how it works for them in their teams and in that context. This is where key components of evolution start to come into effect; natural selection and mutations invariably happen as teams adopt these documents and try them out for themselves. Over time, the teams settle on a couple variations of the template that broadly work for most projects and situations which become the de facto standard.
Optimize for Change
Change is inevitable, and you need to optimize your systems to handle it gracefully. This involves creating feedback loops to continuously monitor system health and effectiveness. By treating these systems as living entities, we can ensure they evolve in response to changing conditions and quickly take advantage of when new innovations are made. In a business context, change can come from any number of internal or external sources: company growth, employees joining or leaving, the competitive landscape, technology advancement. The list is endless.
New standards and best practices may emerge from this evolutionary process, which you can then apply more broadly. Conversely, you may eventually need to revisit and revise some of the foundational principles as the system grows and adapts. This iterative approach ensures the system remains relevant and effective over time, but it requires constant examination of the effectiveness of what is currently in place and if it’s time to adapt to an environment that has changed.
Change Optimization in Practice
Over time, your startup continues to grow, and so many of the things you put in place when it was a handful of teams simply don’t apply anymore. For example, the Demo Day every team anchored around became untenable beyond 10 teams, and you needed to design a new solution for creating visibility and coordination on what teams are launching. You recognized this when the meeting started to become extremely long, turnout started to wane, and engagement wasn’t the same as it was in the beginning.
The project planning templates spread through the organization like wildfire, however. The templates went through many iterations as teams tweaked them to fit their specific needs, but eventually they reached a point where most teams were using them without the need to modify them further, so you decided it was time to make it a foundational principle of the product development process.
What both of these things have in common is that the components of the system — the Demo Day and the templates — did not change. Instead, the environmental conditions around them did. This recognition of change in the environment and the adaptability of the components within it are the qualities of a Darwinian system that makes it so resilient.
Think Darwin, Not Newton
Whether designing a framework, a process or an organizational system, it is tempting to prescribe a well-thought-out, detailed description of how something should work in every imaginable condition. Designing systems that embrace a Darwinian approach requires a different mindset, however. Instead of striving for complete control and predictability, acknowledging and preparing for uncertainty can lead to more robust systems.
By starting with a minimalistic set of principles that focus on only what is absolutely required, avoiding premature abstraction and embracing change, we can create systems that are resilient, adaptable, and capable of thriving in a dynamic environment. This evolutionary approach ensures that our systems not only survive but also flourish amidst the inevitable changes and challenges they will face.
