Some industries have a lot of cross-pollination -- including computing and airplane flying. There is something about being at one in the sky with that conglomeration of odd pieces of technology called an airplane that can easily be indelibly stamped into the DNA.
Then there's Gary Kildall, who developed CP/M, which gave the 8080 processor the ability to control floppy disks. In 1980 IBM approached Kildall's company Digital Research with an offer to acquire a release of CP/M, CP/M-86 for the IBM PC. Kildall, the story goes, left negotiations to his wife as he typically did, to deliver software to Bill Godbout. IBM insisted on his wife signing an NDA which she refused to do until Kildall returned. Kildall later grumbled about a rumor perpetuated by Bill Gates and the press that he blew the deal between IBM and Microsoft because he "went flying" for fun instead of sitting in the contract negotiations. Negotiations went awry. Precisely what happened is not known, but the deal was never sealed.
I was introduced to computer technology via avionics. At the time, I was deep into building a single seat aerobatic aircraft called a One Design, when one of my contributing editors, Wayne Rash, turned me onto the Comdex trade show. When he saw how much I enjoyed being part of the exploding frontier, Wayne said, “You know, Alyson, I think you’d like reviewing technology products. You might live a little longer.”
He was right. I fell in love with the process of pulling devices apart and re-constructing them, banging my head against the wall when I couldn’t bring up a device on my test network, and stubbornly working into the wee hours until I succeeded, to drive home when the street signals were flashing.
Yet aircraft have remained a part of my DNA.
Here are a few true-isms discussed by pilots anywhere we congregate. The conversation could be in the flight instruction room at a whiteboard, or at a local airport restaurant like Typhoon, over a beer or ice-cold martini with hand motions mimicking aircraft in flight, “…and there I was!” Their points apply in managing technology too.
Plan the flight and fly the plan.
Many factors go into a flight plan: weather, aircraft performance, fuel stops at airports en route, etc. For an air show or aerobatic competition, factors like aircraft performance are calculated to take into consideration factors critical to the safety of the flight, including temperature and density altitude.
Pilots are often tempted to alter their flight plans for unimportant reasons like checking out the river below them or pushing on past a planned airport fueling stop because they think they have enough gas to make it to another airport. This can get them into serious, life-threatening trouble. For instance, a pilot forgot to check his chart and end up tangled in power lines that hung low across the river. Or she didn’t notice a wind shift and ended up without enough fuel to make it to her next fuel stop and not enough to turn back and make it to the planned airport for refueling. Instead the pilots end up landing off airport on a road in the middle of nowhere.
It pays to carefully plan the flight taking into consideration all exhaustible information to make a comprehensive plan. Once filed, stick with it and stay safe.
In technology, we are often tempted to change aspects of a project because we’re having problems completing a specific phase. We may try to introduce workarounds or to scale back to keep the project on schedule. Carefully performing a needs analysis or a content map and planning every aspect of the website’s architecture or the network’s design before diving into the project can save significant time and money. It’s not fun to be ready to launch a new product portal and have the CIO ask, “Where’s the ‘Search’ feature, and where are the data sheet PDFs supposed to reside?”
Demonstrate your superior judgment to keep from having to demonstrate your superior skill.
This is a natural extension of the one above. Pilots sometimes find themselves debating whether to take off due to factors like marginal weather, marginal aircraft performance, or other safety concerns. Generally, if a pilot has to ask whether whatever she’s contemplating is a good idea, the answer is “No!” Stay on the ground, so you don’t have to impress your passengers with how well you thread between clouds and how well you dove through that sucker hole!
In IT, it’s always better to use judgment rather than skill in recovery. Test that network and its infrastructure prior to launch, rather than impressing the CEO with your skills by how fast you bring it up after it crashes three days in a row.
Never trust your life to an aircraft with a single point of failure.
No one wants to hear the sputter of an ailing engine, then see the propeller come to a dead stop in front of his eyes. This is why aircraft piston engines are built with two electric generators that create alternating current, called magnetos. One magneto can fail; the other will keep running and the engine will still run.
Never trust your business to a network with a single point of failure. Good network designers and engineers always provide for a outage by including alternate devices like load balancers, multiple routers complete with current security updates, uninterruptible power sources, and regular content backup.
Altitude is your friend.
When things head south in an airplane, it pays to have plenty of altitude. Altitude gives you time to diagnose, troubleshoot the problem and, if unsuccessful, look around for a place to land with minimal consequences.
For IT, the payoff comes when the department has not undersold the complexity of a network or portal buildout and they allotted plenty of time to be successful. Setting realistic timeframes and feature expectations is crucial to success. With enough time built into the project, the IT staff has the flexibility to troubleshoot, diagnose, and fix the issues without the pressure to launch an untried final product.
At the end of the day, after a successful rollout, IT is a hero.
See also:
