Executives as Pilots

Today’s executives have a lot on their hands. Not only does the business environment change more rapidly and dramatically than ever, but the set of available technologies also evolves at a stunning rate. Those technologies are no longer “things that IT does far down in the engine room”; they have become a critical ingredient for the business to achieve the needed agility without sacrificing quality, reliability, or security. How can executives build a bridge between the business strategy and the technical design decisions so that they aren’t distracted but ready to take the helm when needed? Luckily, we can draw quite a bit of inspiration from a group of people who also need to make critical decisions that often depend on the technology that keeps them going: pilots.

Pilots are top executives—they are in charge of getting everyone safely to their destination. They also operate amazingly reliable but staggeringly complex machines. To make critical decisions, they must understand the equipment they are controlling and the environment they are operating in. Although pilots don’t need to do this alone—they rely on support from air traffic control, ground crews, maintenance centers, and weather services—they can never delegate their accountability. Let’s see how executives, especially those on a cloud journey, can learn a thing or two from how pilots train and operate.

Managing Complexity at 35,000 Feet

Pilots have to be prepared to make safety-critical decisions, often on short notice and based on incomplete or contradictory data. Let’s join the cockpit of Air Transat Flight 236 from Toronto to Lisbon halfway into a smooth flight across the Atlantic. The pilots noticed that engine #2 showed lower oil temperature and higher oil pressure than normal. Advised by the maintenance center to monitor the situation, they continued until half an hour later, a fuel imbalance between the left and the right wing caught their attention. They decided to correct it by pumping fuel from the left tank to the right. The next 45 minutes went smoothly, until suddenly engine #2 flamed out due to lack of fuel. Luckily, all twin-engine jets are designed to operate safely on a single engine. Alas, another 10 minutes later, engine #1 also flamed out, leaving the aircraft over the ocean with absolutely no fuel and no running jet engine. This also meant that virtually all hydraulic and electric systems shut down, turning this amazing Airbus 330 aircraft with 293 passengers on board into not much more than a primitive glider. Through a minor miracle and a lot of pilot skill, the aircraft landed safely on a military air base on the Azores 75 miles away.

What happened on that flight has a technical explanation. Jet engines are fast-spinning turbines that are lubricated with oil, just like car engines. The oil is cooled using a heat exchanger device that cools circulating engine oil by also warming up fuel flowing from the wings toward the engines. Flight 236 suffered from a fuel leak near the engine because an improperly installed fuel hose rubbed against the engine cowling and ruptured. The increased fuel flow from the leak caused the heat exchanger to cool the engine oil more than usual, causing low fuel level, lower oil temperature, and increased oil pressure (cooler oil has a higher viscosity).

All the warnings the pilots saw in the cockpit originated from a single problem: the ruptured fuel hose. Had the pilots been aware of the heat exchanger mechanism, they might have reasoned that there’s a connection between the fuel imbalance and the low oil temperature that they observed. They would then have realized that transferring fuel into a leaking tank over the ocean is a very bad idea.

Executives as Pilots

Pilots must make quick decisions in the face of complexity and uncertainty. That’s why they train extensively and follow strict procedures. Although modern IT executives are unlikely to run out of fuel over the Atlantic, they operate in a similar environment that’s highly complex and critical to the business. Let’s take a closer look at how modern IT executives can benefit from operating like pilots:

Be Ready to Take Control

A large portion of any flight takes place in autopilot, which avoids pilot fatigue and distraction by handling routine work such as keeping the aircraft on a prescribed flight path. Pilots specify heading and altitude to the autopilot and the plane pretty much flies itself. However, an autopilot isn’t a substitute for the pilot’s ability to fly and understand the machinery they operate. That’s why pilots train regularly—without autopilot! By flying manually, the pilots understand the dynamics of the technical environment they operate, including how it responds to inputs and how different parts interact or interfere with each other.

IT executives are also used to flying in autopilot. That’s called “management by objectives”: executives fund an IT project and specify the deliverables and timelines. The autopilot in this setup is middle management: they detect small deviations from plan and correct them so that everything progresses smoothly. A decade or two ago, that worked fine because a slow rate of change in both the business environment and available technology made it relatively easy to keep things stable. But today’s turbulent IT environment is very different. Technology innovation takes place at a never-before-seen rate, which, combined with rapid changes in the business environment, keep CIOs and their IT departments on their toes.

IT execs need to be able to take the helm when things get choppy, just like pilots. To do so, they need to understand what’s going on in the IT “engine room”—where technical systems operate and critical decisions are made. Understanding the dependencies between systems and technologies teaches IT execs how to react to unusual readings from the instruments, just like pilots do. Is that “red light” a simple warning or a serious issue? Pilots can’t just “wait and see.” The same is true for IT executives in today’s fast-moving environment.

Middle management is IT’s autopilot. It takes care of routine adjustments so executives can focus on critical tasks. But an autopilot can also mask problems. Executives therefore must be ready to take the helm when things get choppy.

Autopilots, as useful as they are, also mask potentially critical problems. Because they’ll automatically compensate for deviations, an issue might go undetected until it becomes serious. So, it’s important for pilots and IT execs alike to not blindly rely on autopilots. That’s one reason why at Amazon, we adopted “dive deep” as one of our 16 leadership principles. Amazon executives are expected to dive into the details of what they are managing—without autopilot.

Walk Around the Engine Room

Before any pilot gets on a plane, they do a walk-around: they are down on the tarmac, looking at tires, sensors, and engine intakes. They want to make sure everything is in good working order. They don’t blindly trust their dials and gauges. Even though mechanics maintain the equipment meticulously, it’s important for the pilots to not be detached from the machines they operate. After all, they carry end-to-end responsibility—you can’t say “that’s not my department” when you’re low on fuel over the Atlantic. Walk-arounds also underline that walking on the tarmac and kicking the tires isn’t beneath a pilot, despite the prestigious job title.

Likewise, modern IT executives need to understand the machinery they control. This doesn’t mean that they need to read or even write code, but they should understand the key components, the ramifications of choosing one solution over another, and critical interdependencies. What technical infrastructure is needed to enable modern ways of working, like DevOps or Agile development? Can a platform strategy drive harmonization while also boosting innovation? What are the key ingredients to making such a strategy successful, both technically and organizationally? Top executives who have clear answers to such questions in their minds will not only make better decisions but also become stronger sponsors for related IT initiatives.

Modern IT executives need to visit the engine room to build an understanding of the machinery they control.

“Management by wandering around” was a common phrase in the ’70s and ’80s. The increasing complexity of today’s IT might scare executives away from visiting the engine room, but it’s actually more important than ever: those engines determine whether your business will fly.

Ask “Why” a Lot!

In complex systems, it’s difficult to understand how pieces are interconnected. When everything is working fine, one might never know about a fuel-oil heat exchanger. Ironically, when something unusual happens—a fuel leak in the worst case—we learn about how the engine room behaves. But only if we ask enough questions!

Air safety boards do ask a lot of questions to get to the root cause of a problem. They don’t stop at the technical issues; they also look at procedures, management practices, and regulatory guidelines. Causes for IT project delays and failures can be similarly diverse. Executives should therefore take part in retrospectives and ask a lot of “why” questions. The “five whys” method was pioneered by Toyota to get to the bottom of a problem by repeatedly asking why something happened . The point here isn’t to identify the “guilty party” but to solve the true root cause of a problem, not merely curing symptoms.

Everything going according to plan might be most comfortable state. But the unexpected presents most opportunities for learning – if you ask enough questions.

So, the next time something doesn’t go to plan, jumping to a quick solution might forgo one of the most valuable learning opportunities. A problem isn’t solved when it magically disappears but when the root cause is understood and rectified. That can only happen when you ask a lot of “whys” first.

Use Models to Combat Complexity

Pilots and even mechanics can’t take the entire airplane apart to understand how it works. Instead, they rely on handbooks, schematics, and engineering drawings. These documents are abstract models: they highlight the important parts, especially what component is connected to which other ones. They also omit a lot of detail, like exactly how long a wire or a fuel hose is, so they can reduce complexity without losing important aspects.

Architecture models are equally important tools for executives that act like pilots. Such models provide meaningful abstractions that eliminate noise and highlight important choices and their trade-offs. That’s the only way to conquer the inevitable technical complexity in today’s IT. Without such models, managing complexity can feel like playing Whack-a-mole: you solve one problem just for another one to pop up, seemingly randomly—just like when the pilots balanced out the fuel tanks only to run out of fuel less than an hour later. Because problems in complex systems often arise between the parts, like a fuel line or a faulty software integration, it’s important to use models that depict the connections between the pieces.

Without architecture models, solving IT problems will feel like playing Whack-a-mole.

Architecture teams are a great source for such models. That’s why modern architecture teams should be closely connected to IT executives. They can create clarity and help make better and more transparent decisions. Such architects connect decision-makers and the IT engine room, a concept I refer to as “riding the architect elevator.”

Focus on Grammar, Not Vocabulary

Excessive jargon keeps many IT executives out of the engine room. Connecting to folks in the engine room can feel like having to speak a foreign language. “We favor a declarative IaC flow but wrapped the API in an OO language to aid frequent refactoring” is what you might hear. You might be tempted to ignore those details until the next message is “a typo in our shared IaC library took our production system down because it shut down all servers.” At that point, taking the helm will be difficult, and blaming the intern isn’t going to fly.

To make matters worse, IT vocabulary changes all the time: is it DevOps, DevSecOps, Post-DevOps, NewOps, or NoOps? Is it all more or less the same or should we call it SRE (site reliability engineering)? That debate alone could easily last hours.

Luckily, it’s not necessary to memorize a giant dictionary of IT terms. To become proficient in a new language, you need to master two elements: the vocabulary, which provides the set of available words, and the grammar, which defines how these words can be combined to express something meaningful. As an exec, even one that acts as a pilot, it’s almost impossible to master today’s IT vocabulary: it changes too frequently, and a widely accepted dictionary doesn’t exist.

Keeping up with today’s IT vocabulary is difficult. Therefore, focus on the grammar to understand relationships.

Execs who act like pilots should therefore focus on the grammar of IT: What combinations of words make sense? Can I establish DevOps practices before moving to the cloud? Does using serverless platforms affect how I implement DevOps? Should the business take part in such a transition? Those questions reveal the grammar of the IT language and the relevant connections.

Welcome Aboard

When we board an aircraft—an experience many of us have been dearly missing—as passengers, we don’t need to think about all the complexities of the machinery ferrying us to our destination. However, executives aren’t first class passengers; they’re sitting in the cockpit!