The Kobayashi Maru

One of the more challenging things I run into as a designer is the “no-win” design problem.

The Kobayashi Maru is a Starfleet training exercise designed to test how a cadet handles a no-win situation, how they perform in the face of insurmountable odds. It tests their:

  • character
  • ability to redefine a problem
  • ability to lose gracefully

It goes like this. The cadet is leading a ship on a mission to rescue a civilian ship, the Kobayashi Maru, which is about to be attacked by the Klingons. The ship has been stranded in a Klingon demilitarized zone. The cadet must decide whether to enter that zone and risk her life and those of her crew (as well as potentially starting a war with the Klingons), or leave the Kobayashi Maru to be destroyed.

If the cadet chooses to attempt rescue, the simulation is designed to guarantee that the cadet enters a situation where she will have no chance of winning, negotiating, or even escaping. If the cadet chooses to leave the ship to die, the mission fails, and dishonorably so.

Many design problems can be the Kobayashi Maru in disguise, depending on how the designer and her leadership or peers view it. Not all projects will allow one to go through a perfect design process, perfectly ship, and perfectly perform. Design, like leading a crew in a ship in space, is a team effort, and is subject to a system of relationships, events, choices, and problems that are outside of the designer’s control.

There’s more to learn about a designer in how he or she works through a no-win design problem. How does she re-frame the work and her role on a team when she realizes it’s a no-win situation? Does she design “what it should be” and throw it over the fence and let the engineers figure out how to build it? Does she design something that’s doable, to ship something, get a “win,” but that she knows isn’t going to solve a user’s problem? Does she punt to “incremental shipping” or testing that she knows will never happen? Or when she realizes that all hope is lost, does she lose her shit and blame it on other people–the engineers, the marketing team, her manager? Maybe she refuses to work on it altogether. Or does she team up with others and negotiate and potentially come up with something even better down the line, even if it’s not pixels, today?

This has happened to me plenty of times, and I used to give myself a pity party until I learned to take a step back, and learn something else from the situation about what it means to be a designer. The people part, and the reality part.

Still, it can happen, and catch me off guard. More recently, a mentor of mine had pointed it out, that I had been on a series of “no-win” projects. Even though I always take the “rescue the ship” approach, I can’t always guarantee that others will see the work as a no-win situation. They may still expect me to pull everything off cleanly, for it to count as a success. For example, there was one situation where, the simpler I designed the thing, the more I would be disappointing the user. Because design isn’t just about UI. I redefined the problem in the context of business and user value, but that increased scope, became more about strategy, and generally went beyond what people are used to designers doing, and that weirded out people. At that point I realized I had lost, and I decided to make the most of it by communicating my findings, recommendations, partial solutions, and make peace with it. I wanted to fix it though, and I could have, pero nimodo.

I think this experience cost me an opportunity to be seen as a leader on my team–on my specific team. To others, the “winning” approach would be to design something pretty quickly, and ship it, and then wait for the metrics to come in. But to me, that would have been the cowardly, “let the civilians die” approach, because it wouldn’t have been solving the design problem. Unlike in a Kobayashi Maru situation, where it would have been more about how I handled the situation, here it really was about whether I could declare a design victory.

Designers love to tell stories of successful accidents. I wonder if that’s another reason why people praise the type of person that doesn’t wait too long before shipping something–what I was expected to do. But crafting surprises isn’t a skill you can learn. Part of being a designer is spotting when something is just not going to work, having the courage to bet on an outcome, and signal risk. If you end up being wrong, hopefully you’re also humble.

I could have shipped something sooner. I should have, and made people happy, to gain their trust. Then I could have had data on my side, at least. But then that could have cost us some money…or call into question why I didn’t call out the likely failure…you get the picture. No win.

If I hadn’t known about the Kobayashi Maru–meaning, if I wasn’t a Trekkie–and approached the situation as an opportunity to practice how to redefine problems, and how to lose, I could have blamed others and gotten angry and bitter. And still look like I couldn’t pull off a project right. Instead, I learned about what type of designer I am, what type of leader I might be, and how that might not always align with what others view as success. This awareness is more valuable to me than having pocketed a “win.” Thank you, Star Trek, you keep having my back.

Edit:

I had written that I wasn’t going to get into the option to just leave the ship to be destroyed, because it was a sign of a designer “being lazy or entitled.” That was probably a knee-jerk reaction thing to say, prompted by my own experiences.

There are plenty of powerful Star Trek episodes where captains and crew have to decide to let people die. I wonder if the equivalent is saying “no” to a client, or a project. Not sure, I think the stakes are higher in this analogy. But still good stuff for conversation.