Field Notes on Growth Creating Complexity

Growth is often sold as a linear progression—a simple matter of adding more users to a machine that already works. In reality, growth is an entropic force. It does not just make the business bigger; it makes the business fundamentally more difficult to manage. Every new feature, every new user segment, and every new hire adds a layer of non-linear complexity that eventually threatens to overwhelm the very foundation that allowed for growth in the first place.

The central paradox of building for the long term is that the things you do to achieve growth often create the friction that slows you down later. This complexity manifests most visibly in the support queue and the founder’s own cognitive load. To survive this phase, you must recognize that growth is a phase shift, not just a volume adjustment.

The Complexity Threshold

In the early days of validation, complexity is low because the surface area of the product is small. You have a few core features and a narrow set of users. Communication is direct, and the distance between a problem and a solution is short. As you move into the growth phase, you cross a threshold where the number of possible interactions between features and users begins to explode.

This is where the "Yes Trap" becomes dangerous. Every time you say yes to a feature request to close a deal or appease a vocal user, you aren't just adding code; you are adding a permanent maintenance obligation and a new variable that must be considered for every future update. This is the origin of the valley between validation and scale, where the momentum of the early days is replaced by the heavy lifting of managing legacy decisions.

Where Complexity Lands: The Support Queue

Complexity does not hide in the code; it reveals itself in human frustration. In the manuscript for The Long Build, I reflect on how support serves as the canary in the coal mine for product complexity. When a product is simple, support is about education. When a product becomes complex, support becomes a form of forensic investigation.

Support is one of the fastest ways to learn what is actually true about the product.

When you are the one who built the product, there is no emotional buffer between you and the complexity you created. A bug isn't just a technical error; it is a personal failure. A user's confusion isn't just a UX hurdle; it is a critique of your clarity. This emotional exposure is a significant part of the founder breaking before the product. The complexity of the system begins to mirror the complexity of the founder's mental state.

Comparing the Phases of Complexity

Understanding how complexity shifts is essential for deciding when to automate, when to hire, and when to delete features entirely. The following table outlines the transition from early-stage simplicity to growth-stage complexity.

The Failure Mode of Perpetual Proximity

A common mistake for founders is trying to maintain the same level of proximity to every detail that they had during the validation phase. They believe that by staying close to every support ticket and every line of code, they can manage the complexity through sheer force of will. This is a failure mode because it ignores the reality of emotional debt.

As noted in The Long Build, founders often care too much to do customer support forever. The very empathy that makes you a good product builder makes you a fragile support agent. Great support requires the ability to absorb volatility without inheriting it. If you stay permanently exposed to every emotional swing of a growing user base, your judgment will eventually suffer. Maturity in leadership includes knowing when to step back and create a buffer between yourself and the noise of the machine.

Strategies for Managing Complexity

If growth is inevitable, complexity must be managed. It cannot be avoided, but it can be tamed through deliberate constraints.

• Simplicity as Strategy: Regularly audit your feature set. If a feature is used by a minority of users but causes a majority of support issues, it is a candidate for removal, regardless of how much effort went into building it.
• Support as Research, Not Just Service: Use the support queue to identify patterns of friction. If the same question is asked five times, the product—not the documentation—is the problem.
• The Leadership Tax: Accept that as the team and product grow, you will spend more time communicating and less time building. This is not lost time; it is the cost of maintaining alignment in a complex system.
• Emotional Distancing: Build systems that allow you to see the data of user frustration without feeling the sting of every individual comment. This preserves your ability to make long-term decisions.

Next Steps for Builders

Navigating the transition into a complex system requires a shift in identity. You are no longer just a builder; you are an architect of a living system. To continue exploring these themes, you can read more about the field notes on the valley between validation and scale or dive deeper into the principles of endurance in The Long Build.

Complexity is the price of success. The goal is not to reach a state of zero complexity, but to build a structure that is resilient enough to carry the weight of your growth without breaking the person behind it.

Follow via RSS: latest articles · full article archive