we could dive into devising solutions so that this boat never ran aground again. I'm familiar with the responsibility to keep your keel wet. When I was 24, I served as the Navigator aboard the USS Reuben James, a frigate stationed out of Hawaii.
My quartermasters and I knew every inch of shoal around Pearl Harbor and most of the inches surrounding the Big Island and Kauai. The Navy graciously provided us reams of instructions, checklists, requirements for data recordings and a detailed logbook of all commands given on the bridge of the ship. All of that process doesn't prevent Navy ships from running aground, yet the layers of regulation get piled on after each new incident.
I had a friend who served as a navigator in the Coast Guard. After serving on two cutters, he subsequently did a cross-service tour as a navigator on a Navy ship. The manner in which the two services practiced safe navigation were worlds apart, he said.
The Coast Guard, since they didn't have many people, were required to be more independent and solve problems at a lower level in the hierarchy. They were just fine without the layers of bureaucracy the Navy had. All of the Navy's records and extra watches require people, which the Navy has plenty of. Here's the problem: The comfort of adding "solutions" to the problem of safely navigating shoal waters, solved an Admiral's anxiety but usually did little to change the process of navigation at sea.
Navy ships run aground very rarely. This just happened to be the arena where I experienced the military's penchant for finding solutions, rather than understanding the problem from the point of the end user. Sometimes, what you may think is a problem isn't a problem at all. Instead, it may be an interlocking set of challenges, opportunities and unleashed potential energy.
The work of diving into the problem first is messy in a complex organization. Sometimes there are several user groups with problems ranging from the technical to the small-unit team level, to deeper problems baked into the bureaucracy. You can't solve everything, and it seems limiting to narrow one's solution to a smaller, limited focus.
But this is exactly what design thinking offers -- a structured process to dive into a complex problem and understand it through the stories of its users.
The problem that once seemed like a slippery thing-beast is tamed and set on a whiteboard or a set of Post-its. I've advocated design thinking to those in the Navy, and when I do, they get a gleam in their eye. It sounds like the promised land. They can rely on a process to help them access the fickle muse. The catch is that they still have to make decisions -- and very hard ones at that. Brainstorming is so much easier than the process of narrowing multiple stories into insights. Solution-finding is a joyous exercise that involves going wild with new ideas and exploring the horizons of possibilities where a new change to an official instruction or a tech upgrade ushers in emergency-free nights.
Design thinking overall is also serious; it involves making choices, and is dependent on constraints. Before we ever get to the ideation stage we've spent several rounds doing interviews, empathizing, and defining insights. Each of those exercises requires us to choose who to observe and which nuggets are surprising.
I believe that if we do the work at the beginning to understand our user -- to understand the problem set we've chosen to engage with -- we have the greatest chance of arriving at the best solution. In other words, let's pivot the focus from how we change our process after ships run aground to focusing on the people running the ship and the system of regulation around them.
When we make the kinds of pivots, the slippery thing-beast turns out to be not so slippery after all. You just have to make the choice to wrestle with it awhile and rub off the oil to get to the scales on which you can grip.