On May 7, 2021, DarkSide ransomware shut down the Colonial Pipeline’s computerized systems, and six days later the entire company was still trying to recover. Fuel shortages rippled across the Southeast, average gas prices hit six-year highs, and every news outlet in the country was covering what happened next. But for IT managers, the real story wasn’t in the ransom payment or the recovery timeline. It was in the decisions made in the first few hours, the conversations with executives happening at 2 AM, and the way leadership communicated downward to teams running on fumes.

This is where crisis management separates the mid-level manager from the senior leader everyone wants to work for.

The Entry Point: A Password, No MFA

The attack itself was straightforward in a way that should make every IT manager uncomfortable. Hackers gained access through a single compromised VPN password tied to an unused account. That account had no multifactor authentication. An employee had reused a password that had been exposed in another data breach somewhere, attackers found it on the dark web, and they were in.

What’s instructive here isn’t the breach itself. It’s the conversation that happens afterward in the post-mortem meeting. Your board will ask, “Why didn’t we have MFA on that VPN account?” Your CEO will ask, “How much is this going to cost us?” And your team, sitting in that conference room at midnight, exhausted after seventy-two hours of incident response, will be thinking about whether they still have a job.

As a manager, you need to own the answer to the first question completely. Not because it makes you look good, but because your team needs to see you absorbing the technical failure and translating it into business language that the rest of the organization understands. If you deflect or minimize the severity, you lose credibility when you need it most.

The First Decision: What to Tell Whom and When

Colonial Pipeline made a critical choice very early: they shut down the pipeline themselves rather than risk a cascading failure. That decision moved the crisis from “ransomware attack” to “critical infrastructure emergency” and changed every downstream conversation.

This is where I’ve seen managers make their first major mistake. You have at most two hours before someone outside your team knows something is wrong. The question isn’t whether to escalate; it’s how to frame it when you do.

You’ll need to tell three audiences in this order: your direct leadership, your CEO and board, and your frontline team. Each conversation is different.

To your direct leadership, you need specifics: what we know, what we don’t know, what we’re doing in the next four hours, and what resources we need. This isn’t the place for optimism. If you think this could be serious, say that. If you need emergency budget for forensics or external incident response firms, ask for it in that first conversation. Don’t wait.

To your CEO and board, you’re translating the technical crisis into business impact. Colonial Pipeline didn’t explain SUNBURST or lateral movement or encryption keys. They explained that a critical system was offline, operations were halted, and they had a ransom demand. They explained it clearly and early, and they had a forensics plan. You need to do the same thing, and you need to do it before your CFO hears rumors from someone else.

To your team, you tell them what they need to do and what you’re going to protect them from. You tell them they’re doing the right work, that you understand it’s hard, and that your job is to handle the executive conversations so they can focus on recovery. Then you actually do that. This is the only place where “we’re going to figure this out together” isn’t just motivational speak. It’s your actual job.

Prioritization Under Time Pressure

In the first seventy-two hours of the Colonial Pipeline incident, teams had to decide what to look at first, what to isolate, what to preserve for forensics, and what to sacrifice for recovery speed. Every one of those decisions had downstream consequences.

This is where having a pre-existing incident response plan saves your sanity. Not because the plan will be perfect, but because it gives your team a framework that prevents decision paralysis. You already know who makes what call, what gets logged, who talks to law enforcement, and how you’re going to communicate with customers. When the actual crisis hits, you’re not arguing about process; you’re executing it.

If you don’t have a plan, start one this week. It doesn’t need to be elaborate. It needs to cover: incident classification (is this critical infrastructure, is this data theft, is this ransomware?), escalation criteria (who calls the CEO, who calls law enforcement, who calls forensics vendors?), communication templates (what do we tell customers, what do we tell employees, what goes to the board?), and role clarity (who’s the incident commander, who’s the technical lead, who’s handling external communication?).

The best managers I’ve worked with treat this like fire drills. They practice it quarterly. They run tabletop exercises where they walk through a scenario and see where their communication plan breaks down. Colonial Pipeline didn’t have that luxury during the actual incident, but you can.

Managing Your Team’s Capacity

Here’s what nobody tells you in management training: during a six-day outage of critical infrastructure, your team doesn’t need motivation. They need permission to be exhausted, rotation schedules that actually work, and someone above them absorbing the pressure so it doesn’t cascade down to the people who are actually trying to fix the problem.

I’ve worked in enough incident rooms to know what this looks like. Someone’s running on their fourth coffee in five hours. Someone else is trying to figure out how to explain to their family why they can’t make it home. Your senior engineer is asking whether they should still be on the call or whether they’re at diminishing returns. And the team across the company is watching your incident response channel, wondering if they’re going to be affected next, which creates ambient anxiety that shows up as slow work and mistakes.

You need to manage three things simultaneously. First, you need actual staffing rotation. If this is a six-day incident, assume it’s a forty-eight-hour problem for at least three different shift teams. Burnout on day two is not acceptable. If you’re short people, that becomes an escalation. You pull from other departments. You call in contractors. You involve your leadership in the staffing conversation because they need to understand that running people into the ground now costs you more money in turnover and mistakes later.

Second, you need to be visible and present, but not directive. Your team knows how to do the technical work. What they need from you is the sense that someone is thinking about how the pieces fit together, that you’re aware of what’s happening in adjacent systems, and that you’re protecting them from the organizational chaos that’s definitely happening somewhere above your head.

Third, you need to normalize what burnout and stress look like in that moment and commit to recovery afterward. Weeks after the crisis, people need to be able to take the time off they earned. They need psychological safety to say, “I made a mistake, here’s what happened, here’s how we fix it,” without fear that the crisis will be used against them in performance reviews. Some of the best companies I’ve seen have explicit post-incident recovery policies. Days off, professional development money, clear communication that this was extraordinary and it’s over.

When to Escalate and How

Colonial Pipeline faced the question every IT manager dreads: do we pay the ransom? That’s not a technical decision. That’s a business decision with legal, financial, and operational consequences. Your job is to give your leadership the information they need to make it, and then to execute whatever they decide.

But before you get to the ransom question, there are a dozen smaller escalations. Does this cross a threshold that requires law enforcement notification? Do we need a forensics firm? Do we need to shut down systems that aren’t directly affected? Does this require board notification? Do we contact our cyber insurance carrier?

The pattern I’ve learned is this: escalate early, escalate often, and escalate with specific asks. Not “this is bad.” Rather, “we need a forensics firm in the next six hours. That costs $150K and needs board approval. Here’s what they’ll do and why we need it.” Your leadership will respect that level of clarity, and you’ll get approval faster.

The Longer Lesson: Crisis as Career Accelerant

Here’s something that doesn’t get discussed enough in management circles: how you handle a crisis becomes permanent organizational memory. Years later, people will still talk about how you communicated during the incident, whether you protected your team, and whether you let them down when it mattered.

I’ve seen managers rise to senior director roles on the back of crisis management. Not because they had all the answers, but because they stayed clear-headed, prioritized ruthlessly, communicated honestly, and took care of the people around them.

That matters for your career trajectory. When you’re up for promotion, people remember whether you managed up and down simultaneously, whether you stayed focused on the actual problem instead of playing politics, and whether your team’s retention stayed solid after the crisis. Those things are harder to achieve than having the best technical fix, and they’re worth far more in the long run.

Looking back at [the SolarWinds breach], organizations that managed their teams well during the response saw better retention and faster recovery. The ones that burned people out and pointed fingers dealt with staffing problems for months afterward. The difference wasn’t in the technical skill; it was in the leadership.

The same applies to crisis communication. You’ll be tested on how you talk to your CEO under pressure, how you translate technical chaos into business language, and whether you can make hard calls with incomplete information. These are the soft skills that companies pay directors and VPs to have. If you can do them under the extreme pressure of a six-day outage, you can do them in normal business too.

Build the Systems Now

The Colonial Pipeline attack happened because a critical system was missing a basic control, MFA, that should have been baseline. But it also happened because the organization didn’t have the incident response muscle memory in place when it mattered.

The management lesson is identical: don’t wait for the crisis to build your incident response plan, your communication protocols, your escalation criteria, and your team rotation practices. Build them now when you have space to think clearly. Test them quarterly. Adjust them based on what you learn.

When the crisis comes, you’ll spend your mental energy on actual decisions instead of scrambling to figure out the process. Your team will know what to do and will trust that you have their back. Your leadership will get clear, timely information that lets them make good decisions.

That’s what separates good crisis management from bad. And that’s the skill that moves you from a good manager to a leader people actually want to work for.

Crisis management isn’t glamorous, but in a world where incidents are inevitable, it’s indispensable. Start now.

Further Reading:

See also: the SolarWinds breach changed everything for more on how major security incidents reshape technology teams, and zero-day crisis management: the soft skills that companies pay for on translating technical problems into leadership decisions.

Sources: