The CC List Is Not a Control

In this article6 min read

There is a particular kind of organisational reassurance that comes from adding another person to an email, another stakeholder to a Teams channel, another manager to the CC list.

Nobody can later say they didn’t know.

We usually describe this as keeping people in the loop. Quite often, it is really keeping ourselves out of trouble.

I understand the instinct. In critical infrastructure, decisions carry consequences and traceability matters. But somewhere along the way we have confused visibility with control. They are not the same thing, and the gap between them is where a surprising amount of delivery risk now sits.

Thirty updates and one that matters

If I receive thirty routine updates a day, each one may technically make me better informed. Most of them reach me because someone added a name to a CC list, not because anyone judged that I needed to act. Collectively, they make it harder to notice the one message that actually requires me to do something.

That is more than an inbox problem. Martin Eppler and Jeanne Mengis reviewed nearly four decades of information-overload research across organisation science, accounting, marketing and information systems, and found a consistent pattern. Performance improves as information increases, but only up to a point. Past that point the curve turns over, and additional information produces slower and worse decisions rather than better ones. A 2023 review in Frontiers in Psychology reached similar conclusions and mapped the personal and organisational conditions that push people across the threshold.

The threshold is real, it arrives earlier than most governance processes assume, and almost nothing in a standard operating model is designed to detect it.

There is a second-order effect as well. Once people learn that most of what arrives through a particular channel does not concern them, they stop reading that channel carefully. The filtering becomes automatic and fairly indiscriminate. When something genuinely urgent finally comes down the same route, it gets treated exactly like the noise that preceded it.

Why the CC list keeps growing

The uncomfortable part is that organisations often create this overload deliberately, in the name of reducing risk.

We copy people because exclusion feels dangerous. We invite everyone because someone might have useful context. We circulate decisions that have already been made because wider circulation feels more governed.

Each of those choices is individually defensible. Together they produce an environment where the cost of being wrong about who needed to know gets paid by everybody, every day, in small increments that never appear on a risk register.

The economics are quietly perverse. Adding a name to the CC list costs the sender nothing and buys them a little insurance. The cost lands somewhere else entirely, spread thinly across everyone who now has to read, assess and discard something that was never meant for them. No single instance is expensive. The aggregate is.

The result looks wonderfully transparent right up until something fails.

Then the behaviour changes. Someone trims the CC list to the people who can actually act. Updates become specific. Someone is given the job of talking to everyone else.

We already know how to do this. We just reserve it for emergencies.

What incident response gets right

Google’s Site Reliability Engineering model separates incident command, operational work and communications, so the people trying to restore a service are not simultaneously answering every interested observer. A communications role owns stakeholder updates while operations stays focused on mitigation. That separation exists for a practical reason: answering questions and fixing systems compete for the same scarce resource.

The Incident Command System, developed for emergency response and now embedded in FEMA’s training material, works from the same idea. Clear roles, defined communication routes, and a deliberate span of control. Nobody in an ICS structure reports to everybody, because a span that wide stops functioning under pressure.

NIST made a comparable point when it rewrote its incident-response guidance in April 2025. Revision 3 of SP 800-61 — the first substantial update since 2012 — puts the emphasis on establishing organisational response structures before an incident arrives, rather than improvising them during one.

Three different traditions, one shared conclusion. Under pressure, you protect the responders’ attention by deciding in advance who talks to whom.

Nobody runs an incident from a CC list. The everyday version is less dramatic but the same shape. Most delivery organisations already have the components: somewhere decisions get recorded, forums where they get made, and channels where they get announced. What tends to be missing is a deliberate decision about which of those a given piece of information actually belongs in.

Attention is part of operational capacity

There is a useful principle hiding here.

Attention is part of operational capacity.

We are comfortable protecting network capacity, storage capacity and people capacity. We monitor them, forecast them and raise alarms when they run short. We are far less disciplined about protecting attention, despite it being the constraint that determines whether any of the other capacity gets used well. A CC list spends it without ever recording the cost.

I have watched that asymmetry survive four platform shifts now — mainframe to client-server, on-premise to cloud, waterfall to agile, and now AI. Every one of them made it dramatically easier to broadcast information to more people faster. Not one of them improved our discipline about deciding who actually needed it.

A better question before you add to the CC list

Perhaps routine governance should therefore ask a different question.

Not:

Who might reasonably want to know about this?

But:

Who needs this information in order to make a decision or take an action?

The first question has no natural limit. Anyone might reasonably want to know almost anything, which is why it always resolves to adding one more name. The second question has an answer, and usually a short one.

Everyone else can have somewhere reliable to look when they need it. That is the part most organisations skip. You cannot safely narrow a CC list unless the information is genuinely retrievable elsewhere.

Push discipline depends on pull infrastructure.

What this looks like in practice

None of this needs a new framework. It needs a few habits applied consistently:

• Separate the decision record from the decision notification. Write it down somewhere durable, then notify only the people who have to act on it.
• Give status broadcasts an owner rather than an audience. If something genuinely needs wide circulation, someone should be accountable for the quality of that circulation.
• Treat a growing CC list as a signal that decision rights are unclear. People copy defensively when they are unsure who actually decides.
• Review recurring meetings and channels for span of control, not just for cost. A forum with forty attendees is rarely making decisions.
• Make the retrieval path obvious. A team that trusts it can find something will stop asking to be sent everything.

Not all of these will fit every organisation, and regulated environments will keep audit trails that look redundant from the inside. The distinction worth holding onto is between a record that exists for accountability and a notification that exists to interrupt somebody.

Ordinary Tuesdays

The aim is not to keep fewer people informed.

It is to stop spending emergency-grade attention on ordinary Tuesdays.

Sources used

1. Martin J. Eppler and Jeanne Mengis, “The Concept of Information Overload: A Review of Literature from Organization Science, Accounting, Marketing, MIS, and Related Disciplines”, The Information Society, 2004.
2. Miriam Arnold, Mascha Goldschmitt and Thomas Rigotti, “Dealing with information overload: a comprehensive review”, Frontiers in Psychology, 2023.
3. Google, “Managing Incidents”, Site Reliability Engineering.
4. FEMA Emergency Management Institute, ICS Resource Center.
5. NIST, SP 800-61 Rev. 3, Incident Response Recommendations and Considerations for Cybersecurity Risk Management, April 2025.

Related reading

• Stop Owning People. Start Owning Outcomes
• Self-Awareness Is Not Introspection. It Is System Monitoring.
• Speeding Up the Builder Won’t Clear the Jam