Convolution / Evolution
As digital products grow, complexity has a way of sneaking in. Features are added, functionality expands, more and more edge cases and personas are accounted for. While these additions are almost by definition well intended, this accumulation of complexity can quickly transform into what Huggy Rao and Robert Sutton in their book The Friction Project call “addition sickness.” In a quest to add value, teams pile on complexity, often creating a product that’s paradoxically harder to use and, crucially, even harder to fix in the future.
Complex software begets a complex org chart, and the two feed off each other like a digital Ouroboros. As systems grow, the number of people, processes, and dependencies involved in making changes expands, which naturally slows down decision-making and execution. The more layers you add — whether they're teams, systems, or approval processes — the harder it becomes to move quickly. Furthermore, the reliance on key people or critical systems creates bottlenecks. "Move fast and break things" may have been a rallying cry for early-stage startups, but when an organization reaches a certain scale, this rapid-fire approach often results in hyper-pivoting, constantly broken organizational structures that burn through people in overstressed positions. When human relationships within the company can’t keep pace with technological changes, complexity becomes an impeding force, slowing down progress and innovation.
So does this mean we should abandon complexity altogether, stop adding features and spend all our time paying down tech debt? Absolutely not. A concept called “The Camel Principle” illustrates why not all complexity is bad, and in fact, why certain types of complexity are extremely valuable.
“The fable behind the Camel Principle involves three sons inheriting 17 camels, which can’t reasonably be divided according to their father’s will: that the sons should respectively inherit 1/2, 1/3 and 1/9 of his herd. A wise neighbor lends them one camel, making the total 18. The sons then divide the camels as instructed, taking 9, 6, and 2 camels respectively, and the neighbor takes back the loaned camel, leaving everyone satisfied. The principle shows that temporarily adding complexity can simplify solving otherwise intractable problems.”
The Camel Principle illustrates a critical concept: in specific circumstances, adding complexity to a problem can in fact make it easier to solve. Complexity that increases the quantity or quality of available solutions is good complexity. It's the kind of complexity that makes future decisions easier, not harder.
But let’s also consider the above example if the father’s herd were initially 18 camels—would the sons benefit from the well-intentioned neighbor lending them a 19th? Almost certainly not. The added camel would introduce unnecessary complexity, complicating what was already a solvable problem. This highlights an essential truth: not all complexity is helpful, and adding it without careful thought can create more issues than it resolves. Now, bring this idea into modern business, where there’s a rush to inject AI into every process. If your core business model relies on repeatedly “dividing herds of camels,” is it always wise to add the immense complexity of a costly, opaque AI system to every decision? Sometimes, AI may offer game-changing value, but other times, it merely complicates processes that don't need it.
The problem with unchecked and unintentional complexity is that it gradually narrows the "solution space" — the range of future improvements, adjustments, or innovations that can be realistically pursued. Picture the solution space as a playground where designers and developers have room to explore new ideas and tackle emerging challenges. As complexity accumulates without careful management, walls begin to form in this playground, limiting the freedom to experiment and improve. Changes become riskier, and small tweaks can lead to a cascade of unintended consequences. The more convoluted the system, the fewer opportunities there are to introduce meaningful, impactful updates without further complicating the product or alienating users.
Adding complexity should be a strategic move aimed at expanding the solution space. For example, when you implement multi-factor authentication (MFA) for security, you’re introducing complexity into the login process. But that complexity is justified because it makes the system more secure, and this security foundation expands the solution space for future features. Now, with robust authentication in place, you have more freedom to build advanced permissions or other security-sensitive functionalities without compromising the integrity of the platform.
In contrast, consider the example of implementing a machine learning recommendation engine into an e-commerce platform. This might seem like an exciting, cutting-edge feature that promises to personalize the user experience and boost sales. However, if the system requires massive amounts of data, constant recalibration, and a team of specialists to maintain, it can quickly overwhelm the company. Worse, if the recommendations aren’t accurate or intuitive, users might disengage entirely, leading to a decline in trust. The complexity of managing this AI-driven system can start to outweigh its benefits, making future updates more difficult and resource-intensive. You might find yourself spending more time troubleshooting and fine-tuning the system than delivering value to your customers. Instead of expanding the solution space, this added complexity shrinks it by limiting the team's ability to pivot or make simple improvements without triggering unintended consequences throughout the platform.
This is the crux of the Camel Principle: complexity implemented today should simplify the future, not make it more convoluted. When you add a new layer of complexity, it should open up more possibilities than it closes off. Consider the architecture of a product. Adopting a modular design might introduce more upfront complexity—it requires careful planning, more documentation, and thoughtful integration. But once in place, this structure allows for easier, faster iteration. Modules can be adjusted or replaced without disrupting the entire system, which expands the solution space, giving the product the flexibility to evolve without becoming fragile.
The key is to ask the right questions before introducing complexity: Does this change increase or decrease our ability to adapt in the future? After implementation, does it simplify or complicate the solution set? If the added complexity doesn’t expand the solution space, you’re likely better off without it, and future-you will thank you. The guiding principle should be to design for long-term adaptability, where every decision is evaluated not only for its immediate benefits but also for how it shapes the product’s future potential.
Making the right decisions about implementing complexity is inextricably linked to a mindset that favors intentionality and long-term thinking. Every addition to the product should be scrutinized through a lens of future adaptability. Does this feature or process expand the product’s potential, or does it limit it? Does it make innovation easier, or does it build walls around what’s possible? This kind of reflective, disciplined approach is essential to keeping complexity in check while ensuring the product continues to grow and evolve.
Ultimately, the goal isn’t to avoid complexity but to maximize your product’s ability to survive in an ever-changing tech environment. Companies that focus too strongly on minimizing short-term complexity may find themselves without the right tools to address future challenges, while those that let complexity run unchecked may find they've ultimately painted themselves into a corner. The key is to strategically embrace complexity when it expands the possibilities for future innovation and to avoid it when it limits future growth.
