On paper, the two outages looked almost identical. Same plant type. Similar scope and duration. Similar labor curves. Same contractor mix. Both ran on the same corporate planning templates and the same milestone model.

One ran smoothly. Deviations happened, but they stayed controlled. Crews kept productive. Decisions got made fast and safe. The event finished close to plan.

The other felt like a street fight from the first shift. Crews waiting on information and permits. Sloppy hand-offs. Workaround decisions made in the field and reported after the fact. A schedule rewritten on the fly, shift after shift.

The plans were nearly the same. The people system was not.

What decided those two outcomes wasn't scope, and it wasn't tools. It was people complexity. The way skill, experience, turnover, supervision, and the informal practices nobody writes down shape what actually happens when you try to execute work at scale.

Most schedules treat people as interchangeable units. Ten pipefitters here. Eight electricians there. Twelve scaffolders over in Area 200. At the planning level, you have to think that way. At the execution level, it's dangerously incomplete.

Ten experienced pipefitters who know the unit are not the same as ten who've never set foot on the site. A stable core crew with low turnover behaves nothing like a rotating cast of contractors meeting each other on Monday. And a supervisor who can coordinate, prioritize, and buffer the crew from chaos changes the entire character of the day.

Ignore those differences and you're assuming the plan will behave the same everywhere. Pay attention to them and you realize something important: people aren't just a cost line. They're your primary complexity-management mechanism. They're the thing that absorbs the surprises, or doesn't.

People complexity shows up in a few predictable ways, and none of them fit on a histogram.

Start with skill and experience distribution. It isn't whether you have enough heads. It's how many of those heads carry deep experience with the plant and its quirks, can troubleshoot when the field doesn't match the drawing, and actually know your safety and work processes. A handful of those people will stabilize a whole crew. Without them, a minor surprise becomes a major delay. Then there's turnover. Churn in the key roles, planners, schedulers, supervisors, lead techs, creates a permanent learning curve. Institutional memory bleeds out, and work that used to be routine turns complex all over again. Role clarity and supervision quality matter just as much. In some shops, coordination is treated as overhead, and supervisors drown in admin and firefighting with no time to actually coordinate. In others, the supervisor is recognized as the person who integrates all the day's complexity in real time. Contractor strategy shapes the whole profile too: one long-term partner with stable crews is a different world from a patchwork of vendors with constantly changing faces, and the more fragmented that landscape, the more complexity you dump onto your planners and supervisors. And underneath all of it sits culture, how people actually communicate, escalate, and make trade-offs when nobody's watching, which matters at least as much as any RACI chart on the wall.

None of that shows up on the Gantt chart. All of it shows up in how the plan behaves once the work starts.

Wherever the formal process and tools don't fit reality, shadow processes grow up to fill the gap.

You know them. The operator who can always make a permit happen when the system's jammed. The tech who knows exactly how to reach a valve in a tight rack even though the job plan is two generic lines. The night-shift supervisor running his own allocation and prioritization rules that don't match the daytime process at all. These exist because people are trying to make a flawed system work, and that makes them a sign of resilience and a source of risk at the same time. Resilience, because people are plugging the holes and keeping the plant moving. Risk, because success quietly becomes dependent on specific individuals and unwritten practices instead of designs you can repeat and improve.

Tribal knowledge is the same coin. When the critical know-how lives in a few heads, your whole capacity to handle complexity is tied to those people. They retire, leave, or burn out, and complexity spikes overnight, on a Tuesday nobody saw coming.

Ignoring people complexity doesn't make it disappear. It just guarantees you get surprised by it.

The symptoms are familiar. Pockets of real excellence and pockets of chronic chaos inside the same plant. Big swings in performance between shifts, or between two supervisors with the same scope. Plan adherence all over the map even when the constraints are similar. And a heavy reliance on a small number of go-to people for the decisions that matter.

From a distance, it's easy to file all that under inconsistency or weak discipline. Up close, you see the real cause. The system was never designed to understand, develop, and deploy its people as the primary complexity buffer they actually are. And here's the hard truth underneath it. If your ability to handle complexity depends mostly on who happens to be on shift, you don't really have a system. You have a few strong people holding the complexity in their heads, and a lot of exposure the day one of them isn't there.

You can't eliminate people complexity. You can design with it instead of pretending it isn't there.

Profile crews for the major events, not just headcount. For the critical tasks and areas, ask what the experience mix really is, how many people genuinely know this unit, and where the thin spots are. Treat front-line supervision and workface coordination as a key lever rather than overhead, because a good supervisor managing constraints, sequencing intelligently, and shielding the crew from noise is doing complexity management, full stop. Mix experience on purpose, instead of stacking all your veterans on one crew and all your new people on another, so every crew has enough depth to absorb a surprise and to grow capability over time. Bring the healthy shadow processes into the light, formalizing the parts that add value and stripping out the parts that carry risk. And capture the tribal knowledge deliberately, through job-plan improvements, walkdowns, and structured debriefs, because every time an old hand says "you wouldn't know this from the drawing, but," that's gold that should end up in a reusable artifact instead of walking out the gate at retirement.

Done over time, that shifts an organization from personality-dependent to system-supported, without losing the value of experienced people who know how to get things done. It's a lot of what execution support is really about: turning what lives in a few heads into something the whole team can run on.

Maintenance and turnaround complexity isn't only scope, systems, and schedules. It's people. Who you've got, what they know, how they work together, and how much of the real process lives in their heads instead of your designs.

You can't simplify the human element. But you can stop pretending a headcount number is a fair representation of it. Treat people complexity as something to understand and design for, and a lot of those mysterious performance gaps between sites, shifts, and events stop being mysterious at all.

Next in the series, we get practical on the debt side. We've spent a lot of posts naming maintenance debt, measuring it, and tracing where it comes from. Now the question every leader eventually asks: where do we actually start paying it down? We'll lay out a playbook.