Feb 232017
Image source: AOPA Flight Safety

My friend Scott Barnes tagged me about this article on factors affecting pilots’ decisions to land.

Scott’s share of this article reminds me of one more way in which my training as a Commercial Pilot and Flight Instructor influences my business consulting practices.

In aviation, we don’t think of an aborted landing as merely a landing that we “failed.” The aborted landing is actually a maneuver with procedures and performance standards. We train for it like any maneuver.

The Go-Around

Go-Around procedures. Source:

Go-Around Procedure (image:

Sometimes a landing shouldn’t happen. The entire flight path to the runway was fraught, so those final 100 feet to wheels-down are going to be messy. Another aircraft is on the runway you were just cleared to land on. You got distracted and got “behind the airplane” (you aren’t thinking ahead, and have become more of a passenger than a pilot.) The landing was going great, but the wind gusts are worse right now than they were sixty seconds ago… and as you fight the gusts, you are running out of runway.

As a student pilot, I had my share of unpleasant landings, including one which came close to scraping the tail of the aircraft on the runway tarmac.

My instructor — after examining the tail of the aircraft and breathing a sigh of relief to find it unharmed — informed me that any of these is a totally valid reason to skip the landing and go around.  In fact, I should plan every landing as if it were going to be a go-around.

“Get back up safe in the sky, re-plan, and come around and try again. Landings don’t cause crashes; pilots forcing themselves into bad landings cause crashes.”

This was eye-opening advice. How cool: as Pilot-In-Command, I have choices! I’m NOT doomed to follow my plan down into a fiery impact with the ground!

Warning Signs

But how often, in business, do we “force ourselves into bad landings?” The article lists six factors for why pilots do so, and they should ring a bell for us in business.

I’ve taken the liberty of translating the article’s six factors into typical sound-bites that represent the thinking behind these factors:

  1. Plan Continuation Error — “We need to stick to the plan. Why else did we make one?” 
  2. Sunk Cost Effect“We’ve invested a lot of time/money in this course of action, we need to see some return.”
  3. Cognitive Dissonance“The alternative you suggest sounds too complicated. Our current course of action is simplest.”
  4. Complacency“We’ve done dozens of deployments like this, I don’t see why you’re so pessimistic.”
  5. Hindsight Bias“Those warning signs you talk about aren’t warning signs; they are they only thing that could have happened. Stop worrying about what DID happen and focus on what SHOULD happen.”
  6. Bounded Rationality/’Satisficing’“I’m not rationalizing risk away; I just don’t think a few annoyed theoretical customers is as risky as delaying our product release by a month.”

How often have you heard statements like these, prior to the business equivalent of a crash into the ground?

Image source: AOPA Flight Safety

Image source: AOPA

Crashes in business can take longer than in aviation, but both are awful to watch.  I once saw one go on for 4 months. There were dozens of “passengers” (senior employees) involved in this particular venture, but despite all evidence, the “pilot” (C-level leader) continued to make statements that sounded a lot like those above.

Right up until the point that the company’s core business and customers were threatened.

It was the business equivalent of feeling the aircraft tail scrape the runway.

Plan the Go-Around — Detect When to Execute

I’m not trying to paralyze you with crash stories and accident reports. I’m hoping to show you that you have options besides “do or die.”

But only if you plan to have options. If there are warning signs, don’t simply hope that everything will be okay. Don’t shove the responsibility for a successful landing off onto your people. Question. Test your assumptions.

Here are some antidotes to the above risky soundbites:

  1. Plan for AlternativesWhat “go-around” procedures do we have if a risk manifests? Are we ready to execute them?
  2. Think Incremental ROIWe’ve invested a lot of time/money; how do we ensure that we get at least partial ROI no matter what?
  3. Be SkepticalWe’ve done dozens of successful deployments like this. But what’s different about this one?  
  4. View Risks as Discovered Work — I hear some concerns. Sounds like we’ve discovered some new risks. What work do we have to do to minimize these risks? Is this work in the new plan?
  5. Set Triggering ConditionsLooking ahead, under what circumstances might we need to change our plans? How can we tell if those conditions occur?
  6. Be Open to Peer ReviewI don’t think the risk of failure is as great as the risk of delay. But maybe I’m biased. So I’ve asked people outside my department for their assessment.

In aviation, we say:

“Plan every landing as a go-around, plan every [instrument weather] approach as a missed approach.”

Hope is not a strategy. “Go around triggers” for a project at risk from outside commitments.

In business, this means that while yes, we should “think positive” and “plan to ship it,” successfully delivering means that we also detect when that plan is no longer feasible, and then re-plan using newly discovered information.

Agile Development methods bake this re-planning into their process. Unfortunately too often the surrounding business processes do not. Too often, the people leading those processes view re-planning as a sign of failure.

So watch out for those warning sound bites. And stop thinking of deviation from the plan as failure. Start thinking of it as a procedure to be practiced and performed just like delivery.

As we say about go-arounds in aviation:

“Better to explain why you DID it, than for others to find out after the crash why you DIDN’T.”

 Posted by at 12:50 pm
Sep 222016

In the previous section, we explored how technology can potentially free up capability. On a high-tech destroyer or in cyber-security, tech can “raise the game” of people in the enterprise.

Technology offers tireless, rapid, low-variance behavior. That doesn’t necessarily mean more intelligent behavior.

Lesson 2. Automation Is Necessary, But Not Sufficient

green-bar-paperOne of my first jobs was loading magnetic tapes onto a backup machine and physically delivering printed reports around the office. (Yes, green-bar paper!) Occasionally I’d mis-load a tape or deliver a report to the wrong place and oh boy, would the phones would start ringing. Cool story, bro, but now we’re better than that, right? Today we’d consider this an egregious waste of human talent.

Yet we think nothing of employees spending hours fighting Excel. Sorting, querying, transposing. We haven’t raised the game. We’ve just made it harder to win. Technology gives you more of what you already have, faster.

“S.S.D.D.” used to mean “Same Sh*t, Different Day” but now it means “Same Sheet, Different Data.”

Image: Walt Disney Co.

Mickey’s automation problems in Fantasia (Walt Disney Co.)

If you add automation without engaging your people, you accelerate whatever already exists in your org. And you may accelerate the bad faster than the good.

If your enterprise (starship, sailing ship, or company) is full of reporting, bureaucracy, fear, or butt-covering, adding a “technical solution” may just amplify that.

I’ve seen far too many orgs drowning in data, yet thirsting for insight. Where people have become servants of the systems, not the other way around. And the mission is forgotten.

The crew of the Zumwalt avoided this by designing around the human side of the equation. Every new shipboard computer system was prototyped and adjusted based on feedback from the crew. Then they trained hands-on, side-by-side with the engineers to be ready to sail the new space-age destroyer.

Electrician’s Mate 1st Class Donald Goldsberry and Electrician's Mate 2nd Class Radarwin Adams of the pre-commissioning crew of the future USS Zumwalt (DDG 1000) train to use the common display system console and engineering control system screen navigation at Naval Surface Warfare Center Carderock Division - Ship Systems Engineering Station (NSWCCD-SSES) in Philadelphia (U.S. Navy photo by Public Affairs Specialist Joseph Battista/Released).

Zumwalt crew members cross-train shared tasks on a shared console (U.S. Navy)

So pay close attention when you add technology. Consciously prioritize the human issues above the technological ones. Use technology to free your thought-workers for thinking. Be ever alert to the failure mode of people “feeding the machines.”

As a leader, you need to enable your teams to move from what to why.  You need to enable them to make the same shift that my friend’s “network operations security” team made when they graduated to “risk management.”

Set clear strategy, manage the work, and let people self-organize around it. Or your organization’s relationship with technology might look a bit like Mickey’s above.

In Lesson 3: Management Overhead, we’ll look at how raising the game for your people re-defines the value of “management.”

All articles in this series:

  1. Raise the Game — Automation is Required
  2. “Same Sheet, Different Data” — Tech is Not Enough (this page)
  3. Management Overhead — Reduce the Waste
  4. Team Skills Needed — Diversity, Communication, Mutual Support
 Posted by at 5:17 pm
Sep 212016

In “Same Sheet, Different Data“, we saw how subordinating human intelligence to technology is a failure to “raise the game.” The story of the Zumwalt highlights another opportunity of work in the 21st century: raising the game means that much of traditional management effort is waste.

Lesson 3. Reduce the Wasted Effort of Traditional Management


An all-too familiar problem in many corporations. (Reddit)

Technology on the Zumwalt — and in the workplace — has shifted jobs away from routine tasks and toward those requiring technical expertise. Cross-training and crew communication have made layers of top-down supervision redundant.

Yet in the majority of organizations that aren’t a stealth destroyer, these redundant managerial structures remain in place. A recent HBR article estimates the current waste — that’s no value added — of management overhead in the U.S. at 17% of GDP. Three. Trillion. Dollars. Every year.

Roger Perlmutter has been at the helm of R&D at pharmaceutical giant Merck since 2013. One of his early tactics was to simply eliminate the redundant layers:

The problem, Perlmutter says, was that the labs had become tied up in bureaucracy, with too many people reporting to other people reporting to other people, all of them asking each other for permission slips. “Everybody stayed in their swim lanes. I’m actually interested in people who want to own the pool.”

Forget the pool, Captain Kirk and his crew are owning the ocean. Kirk’s job as a leader is to “create a sense of mission and teamwork.”  This enables his team to be responsible. To “not just accept delivery of the ship, but to take delivery of the ship.” And as we saw in Lesson 1, they use their game-raising automation to directly control the gunnery, communications, and steering of the ship.

Capt. James A. Kirk (U.S. Navy)

Capt. James A. Kirk (U.S. Navy)

The result? Despite being a much larger vessel, Captain Kirk’s modern destroyer has a crew complement that is the smallest since those of the 1930’s.

Maybe some organizations can get away with the extra bureaucracy. Maybe it’s okay for their service delivery to be thinly smeared across multiple managers/directors. As embarrassing as it might be to admit, perhaps their missions just aren’t as critical as that of Captain Kirk’s crew.

But just think what your enterprise could be like you were able to create that sense of mission and teamwork.  If everyone who worked there directly added value, because you aren’t creating waste with adult baby-sitters.

In our final lesson (for now), we’ll look at the skills that differentiate the superstars in the 21st century workforce.


All articles in this series:

  1. “Raise the Game” — Automation is Required
  2. “Same Sheet, Different Data” — Tech Is Not Enough
  3. Management Overhead — Reduce the Waste (this page)
  4. Team Skills Needed — Diversity, Communication, Mutual Support
 Posted by at 5:17 pm
Sep 202016

Leaders of 21st-century enterprises can learn a few things from Captain James A. Kirk’s brand-new stealth destroyer and her crew. Consider the similarities. Technology can raise everyone’s game and provide more information, faster. Automation can free humans from rote, mechanical work to do human, thinking work. There’s less room — less time — for overhead and waste.

More than ever, performance of the enterprise depends on individual people working together. And that means looking at individual skill-sets differently.

Lesson 4. Diversity, Teamwork, and Cross-functional Abilities are the New Superpowers


Zumwalt‘s technology means high awareness – but its up to the crew to act on it in time. (AviationIntel)

Whatever your organization is up against — battlefield, marketplace, research goal, or social cause — the environment in which you navigate is more volatile today.  The web and social media means everything is connected to everything else. What you “know” to be true can shift more rapidly and unpredictably now than in the past 300 years.

Traditional teams and organizations are at a disadvantage in this kind of environment. Teams whose every move is subordinate to a supervisor. Teams tiptoeing around the brilliant-but-difficult “superstar.” Teams in the dark about potential problems because their diligent-but-silent “hard worker” never asks for help.

It’s not the teams’ fault — these are the traits we usually hire for. “Takes direction well.” High GPA, high individual achievement. Most solo papers published. “Strong technical skills.” Independent “self-starters.” But today’s fast, chaotic environment needs High-Performing Teams more than high-performing individuals. And the science shows that what we usually look for in individuals needs an update.

The Zumwalt's crew (U.S. Navy)

The Zumwalt’s crew (U.S. Navy)

Teams in the 21st-century enterprise need to be composed of diverse people who mesh well together. People with not just good IQ, but good emotional intelligence — EQ. People who communicate openly and effectively. Who cross-train and appreciate each others’ jobs. Who put the overall mission above their egos. These teams perform well under fire because they cross-monitor, offer mutual support, and allow situational leadership to flow from person to person as needed.

Captain Kirk was asked how his reduced team was going to provide “force protection,” the military term for preventing hostile action against the crew. His answer is “we’re going to do it very well.

Our philosophy is going to be akin to the Marines Corps’ philosophy that every Marine is a rifleman in that every sailor on board must be a force protection expert.

They are also going to have to have a firm grasp of damage control, medical response, evacuation and care. If you get those three things in everybody’s ‘job jar,’ then you have the bench you need in an emergency while still having sailors trained and ready to execute their in-rate skills at different conditions of readiness.

Like Captain James A. Kirk, leaders of 21st-century enterprises will shift away from identifying candidates with the best skills for the job tasks. Instead, they’ll need to start screening for those who can perform the job tasks — and selecting the ones with the diversity, responsibility, communication skills, and sense of mission above self to best fit the mission of the team.

These were the first four lessons that popped to mind when I first read of the Zumwalt and her crew. What others do you see?

All articles in this series:

  1. “Raise the Game” — Automation is Required
  2. “Same Sheet, Different Data” — Tech Is Not Enough
  3. Management Overhead — Reduce the Waste
  4. Team Skills Needed — Diversity, Communication, Mutual Support (this page)
 Posted by at 5:15 pm
Oct 162011

I recently spent a day helping the leadership of an organization make the leap from “can we become Agile?” to “now we’re becoming Agile!”  The problem was one of mindset: getting people to think less about barriers and more about what actions are possible.  My solution involved hands-on experiential learning and structured group debriefing.

I’ve written about it below, but I’m a visual person so I’ve added a lot of captioned pictures if you want the gist, and the how-to “recipe” for doing this mindset-shift yourself is at the end.

Continue reading »

 Posted by at 6:59 pm
Sep 302011

At Agile Coach Camp I conducted a small session on balancing advocacy with inquiry when debriefing or trying to defuse tense situations.  Olaf Lewitz gave a very kind write up of the session (with pictures!) in his blog post Test-Driven Conversations and explains the learning he took away from the session.  Thanks, Olaf — and I love the title!

I did have a tweaks to the explanation, having to do with the example of Joe seeing Jim throw a plate on the floor, where Jim says “…if I was doing that I’d have been crazy.”

That’s an example of a judgmental statement couched in advocacy/enquiry language.  The judgement there is “you are crazy” and the interaction is tending toward the implication that there is some fault on the part of Jim.

If Joe were truly approaching the situation with desire to find out Jim’s internal motivation and wished to balance advocacy with enquiry, Joe might have said something like:

“I saw you throw that plate on the floor (fact), and I was frightened because to me throwing things is a sign of anger (advocacy).  Can you help me understand what was happening? (enquiry)

Advocacy requires that you expose your own internal frame/motivation, which doesn’t necessarily mean keeping your emotions to yourself — it just means that you expose them directly by stating what they are, rather than indirectly through tone of voice, gesticulating, etc.

Of course, being able to do this requires that you know what’s going on inside your own head too… not always easy to be aware of when emotions are high. :)

 Posted by at 5:28 am