Blog

I learned to spot the warning signs too late.

It was during a remote disaster recovery test that I was responsible for; the type of test where you have a set period of time to recover your core systems using a selection of backup tapes. In this case we needed to bring all the key business systems online to the point where remote users could log in and complete a list of tasks. Within 24 hours.

We had a scoring system to track how well we did during the exercise, and it was possible to get “partial credit” if certain parts of the system did not recover. But there was one component that nearly everything else depended on; the database. On the plus side, I was the DBA and I had stress tested my backup/recover process until I dreamed about it. Once the DG/UX systems had been recovered and my data restored, I would be able to get the database up within 3 hours.

The test started and our Unix Lead mounted the recovery tapes for the systems and began the process of restoring the operating system. It went well at first; the systems booted and started recovering from the tapes and within an hour we had the OS up and running. The database binaries and configurations restored without issues.

It was during the data recovery that things started to go wrong. Against all advice our Unix Lead had decided to use a new backup system he had recently purchased. The tried and true version was a simple set of DLT tapes that we read one by one. That’s how everything else was recovered. Not the data; for that he had decided that he was going to use a five tape RAID-5 dataset on the new five DLT enclosure that he had just put into service within the last few months.

The lead had been through dozens of similar tests. He knew the systems, knew the risks, and knew the procedures. But somewhere between his experience and reality something went wrong.

When the monitoring started showing anomalies, he dismissed them. “I’ve seen this before, it’s fine.” When our junior engineer raised concerns about the rising error rates, he cut them off. “We don’t have time for that right now.” Even when everyone else realized that this was not going to work, he spent precious minutes trying to prove his original approach could still work instead of pivoting to the fallback we had planned.

The database never did come up, and we failed that DR test.

Later, reading through the postmortem, I couldn’t shake the feeling that I’d seen this pattern before, not just in technology but in other high pressure situations. That’s when I discovered that aviation psychology had already mapped out exactly what had gone wrong. They call them hazardous attitudes, and they’re just as dangerous in a datacenter as they are at thirty thousand feet.

The Problem with Confidence

Here’s the paradox: you can’t be an effective leader without confidence. Nobody wants to follow someone who second-guesses every decision or projects uncertainty in a crisis. Your team needs to believe you know what you’re doing, especially when everything is on fire.

But that same confidence, when it crosses certain lines, becomes the thing that creates the crisis.

Aviation psychologists have identified five specific attitudes that consistently lead to disasters. What makes them hazardous isn’t that they’re always wrong, because they are sometimes right. The hazard comes from them overriding the systematic decision-making that keeps complex systems safe.

Each attitude represents a different way that human psychology can hijack good judgment, and every single one shows up regularly in technology leadership.

Anti-Authority: “The Rules Don’t Apply to Me”

The anti-authority attitude comes in two flavors. The first is straightforward rebellion. This is the classic example of the leader who openly resents being told what to do and treats established procedures as suggestions for lesser mortals. The second is more subtle but potentially more dangerous. This is a leader who rationalizes that exceptional circumstances justify exceptional measures.

I’ve watched this play out in teams more times than I can count. A senior engineer decides that following the change management process is unnecessary because “I’ve done this hundreds of times before.” A manager skips the required security review because “we’re on a tight deadline.” A director bypasses the architecture approval process because “we need to move fast.” For me, it was the pressure of having an entire steel mill hard down after a power loss — a situation where I knew the written recovery procedure and ignored it anyway. Things went horribly wrong.

The justifications always sound reasonable in the moment. Experience does matter. Deadlines are real. Speed has value. But rules in complex systems exist because someone before you learned something expensive. When you decide the rules don’t apply to you, you’re really deciding that you don’t need to learn from other people’s failures; only your own.

The antidote that aviation training provides is simple but powerful: “Follow the rules. They are usually right.” Not because rules are sacred, but because they represent collective learning. If you think a rule is wrong, the time to challenge it is not mid-flight, not in the middle of an incident, not when you’re under pressure to deliver. Challenge it in calm conditions, with data, with the people who will be affected by the change.

Impulsivity: “Do It Quickly”

Time pressure makes people stupid. Really stupid.

That’s not an insult, it’s neuroscience. When you’re rushing, your brain shifts from systematic thinking to pattern matching. You go with your first instinct instead of evaluating alternatives. You skip steps because they feel slow. You commit to a course of action before you’ve gathered enough information to know if it’s the right one.

The impulsivity hazard shows up most clearly during incidents. Something breaks, alarms are firing, people are asking for updates, and there’s enormous pressure to do something. The first thing that comes to mind feels like action, feels like leadership, feels like you’re solving the problem. But the first thing that comes to mind is often wrong.

I learned this lesson from a mentor who had an infuriating habit during incidents. Whenever someone proposed an immediate action, he would pause, take a breath, and say “Not so fast. Think first.” It drove younger me crazy. The site was down! Customers were affected! We needed to move!

Current me now preaches the same thing I once hated. Those five seconds of pause consistently prevented us from making things worse. The antidote to impulsivity isn’t slowness; it’s deliberateness. Take a breath. Gather information. Consider alternatives. A correct decision beats a quick decision every single time, even when the quick decision feels urgent.

This connects directly to what I’ve written about in my series on ignorance in the workplace. Sometimes the most powerful thing you can do is deliberately slow down to avoid ignorant action. Not ignorance of facts, but ignorance of consequences.

Invulnerability: “It Won’t Happen to Me”

Every pilot needs some level of invulnerability to function. If you truly believed that every flight could end in disaster, you’d never get in the cockpit. The same is true for operations engineers. If you genuinely internalized that many of the tasks you performed could cause a critical outage, you’d never do anything.

But that necessary confidence becomes dangerous when it crosses into genuine belief that bad outcomes happen to other people because those people are careless or incompetent. When you start thinking “accidents happen to them because they don’t know what they’re doing, but I know what I’m doing,” you’ve entered the invulnerability trap.

This hazard often travels with others. The invulnerable leader is the one who skips safety checks (anti-authority) because disasters won’t happen to them. They rush through decisions (impulsivity) because they’re confident in their pattern recognition. They take unnecessary risks (macho) because they believe they’re good enough to pull it off.

I’ve seen this most clearly in how experienced engineers interact with production systems. The new engineer follows the runbook exactly, double-checks every command, and verifies every result. The veteran engineer has run these commands a thousand times and starts skipping steps. Until the day they skip the wrong step. For me, skipping the wrong step meant offlining a production database for two hours while we restored from backup.

The antidote is uncomfortable: “It could happen to me.” Not as a source of anxiety, but as a source of rigor. You are not special. Your experience does not make you immune to mistakes. The disaster that happened to that other team last month could happen to your team tomorrow, regardless of how good you are. Accept that, and you’ll maintain the practices that prevent it.

Macho: “Let Me Show You What I Can Do”

The macho attitude isn’t about gender; it affects everyone who works in competitive environments where proving competence matters. It shows up whenever someone takes unnecessary risks to demonstrate skill, whenever someone refuses to ask for help because they should be able to handle it alone, whenever someone pushes past reasonable limits to show they’re tougher than everyone else.

In technology, this often manifests as engineering heroics. The developer who insists on fixing the critical bug solo at 2 AM instead of waking up the team. The ops engineer who manually manages the infrastructure incident instead of following the documented recovery procedure. The architect who commits to an impossible timeline to prove they can deliver what others can’t.

What makes this hazardous is that sometimes it works. The solo developer does fix the bug. The ops engineer does recover the system. The architect does deliver on time. And every time it works, it reinforces the belief that taking those risks was the right call.

But you don’t see the times when it fails, because those people don’t brag about their failures. You don’t hear about the developer who made the outage worse, or the ops engineer who crashed the system trying to be a hero, or the architect whose team burned out delivering the impossible timeline.

There’s a physiological aspect to this too. When you’re running on adrenaline, whether from caffeine, lack of sleep, or the high of fighting an incident, your brain produces an unfounded sense of well-being. Everything feels manageable. You feel capable of anything. This is literally your judgment being impaired by your body chemistry. The 24 hour DR test I started this blog post with was just one of a series of tests we repeated every 6 months. On a later test I wasted three hours for the entire team by breaking an external disk array because I was going to show everyone that we didn’t need to take the 20 minutes to do it right.

The antidote: “Taking chances is foolish.” Not taking calculated risks, which are part of the job, but unnecessary chances driven by ego or competition. The risks you take should be in service of the mission, not in service of proving something about yourself.

Resignation: “What’s the Use?”

The resignation attitude is the most insidious because it looks like the opposite of the others. Where anti-authority is defiant and macho is aggressive, resignation is passive. But passivity in a crisis is still dangerous.

Resignation shows up when someone decides the situation is hopeless and stops trying to improve it. When an engineer sees a failing system and thinks “there’s nothing I can do about this.” When a team lead faces impossible demands and thinks “we’re going to fail anyway.” When an individual contributor receives harsh criticism and thinks “I’m not good enough for this work.”

I’ve watched this kill teams slowly. It starts with someone feeling overwhelmed and helpless. Instead of asking for support or pushing back on unrealistic expectations, they accept that failure is inevitable. They stop proposing solutions. They stop raising concerns. They wait for someone else to fix things, or for the inevitable collapse to prove they were right to give up.

The particularly toxic form of this attitude appears in organizations with aggressive, metrics-obsessed leadership (what I’ve encountered in the past and explored in depth in my writing on toxic leadership patterns). When people face impossible metrics, arbitrary blame, and constant criticism, resignation becomes a survival strategy. “What’s the use of pushing back? What’s the use of suggesting improvements? Nothing I do matters anyway.”

The antidote is “I’m not helpless. I can make a difference.” Even in the worst situations, even with the worst leaders, even facing the most impossible deadlines you still have agency. You can propose solutions. You can raise concerns. You can choose how to respond, even if the response is to request a transfer or find a new job. Resignation is giving away your agency before you’ve actually exhausted your options.

The Self-Assessment Framework

Aviation gives pilots a practical tool for checking their own fitness to fly: the IM SAFE checklist. It’s a structured way to assess whether you’re in a good state to make high-stakes decisions. The same framework applies to technology leadership.

Illness: Are you physically well enough to function? Even a minor cold affects your cognition more than you realize. If you’re sick enough to impact your thinking, you’re sick enough to delegate decisions to someone else.

Medication: Are you taking anything that affects your judgment? This includes prescription medication, but also caffeine, alcohol, recreational drugs, even over-the-counter cold medicine. If it changes how you feel, it’s changing how you think.

Stress: Are you carrying stress that’s affecting your decisions? Stress from the current situation is expected, but stress from your personal life, from previous incidents, from ongoing organizational dysfunction. All of that accumulates and degrades your judgment.

Alcohol: Are you under the influence? The eight-hour rule applies: don’t make critical technical decisions within eight hours of drinking. And if you’re still feeling effects beyond that window, extend the restriction.

Fatigue: Are you well-rested enough to think clearly? Not “can you function,” but “can you function at the level required for this decision.” The oncall engineer at 3 AM needs to be honest about whether they can handle the incident or need to escalate.

Emotion: Are you emotionally stable enough for good judgment? Anger, fear, grief, and anxiety are all human and reasonable, but they also affect decision-making. If you’re in an emotional state that might compromise your judgment, acknowledge it and get support.

The value of this checklist isn’t that it prevents you from working when you’re not at 100%. Nobody is ever at 100%. The value is in building self-awareness about your current state so you can compensate for it: being more deliberate, double-checking your thinking, involving other people in decisions, or recognizing when you need to step back entirely.

Recognizing the Patterns

The most important insight from aviation psychology is this: these hazardous attitudes aren’t character flaws. They’re normal human responses to stress, time pressure, and complex situations. Every single one of us is vulnerable to them.

What separates good decision-makers from poor ones isn’t immunity to these attitudes, it’s recognition. Can you notice when you’re being impulsive? Can you catch yourself rationalizing why the rules don’t apply this time? Can you feel the macho attitude pushing you toward unnecessary risk?

This is where systematic decision-making frameworks become critical. When you use structured approaches like the PIOSEE framework (more on this in an upcoming post), you create checkpoints that force you to examine your thinking. The framework itself becomes the antidote, because it requires you to slow down (countering impulsivity), follow established processes (countering anti-authority), acknowledge risks (countering invulnerability), justify your choices (countering macho), and actively problem-solve (countering resignation).

The hazardous attitudes are shortcuts. They’re your brain’s attempt to simplify complex decisions by falling back on instinct, emotion, or ego. The antidotes are all variations of the same thing: slow down and think systematically.

Building Better Systems

Individual awareness helps, but the real power comes from building systems that catch these attitudes before they cause damage. That means:

Creating cultures where questioning is encouraged. When someone raises a concern, even if they’re junior, even if they’re probably wrong, the response should be “let’s check that” not “I’ve got this handled.” Our junior engineer was right to flag the rising error rates during that DR test. The failure wasn’t their inability to convince the Unix Lead to stop; it was a system that let his dismissal be the final word instead of automatically triggering a second look.

Establishing processes that can’t be easily bypassed. Change management, security reviews, architectural approvals should be gates, not suggestions. If someone needs to circumvent them, that should require explicit approval and documentation, not just a judgment call in the moment.

Normalizing self-assessment. Teams that regularly discuss IM SAFE considerations build cultures where it’s acceptable to say “I’m not in a good state to handle this right now.” That’s professionalism, not weakness.

Building in deliberate pauses. Before any major change, before committing to any significant decision, build in explicit checkpoints where someone asks “have we thought this through?” Those pauses feel slow in the moment but prevent disasters.

The Meta-Pattern

Across all five hazardous attitudes, one pattern repeats: they’re all ways of avoiding the discomfort of uncertainty.

Anti-authority avoids the uncertainty of whether the rules actually apply. Impulsivity avoids the uncertainty of taking time to gather information. Invulnerability avoids the uncertainty of whether you’re at risk. Macho avoids the uncertainty of whether you need help. Resignation avoids the uncertainty of whether your actions matter.

But uncertainty is inherent to complex systems. You can’t eliminate it. You can only choose whether to acknowledge it and work with it, or pretend it doesn’t exist until it manifests as a disaster.

The most effective leaders I’ve worked with aren’t the ones who project the most confidence. They’re the ones who are comfortable with uncertainty, who can say “I don’t know” without losing authority, who can admit mistakes without losing respect, who can follow established procedures without feeling like they’re admitting weakness.

They’ve learned what aviation has known for decades: confidence is necessary, but humility keeps you alive.

Related Reading

• Decision-Making: PIOSEE - The systematic framework that operationalizes the antidotes to these attitudes
• Ignorance Series: The Luxury of Ignorance - Why slowing down to see consequences counters impulsivity and invulnerability
• Toxic Leadership: The Metrics Game - How metrics-obsessed leadership turns resignation into a survival strategy
• Communication: Breaking Down Silos - How Crew Resource Management counters these same hazards from the team side