"Look, this is a complex site. It's just how it is."

The turnaround didn't go as planned. Scope ballooned late. Day 1 was messy. The change requests never stopped. Crews did what they could, but there were more surprises than anyone wanted, and the event landed over budget and a few days late. Then, deep into the postmortem, after a long list of issues, somebody shrugs and says it.

And there's truth in it. The plant is complex. Old units, tight plot, a tough regulatory context, narrow outage windows, mixed crews. All real. But that same sentence makes a very comfortable excuse.

Complexity isn't going away. So the question was never whether your environment is complex. The question is whether you treat that complexity as something to design for, or just something to blame when the numbers come in ugly.

Engineers borrow a useful distinction here, between essential and accidental complexity.

Essential complexity is baked into the domain. In maintenance and turnaround work, that's the hazardous processes, the intertwined systems, the tight plot space, the regulatory load, and the physics and chemistry of your plant. You don't get to wish any of it away, and if you don't respect it, it will surprise you.

Accidental complexity is the complexity you pile on top through your own choices. Convoluted processes. Siloed organizations. Bad data. Unclear roles. Misaligned systems. And this is where most of the pain actually lives. One-size processes that misfit the event. Late changes waved through without pricing their footprint. Uniform KPIs forced onto sites living in different realities. EAM dashboards trusted over the people in the field. People complexity left to luck because headcount looked fine on paper.

Leadership's job was never to eliminate essential complexity. It's to stop stacking accidental complexity on top of it, and to design systems that cope gracefully with whatever can't be simplified.

Step back across these eight complexity posts and one pattern runs through all of them.

Scope can look fine in total hours and still hide dangerous work density and risk clustering. Generic processes can smother the simple jobs and starve the complex events. A late change can drag a good plan into chaos by multiplying constraints at the worst possible moment. A multi-site dashboard can flatten genuinely different plants into a misleading row of comparisons. An EAM can show tidy green KPIs while the field improvises around missing data. And people complexity, skill, turnover, the shadow processes, can flip the outcome of the same plan twice.

None of that is an inevitable cost of operating in a complex domain. Every bit of it is the cost of not designing with complexity in mind. The more unacknowledged complexity your system carries, the harder it gets to run it, change it, or trust it.

If complexity is a given, it ought to be one of the first things you design around, not the last thing you complain about. The loop is simple enough to run before any major event or program:

This is design-for-maintainability thinking, aimed one level up. The thing you're designing isn't a pump or a piping run. It's the maintenance and turnaround system itself.

None of this has to stay abstract, and most of it has already shown up in this series. Event tiers instead of one process, so a quick complexity read sets the planning depth, readiness checks, and governance an event earns. Scope shaping, where you look at the work as patterns of mix, density, and enabling work rather than a flat list, and design out the hotspots. Change control that prices complexity, making late adds progressively harder to approve and forcing a clear view of their hit to permits, scaffolds, crafts, and critical path. Multi-site segmentation, grouping plants by complexity and maturity and tailoring the support instead of ranking them on one ruler. EAM grounded in the field, with data cleanup aimed at the critical assets first and validated by walkdowns. And crew and supervision designed deliberately for the big events, not treated as a generic headcount line.

Every one of those is the same move: treating complexity as an explicit input, not a surprise that shows up on Day 1.

In the end, this is a leadership stance more than a toolkit.

One stance says: our environment is complex, so misses and variability are just part of the game. The other says: our environment is complex, which is exactly why we have to be more deliberate about how we design scope, processes, data, and teams. The first uses complexity to explain the outcome after the fact. The second uses complexity to inform better choices before the fact.

Leaders who take the second stance stop asking whether complexity can be eliminated. They ask two sharper questions instead. Where is our complexity genuinely unavoidable, and how do we design around it? And where have we added avoidable complexity, and how do we remove it or move it somewhere we're strong? That's a very different way to walk into the next outage, the next multi-site rollout, or the next big change.

Complexity won't shrink because you wish it would. In most industrial environments it's growing: more interconnections, tighter margins, stricter rules, more digital layers stacked on top. The organizations that thrive won't be the ones with the simplest plants. They'll be the ones that treat complexity like any other design variable, something to measure, allocate, and engineer around, instead of something to blame when things go sideways.

The work of complexity-aware execution is never finished. But every time complexity becomes an input to design instead of an excuse after the fact, the work gets a little saner and the outcomes get a lot more predictable.

That handles the complexity half of this series. The other half has been about debt, what you borrow against asset health and what it costs you. In the final post, we put the two together. Because when you design for complexity and pay down your debt on purpose, you stop just avoiding losses and start building something that compounds in your favor. Call it reliability wealth.