Battling through the turbulence: How learning to fly planes has made me a better CEO
Just like when a pilot hits turbulence, leading a company can have its rough patches. But it’s important to push through and realize that good results come from slow, steady and focused work. The US Navy SEALs have a saying that goes, “slow is smooth, smooth is fast”. I think that same motto can be applied to running a business.
Although turbulence is actually rarely something to worry about, you can quite easily lose your cool and make a mistake. When I have been overloaded with tasks at my software development company, come across an unexpected bug, or just had to deal with new, inexperienced employees, I always think back to my time flying tiny 2126 lbs private plane.
At the end of the day, things need to be done without haste when under pressure and a checklist needs to be followed in both fields of work. You need to take time to slow down, breathe, and see what’s really happening. Half the time, it’s not as bad as you think. Here are the most important things I learned from flying – and how they make me a better CEO.
Know your limits
My flying experience only involved flying a Cirrus aircraft within the US. But there were times when I had to think fast. I remember on one occasion I was a time flying from Salt Lake to Las Vegas over mountain area. This distorted the airflow and caused the plane to rock quite a bit. Then it started to rock even more before losing altitude suddenly.
It went on for longer than I had expected and I started to panic: for the first time in a while flying, I was scared.
But I thought back to the advice I had been given as a trainee: trying to move too fast could cause more problems. I went with it, breathed, and took time to think. I checked my equipment and made sure everything was in order. In the end, I got through it and made it to my destination safe and sound. Though if I had been too hasty, or rash, I could’ve made an error.
Just as pilots need to check weather and pressure conditions before making a flight, developers also need to clearly outline every project they undertake. As a CEO, I have to make sure that my employees also know how a project is going to pan out.
Manage your time
When running a small business, it can be tempting to take on too much work, which can ultimately be detrimental. In the same way, a small plane can’t fly as long as a 747, you need to be realistic about your capabilities, or things could get dangerous.
When flying a plane, one needs to be focused, intensely, for specific periods of time. The same goes for developing, which is why we work in two-week sprints. When we are only focusing on one problem, it is easier to stay on track. Small, fast bursts of work are what is needed in development. Just like flying a Cirrus aircraft from Ohio to Pennsylvania – I know how long it will take.
One thing that always helped me – when flying, when training how to be a developer, and today managing a team – is a checklist. Atul Gawande’s “The Checklist Manifesto” argues that there are many ‘methods’ for getting things done. But still, in almost all fields, we still make avoidable mistakes. The solution to this could be as simple as a checklist. I relied heavily on them before taking off: the cabin doors; fuel pumps; vacuum gauge. I couldn’t live without them when tackling a large software project and now, dealing with my clients and leading a team, they are as essential as ever for making sure things get done.
Spread the load – pair programming
When there are two pilots in a plane, they will split the load, and at times one will be more focused on one particular task than the other. This is essential in aviation. The same goes for developing.
In my small team, the developers are always paired. This usually works with one programmer writing the code and the other one reviewing it. Code review is essential and pair programming only allow for continuous code review has only ever worked for me. Similarly, when two pilots are in a cockpit, one will always scrutinize whether the other is doing something correctly.
I also believe this allows for longer periods of focus – one developer is always able to spur the other on or motivate when distractions crop up. When I remember back to when I would code alone as a rookie, I would lose concentration to look at emails, surf the internet or just switch to a different coding task altogether. This is rarely the case in pair programming: procrastination becomes a lot harder. And it makes it easier to do continuous code review, too. Similarly when two pilots are in a cockpit, one will always scrutinize whether the other is doing something correctly and talk focus on problems. It also allows for greater communication. Like with radio communication with an airport, I see my developers working in the same way. I remember finding the repetition irritating at times, but it’s what makes sure everyone is on the same page. When I have a new developer on my team, I find I repeat myself a lot as a CEO. But this is the best way to get results.
So there you have it. I’m sure the checklist-style of doing things when flying can be applied to many different fields of work, but particularly when developing. Comparably as a CEO, the experience I have had in the air has allowed me to deal with problems with more ease, manage my own time more effectively, and realize how to delegate tasks correctly.