The 2 A.M. Fire Drill I Could Have Prevented

If you’ve managed a global team, you’ve probably woken up to a fire drill. Something happened overnight, messages are waiting, and your morning priorities have already changed.

This one caught me before I went to bed.

And looking back, I had contributed to the conditions that caused it.

The meeting invitation that got my attention

My personal and work computers sit side by side. I was on my personal computer, about to call it a night, when I glanced over at my work monitor and noticed a meeting invitation for the following morning.

I took a closer look at the attendee list.

Legal leadership. Marketing leadership. Digital operations leadership. My bosses. External privacy consultants.

That’s quite a group for a meeting I wasn’t expecting.

The agenda concerned a privacy and consent program I was managing. The reported issue: it wasn’t working.

That surprised me because I had just finished testing it the day before. I’d checked the consent setup with Fred Pike, Digital Consultant from Northwoods, through Google Tag Manager, Google consent settings, and browser testing across the regional configurations we used for GDPR, CCPA, and the rest of the world.

What had I missed?

As I reviewed the concern, I realized there was a difference between how the person testing the experience understood the consent methodology and how the program was configured to work.

That person worked in IT security. They evaluated the experience based on their understanding of the requirements. I was evaluating it against the regional consent models we had implemented.

We didn’t have a shared basis for deciding whether the behavior was correct.

But before I could confidently address that in a room full of leadership, I needed to verify the configuration again.

Back through the testing, twice

I opened my VPN and started working through the regional experiences.

Location mattered because the consent behavior depended on the visitor’s region. The VPN helped me reproduce those experiences so I could check each configuration.

I used browser tools and privacy testing extensions to inspect what was happening. I worked through the consent choices, checked the resulting behavior, and compared it with what I expected for each regional model.

Then I did it again.

By the time I finished, it was 2 a.m.

Everything I checked was working as expected. I was tired, but I was ready for the call.

Getting everyone to look at the same evidence

I knew how I wanted to approach the meeting.

After the introductions and good mornings, I would take the first opening and ask to demonstrate how the consent models worked.

I wanted everyone to see the actual behavior early in the conversation. Otherwise, we risked spending the meeting discussing a reported failure without a common understanding of what we were evaluating.

The next morning, that’s what I did.

After the greetings, I asked the chef legal officer if I could walk everyone through the configuration and the testing.

They agreed.

I demonstrated the regional experiences, explained the expected behavior, and showed what I had verified.

Then there was silence.

Crickets.

The reported problem was a false alarm.

That resolved the immediate concern. It also left me with a more useful question: what could I have done earlier to prevent the escalation?

The part I owned

It would have been easy to leave that meeting thinking someone else had misunderstood the system.

But I was managing the program. Creating a shared understanding of how to evaluate it was part of my responsibility.

I had focused on the configuration and testing. I hadn’t established the governance that would help the different functions understand the consent models, their responsibilities, and the process for raising concerns.

In this program, I was covering both privacy coordination and analytics responsibilities. That gave me visibility into how consent choices affected measurement, but it didn’t automatically give everyone else the same visibility.

I hadn’t established a privacy and consent council. I also hadn’t documented responsibilities through a RACI or clarified decision authority through a decision rights matrix.

The technical explanation existed. The shared operating model needed more work.

What I would put in place earlier

During my postmortem, I identified several things I would establish earlier in a similar program.

A privacy and consent council

I discussed this lesson in my Northwoods Digital Marketing User Group presentation: privacy and consent work needs representation from the functions that interpret, implement, test, and depend on it.

Depending on the organization, that includes:

• Legal.

• Engineering.

• IT security.

• Privacy, where there is a dedicated function.

• Marketing operations.

• Analytics.

• The program or project manager coordinating the work.

The council needs a practical purpose: establish shared requirements, review meaningful changes, resolve questions, and give concerns a clear path to the right people.

A council alone wouldn’t guarantee that an escalation never happened. It would, however, create a place to surface differences in understanding before they reached an executive meeting.

A RACI that reflects the work

A RACI identifies who is Responsible, Accountable, Consulted, and Informed.

For a consent program, I would apply it to specific activities: interpreting requirements, configuring the platform, validating regional behavior, approving changes, and investigating reported issues.

That level of detail matters. Knowing that security is “involved” tells you much less than knowing who validates a particular requirement and who needs to review the result.

Clear decision rights

Responsibilities and decision authority are related, but they aren’t interchangeable.

A decision rights matrix should clarify who can approve a change to consent behavior, who resolves a disagreement about requirements, and who authorizes an escalation.

Without that clarity, a concern can move quickly through the organization while the people involved are still working from different assumptions.

Shared acceptance criteria and testing guidance

This was particularly relevant to my fire drill.

Before asking someone to test, I would make sure we agreed on the expected behavior for each regional configuration, the conditions needed to reproduce it, and the evidence required to report a failure.

A short walkthrough could have made the testing much more useful. It also could have given the tester a straightforward way to ask whether an unexpected result was a defect or an intended part of the model.

The lesson I carried into DMUG

In my DMUG discussion, I described the goal as “trusted observability over maximum observability.”

That principle depends on people understanding what the measurement environment is supposed to do, including how consent choices affect it.

Legal, security, engineering, marketing operations, and analytics bring different responsibilities to that conversation. A program manager helps turn those perspectives into requirements, decisions, and a process people can follow.

My late-night testing gave me the evidence I needed for the meeting. Earlier alignment would have given the organization a better way to evaluate the concern in the first place.

That’s the lesson I took from the fire drill.

When I review a program now, I want to know whether the people around it can explain what correct behavior looks like, who makes the decisions, and how to raise an issue.

Those questions deserve time on the project plan.

Preferably before 2 a.m.