What five things do SCUBA diving and IT management have in common? IT pro and SCUBA diver Patrick Gray has the answer.
I recently returned from a SCUBA diving trip to the Cayman Islands. My wife and I had a great and relaxing week—it was our the first time away from our small children in quite awhile.
One of my favorite things about diving is the quiet and utter relaxation. You are able to move in three dimensions and gently drift with the current. The only sounds are your breathing, exhaust bubbles, and the occasional distant hum of a boat motor. It's a good time to let your mind wander, and I was struck by some of the parallels between diving and effective IT management.
Establish a common vernacular
You cannot speak underwater, so communication between divers generally relies on hand signals. While some are obvious and universal—making a "head cut off" motion indicates you're out of air, for example—others vary regionally or are based on where you were trained. A "thumbs up" generally means you're headed to the surface, although it could easily be misinterpreted as "this is cool!"
Before a dive, good divers discuss which signals they'll use, particularly to indicate when it's time to turn around and start heading back toward the boat. For IT leaders, it’s worth making sure everyone understands how and when to communicate, and what forms of status reporting and escalation procedures are expected.
Communicate key metrics
A solid plan and appropriate metrics are key to diving, since poor consideration of either could literally result in death or severe injury. Air remaining in your tank and bottom time, which determine how long you can stay before running the risk of "the bends," are the core metrics that drive all aspects of dive planning and how the actual dive progresses.
For IT leaders, communicate the handful of key metrics that drive your IT operation. Unlike diving, where air remaining is a universal metric, one IT shop might be driven by service cost, while another might be tied to a business metric like lead generation. Just as air pressure or bottom time drives your decisions underwater, communicating your key IT metrics allows your team to make decisions informed by those metrics.
Ensure teams hold individuals accountable
Divers usually dive in buddy teams. While all divers carry a spare regulator and some level of backup equipment, having an assigned “buddy” provides a completely redundant set of gear as well as a "redundant brain" should something go terribly wrong. While the buddy system provides a great layer of safety, the individual diver is ultimately accountable for monitoring their air and bottom times, and recognizing when they are out of their comfort zone and aborting the dive. Ultimately, a diver who fails to take individual responsibility won't be around to blame their team should things go fatally wrong.
In most business functions, teams have long been the standard. A team brings complementary skills, redundancy, and perhaps specialized technical skills around a common objective. The major risk with teams is that no one is individually accountable, allowing the team to aimlessly wander without an objective. Leaders can and should assign objectives to a team, but ensure that the team is effectively holding individuals accountable for those objectives. The team should augment and enhance individual performance, not serve as an administrative layer that prevents actual accomplishment.
Rehearse critical procedures
The majority of the practical and procedural items related to SCUBA diving can be learned in a couple of hours. In fact, most dive locations offer an abbreviated "resort course" that teaches the basics and sends you on a closely supervised dive in the open ocean. If you pursue your actual certification, the vast majority of the coursework, pool work, and open water practice dives are occupied with practicing emergency procedures. Hopefully, you will never use these procedures, but they will literally save your life.
For IT leaders, it is also worth planning for what might go wrong, even if there is a relatively remote risk of the worst case scenario ever occurring. Testing disaster recovery procedures is relatively obvious, but how about testing out the new training procedures for your front-line employees, or doing a usability study on that critical new web application?
Review past dives/projects
Divers usually keep a log book with technical notes about bottom times and maximum depth, as well as free-form notes that range from "Saw a huge shark" to "Bring a thicker wetsuit when diving in water below 80F." The log causes us to examine our performance and note ways to improve future performance, allowing us to reflect on past dives and how we've improved as divers.
Many IT leaders do a poor job of "logging" past projects, missing the opportunity to identify effective tools and processes and analyze ways of improvement. Like the diver who keeps a disorganized and incomplete log, we might send a few emails or complete a mandatory form, but it provides little benefit. Like the diver who can review the last few pages of their log and immediately apply improvements to their next dive, an effective post-project process will help your IT organization improve.