For an industry that prides itself on its analytical ability and abstract mental processing, we often don’t do a great job applying that mental skill to the most important element of the programmer’s tool chest—that is, ourselves.

"So, boss, you’ve heard his idea and you’ve heard mine, and we’ve gone through why we each think our idea is the better approach to take. What do you want to do?"

Although it seems to be self-evident, it still comes as a surprise to many new managers that they will be called upon to make a decision. Sure, it’s often true that the team can figure out a number of things on their own, but sometimes, the team can’t come to a unified decision. Sometimes they require some sort of guidance to deal with a thorny situation. Sometimes it’s the new manager’s boss who demands a decision—which candidate to hire, or (far worse) which employee to fire.

It’s a frightening position to be in: upon your words, your decision, the company will undertake some action, and there’s no "going back" after that. A fired employee will not come back if that turns out to be the wrong choice, and you can never recover the time, money, or energy invested into a project that turns out to be an economic dead-end or technical quagmire. As they say in the movies, "It’s all on you." Your decision, your fault. Sure, you’re more than happy to claim the credit for the decision when it turns out to be the right one, but the fear associated with making the wrong choice? It can be crippling.

That’s part of the reason that so many managers prefer to pass the decision up the management chain, and have their boss make the call. And it’s why so many middle managers appear to have no power or authority whatsoever.

Management and Poker

Annie Duke is a pretty good poker player. She’s won a number of televised tournaments and as a result, she’s made quite a reputation for herself in her ability to judge a good bet from a bad one. But much of that reputation doesn’t derive from her success at the poker table. Instead, she’s taken up providing advice and consulting, much of it in the form of seminars and books, to financiers, traders, strategic planners, human resources groups, entrepreneurs, and more. Annie has, through exposure at the poker table, figured out that many, if not most, decisions are actually bets: decisions about outcomes in the face of an uncertain future. Each time managers are presented with a decision to make, they essentially do the same mental exercise that the poker player does when presented with a set of cards and a pot in the center of the table: They’re trying to peer through the fog of the future by examining the present and make a choice today that will hopefully yield a positive outcome tomorrow (or in a few minutes, when the cards are all on the table).

Poker players have to make these decisions hundreds, if not thousands, of times in a given setting, and usually have nothing more than a few minutes’ time in which to make them. You don’t succeed at poker if you’re bad at making those decisions, and you don’t succeed at management, either.

But let’s begin the analysis of betting-as-decision-making by examining what many people (particularly my neighbors here in Seattle) consider the worst play call of all time: Pete Carroll’s decision to throw a pass in the waning seconds of Super Bowl XLIX at the New England Patriots’ goal line. For those sports fans who missed that one, Carroll’s choice to throw, instead of hand the ball off to Marshawn Lynch, one of the best running backs in the league that year, turned out to be a bad call, as the pass was intercepted by the Patriots and the Seahawks lost their chance at a second championship.

After the game was over, the popular media roasted Carroll, using headlines like "Worst Play-Call in History." Certainly, it was the least-desirable outcome, to be sure. But Carroll found a few outlying supporters in people who examined the decision on its own merits, rather than by the outcome: FiveThirtyEight.com, for example, noted that the pass, had it fallen incomplete, would have stopped the clock and allowed for an additional play, whereas the run could have burned up all the time remaining. Across the history of the league that year, that play—a pass at the two-yard-line—had been attempted sixty-six times and never once intercepted. In other words, by looking only at the data that Carroll had at the time, the pass was actually a very solid bet. So why all the criticism and heat?

As Ms Duke puts it, "We can sum it up in four words: The play didn’t work."

When a bet is made, we often judge the decision to bet one way or another by reviewing the outcome after the bet’s resolution has been discovered, rather than looking at the data at the time of the bet. Imagine this: Had the play succeeded, the Seahawks would’ve been heralded as "amazing" and Carroll’s play-calling as "brilliant." But this would be an equally unfair assessment of the bet, for the same reason—to judge the quality of the decision by only examining its outcome is to essentially relegate decision-making to be an entirely backward-looking exercise and leaves us with no ability to determine how to make better bets.

"But isn’t that the point?" some will argue. "Isn’t the whole point of a decision process to figure out which is the right decision to make, and then make that decision?" Sure, if life were a game of chess, where all of the factors involved in making a decision are right there, on the board, easily visible to anyone familiar with the game. Chess is a game of perfect information—neither player has any more information about the state of the game than the other. Alas, life gives us no such clues or hints. Much of the information we might want or need to make a decision is hidden from us, just as in poker.

Every decision will be affected by two factors: skill and luck. (Some will argue that there’s no such thing as luck, that all of the factors could be discovered, identified, traced, and accounted for, but usually we don’t have that kind of time, so let’s leave all of those un-accounted factors under the general umbrella of "luck".) In the Super Bowl, certainly, skill was involved when the defender made the catch, and when the defender was coached to recognize the play call, and when the Patriots coach studied the film of previous Seahawks games so that he could identify this play as one that the Seahawks might run. But luck takes a hand here, as well—the defender could’ve missed the cue that this was the upcoming play because his attention was on a different part of the formation, or even a stray arm could have deflected the ball away from its intended flight path. Luck is always present in these sorts of decisions, and our goal as decision-makers is not to try to eliminate luck entirely (good luck with that, pun intended), but to account for it in both our pre-decision analysis and our post-decision analysis.

It begins with the realization of several things that readers of this column have heard me talk about before: Understanding that our brains are wired to believe in confirmation bias (viewing outcomes in a light favorable to ourselves). There’s the classic "causation vs. correlation" argument that comes into play here, as well: merely because a particular decision was made and a particular result emerged doesn’t mean that the one caused the other, only that both happened. (The old joke about a man in Florida selling Genuine Polar Bear Repellent comes to mind. When challenged by a passer-by, the salesman replies, "I’ve been using it for twenty years and never once has a Polar Bear been seen anywhere in my vicinity." Although, given current climate change rates, that joke may not be funny in about fifty years, either.)

Embracing Incomplete Knowledge

Unless you happen to be a deity of some sort, it’s only a matter of time before you’re presented with the need to provide an answer without having complete knowledge—the decision to purchase a warranty on a new appliance, for example, or the decision around which new programming language to learn to better your chances of obtaining a better job. This is a bet, no different than being dealt five cards at a poker table. Information will be hidden from you, and no amount of study or analysis will ever yield that information. At the poker table, you might be able to track the cards that have already been used—the card-counting technique—but most poker tournaments use many decks together in order to minimize the benefit that knowledge of history might provide. At the appliance counter, you might look at reliability reports for this brand of appliance, but that still in no way means you won’t be the one-in-a-million that gets the one that breaks all the time. (Fortunately, you should be safe—that fate seems reserved for my wife and me.)

All of which means that if you’re to be comfortable with taking bets, you need to embrace the idea that you simply don’t know. As Ms Duke puts it:

Because now, once we know that we don’t have perfect information, and once we accept, deep down, that we will never have perfect information—no matter how many prototypes we build or how many benchmarks we run—then we can begin to perform the necessary analysis of figuring out how unsure we really are.

Betting on the Team

Recently, my management at Smartsheet asked me to build out an Engineering team that would stake out some new ground within the company. We’ll be using a new platform (React and Node, instead of Java), and we’ll be looking to hire younger, less-senior developers so that we can staff up the team quickly. Within two months, I had a team of seven people, five of whom were relatively brand-new to the industry. One of my management peers looked at me with a high degree of skepticism one day, and said, "How do you know that these people are all going to work out?"

To which I responded, "I don’t know. I’m just betting on it." The team lead, the recruiting team, and I, we did what research we could, we looked to establish what knowledge we had, and then, we placed the bet.