Reorganize, or Make Better Decisions? The Variable Most Cross-Functional Failures Miss

By Todd Corbett, Xcelus

When something goes wrong across departments — a data breach that also involved employee misconduct, a harassment complaint that also created exposure to retaliation — the instinct at the top is almost always the same. Redraw the org chart. Add an escalation policy. Stand up a committee. Clarify who reports to whom.

Those responses are legitimate. Sometimes, the structure really is broken and needs fixing. But they share a blind spot: they treat the problem as a wiring diagram when the failure usually started somewhere the diagram can’t reach — in a single decision made by one employee at the moment the incident first surfaced.

Three Leaders, Three Reporting Lines, One Incident

In most mid-to-large organizations, compliance, IT security, and HR are led by three different leaders, each with a distinct mandate and reporting line. That separation is sensible. Each function is deep, specialized, and busy. The problem is that real incidents rarely stay inside one function’s boundary.

Consider a security event where an employee exfiltrated data they were not authorized to access. To the CISO, it is a technical breach — close the hole, review the logs, patch the access controls. To the CHRO, it is a personnel matter — investigate the conduct, follow the disciplinary process. To the CCO, it is a regulatory-notification event with a clock already running and reporting obligations that do not wait for the other two functions to finish their work.

The same incident. Three legitimate, accurate, function-specific readings. And if each leader handles only their own slice, the regulatory dimension can fall straight through the gap between them — not because anyone was negligent, but because everyone assumed the part that wasn’t obviously theirs belonged to someone else.

The Reorganization Reflex

When an incident like this is mishandled, the after-action review tends to produce structural recommendations. Move compliance under legal. Give the CISO a dotted line to the CCO. Create a cross-functional incident-response committee. Write a new escalation matrix. These are the visible, satisfying responses — they produce an artifact, a new box on the chart, a sense that the problem has been addressed.

And then a structurally similar incident happens again, because the new committee and the new dotted line only matter if someone activates them. Activation depends on a person at the front line recognizing, in the moment, that what they are looking at is the kind of thing the committee exists for. If the analyst who found the breach files it as a routine IT ticket, the most elegant escalation matrix in the world never gets touched.

This is not an argument against reorganization. It is an argument that reorganization is incomplete in itself. Structure determines where an incident is supposed to go once someone recognizes it. It does nothing to create that recognition. Most organizations invest heavily in the first and almost nothing in the second — and then wonder why the new structure didn’t prevent the next failure.

The Decision Hidden Inside Every Cross-Functional Incident

Look closely at where these failures actually begin, and you find the same thing every time: an individual, usually not a compliance professional, making a fast judgment about what kind of problem they are holding.

The IT analyst decides whether the anomaly is a technical fix or a compliance escalation. The HR manager who hears a complaint decides whether it is a personnel conversation or a protected report that carries retaliation exposure and documentation obligations. The employee who witnessed something decides whether it is “not my department” or something they are required to raise. Each of these is a decision. Each is made under time pressure, with incomplete information, using the mental shortcut of whose job is this rather than what is the risk here.

That mental shortcut — routing by department rather than by risk — is the actual failure point. And it is invisible to a structural review, because the structure was never consulted. The decision happened before anyone reached the org chart.

Where Compliance Actually Fits

The honest answer to “where does compliance fit when IT and HR each own their own incidents” is not a turf claim. Compliance does not need to win jurisdiction over the other functions. It needs to exist as a recognition layer inside every function — because the moment that matters always happens where the incident surfaces, not where the compliance team sits.

The frontline employee does not need to become a compliance expert. They are not expected to know the notification deadline under a given regulation or to run the materiality analysis. Their job is narrower and far more achievable: recognize that an incident has a compliance dimension and route it to the people who own it. We call this recognition and routing. The engineer who spots controlled technology going to the wrong person doesn’t solve the export question — they flag it. The manager who hears a complaint doesn’t adjudicate the retaliation risk — they route it. The analyst who finds the breach doesn’t interpret the regulation — they escalate it.

This is the same principle that governs whether someone reports a concern at all. A robust reporting and non-retaliation culture works only if employees first recognize that what they witnessed is reportable. Recognition precedes routing, and routing precedes everything the org chart is designed to handle.

The Variable Worth Adding to Your Diagnosis

So the next time a cross-functional incident triggers the question — do we need to reorganize? — The better question to add alongside it is: did the people closest to this recognize what they were looking at, and did they know where to send it? If the answer is no, a new reporting line will not fix it. The same gap will reopen the next time an incident lands on someone who routes by department instead of by risk.

Structure is worth getting right. So are policies and escalation paths. But employee decision-making belongs on that list of things you examine — and it is the item most consistently left off. It is harder to see, harder to draw on a slide, and harder to declare “fixed” in a board update. It is also frequently the thing that actually failed.

Two of our Compliance Conversations episodes show this dynamic in motion — a data exposure where a leader treats a regulatory obligation as a business risk he can accept, and an investigation that collapses because of a single misread moment. In both, the structure was fine. The decision was not.

Building that recognition reflex across a workforce — so that the analyst, the manager, and the bystander all know how to recognize and route — is exactly what the Decision Readiness Engine™ is designed to do, and what continuous reinforcement keeps sharp between annual training cycles. The goal is not to make everyone a compliance officer. It is to ensure that when an incident crosses the seams between functions, the person at the seam recognizes it.