The Sterile Cockpit

On September 11, 1974, while flying an instrument approach in dense fog into Charlotte, North Carolina, an Eastern Airlines DC-9 landed just short of the runway and crashed, killing 72 of the 78 on board. After an exhaustive investigation, the NTSB determined that pilot error was the primary cause of this accident, citing “poor cockpit discipline” in their report, specifically, non-essential conversation between the flight crew members during the approach part of the flight. Due to this accident and others like it, the FAA in 1981 instituted a rule called the Sterile Cockpit Rule, which prohibits non-essential activities by the pilots during critical phases of flight, including taxiing, takeoff, approach, and landing – more precisely any activities occurring below 10,000 feet.

So what’s the point of this? In my experience as a software engineer and a manager, we are most productive when we are focused for continuous blocks of time and have few if any interruptions and distractions. Inversely, our productivity takes a non-linear hit with contextual task switching, especially when the tasks are not homogenous. In his book Quality Software Management, Vol. 1, Systems Thinking (Dorset House, 1992), Gerald Weinberg estimates that context switching between projects costs 20% of time for each additional project undertaken. So if a person is switching between 3 projects in a 45-hour week, 18 hours are spent context switching, with 9 hours spent on each project!

Rock climbers often speak of “flow, a state they enter when they’re climbing, in which their entire body is involved in the ascent and the climb up the rocks feels effortless. A recent incredible 60 Minutes report on super star rock climber Alex Honnold demonstrates this state. As Alex approaches the toughest and most dangerous part of his climb, he is totally relaxed, focused and even smiling (advance the video to the 10:45 mark). A book that came out in the late 80’s, Peopleware (Tom DeMarco and Timothy Lister), based on research started in the early 70’s speaks of this magical “flow” state. When software developers enter this state, time stands still and the computer becomes an extension of their mind and body. This is the state when they crank out their most valuable and productive work. According to the book, it takes at least 15 minutes to enter this state, so every interruption costs 15 minutes of productivity. That means four interruptions in a day will cost an hour of productivity.

So where does this takes us? Should we stop answering email, responding to questions from teammates or peers, or even taking a smoke break? That is hardly practical, and ill-serves our customers and stakeholders. However, what this data tells us is that we have to introduce and enforce uninterrupted blocks of time when software engineers can get into the “flow” and remain there for a few hours. Most of us currently experience these magic blocks of time either early in the day before 10:00 am (if you’re an early bird) or late in the day after 5:00 pm (if you’re a night owl). However, during the middle of the day between 1:00 and 4:00, everyone gets interrupted with a meeting at least once a week.

With that in mind, I have frequently implemented for my teams a meeting blackout period – an Engineering Sterile Cockpit – between the hours of 1:00 and 4:00 every day. During those hours, no one would be allowed to schedule a meeting for members of the team unless it is of a critical nature. That includes meetings for design, user story creation, review or sizing, process discussion, demo, planning, etc. Those meetings should be scheduled before noon or after 4:00 pm. While this may create a slight inconvenience for some team members or stakeholders, the benefit will immeasurably outweigh the cost.

Is this a silver bullet that will take care of all interruptions and context switches? Hardly. But it is a concrete action your team will appreciate immensely and one that will pay dividends for the business. A common theme I observed over the years in many team retrospectives is the perception that there are more and more meetings. But whenever I looked at my employees’ calendars, I discovered that for most of them that is not the case. I am now reasonably confident that this perception is borne out of their inability to get into a “flow” state – precisely at the time when they are ready to enter it.