Dealing with Complexity

TLDR: Complexity isn’t the problem (until it is)

The thing that most often makes me, or the teams I work with, stuck isn’t fear, laziness, or lack of motivation: it’s complexity. It shows up early, making it hard to get started. Or halfway through, where it slowly grinds steady progress to a halt. Rarely does it stop us at the finish line. By then, we’ve usually powered through — by hook or by crook — or walked away entirely.

But here’s the thing: Complexity isn’t inherently bad.

Some problems are complex by nature. Pretending they aren’t leads to fragile work. The goal isn’t to avoid complexity altogether. It’s to be deliberate about where it shows up.

The ideal is a simple solution to a complex problem. That’s rare, but worth striving for. A complex solution to a complex problem? Sometimes necessary. But a complex solution to a simple problem? That’s where things go wrong.

When projects stall

Not too long ago, one of my clients was gearing up to launch a new product. Everyone was aligned on the outcome, but they couldn’t figure out how to break it down. The planning docs grew longer by the day. The architecture diagrams started to resemble the London underground map. Every idea came with a dozen dependencies, and no one knew which part to start with. Eventually, people lost momentum. Not because they didn’t care, but because the whole thing had become too tangled to move.

Why product work attracts complexity

This kind of thing happens often in product development. When the work spans multiple teams, touches old systems, or involves user experience edge cases, complexity multiplies. Add in strong opinions, unclear ownership, and the desire to please everyone, and you’re in deep. Not because of any one bad decision, but because each person added a bit more than was strictly necessary. Now the system is heavy, and no one knows how to lighten it without breaking it.

When complexity is justified vs self-inflicted

Some complexity earns its keep. It exists for a reason. Think of regulatory requirements, or hard technical constraints, or working with a messy legacy codebase that can’t just be rewritten. In those cases, the complexity is part of the job. It’s not elegant, but it’s real. If you remove it, something important breaks.

But there’s also complexity we bring on ourselves. That’s the kind to watch out for. A common source is design-by-committee. Everyone wants to contribute, so features and requirements accumulate. Eventually you end up with a compromise that pleases no one and helps even fewer. Another driver is the quiet belief that if something looks complicated — like a dense spreadsheet or a thick slide deck — then people will respect the effort behind it. Simple can feel risky. Like you haven’t done enough.

Making peace with complexity

I try to stay grounded by returning to first principles. What’s actually required here? What outcome are we solving for? I also lean on the pareto principle: which 20% of the work will unlock 80% of the value? It’s not about avoiding complexity entirely. Some problems deserve depth. But the question is always whether that depth is necessary, or just familiar.

Complexity isn’t going anywhere. That’s fine. The goal isn’t to fear it, but to be intentional about it. To prune, to clarify, to ask whether each piece is really earning its keep.