Aviate. Navigate. Communicate.

I'm not a pilot, but I've always been a bit of an aviation enthusiast. One of the first rules pilots are taught in flight training is this:

Aviate. Navigate. Communicate.

In a nutshell, this means to first keep the airplane in the air. After that, know where you are and where you're going. Then communicate with flight crew, air traffic control, passengers, etc. This bit of advice is broadly applicable across many disciplines, especially in a crisis. Lots of people have written about it, but here's what I love about it:

It acknowledges that communication is costly, but necessary.

That is to say, communication is not your first priority. You must first ensure that the aircraft is flying safe and level, and that you are aware of your surroundings. But once those priorities have been addressed, you still have to communicate your status and intentions.

Of course this is true for software engineering teams as well. As your product gains traction and your team grows, you have to put communication protocols in place to keep it humming as a cohesive unit. Engineers who had been used to working in isolation and keeping to themselves sometimes chafe at these additional requirements. They've gotten used to aviating and navigating, and haven't had to communicate much or at all up to this point. A lone pilot in the middle of the desert can aviate and navigate without communicating. An engineer on a product team does not have that luxury. She is in charge just of one portion of a much larger craft (the product) with a multi-person crew (the product team) and flying with dozens or thousands or millions of passengers on board (the customers). All of this in very active airspace (the market). She can't afford not to communicate.

What protocols has your team used that either really work or really don't?

Did you like this?

I send a daily email with tips and ideas like this one. Join the party!