Decision-making is all around us, almost every day. Being able to make better decisions, in almost any circumstances, is a real career-booster. The key to better decision-making is to understand the basics of how you can evaluate a situation, and how decisions themselves are made—particularly in business settings. Another key point of this chapter is that it’s crucial to get all the different bits of context if you hope to comprehend the decisions that your company makes.

17.1 Deciding who decides: Decision-making frameworks

The worst kinds of companies are the ones where a small number of leaders, each with a strong personality, make seemingly arbitrary decisions and then inflict those on the rest of the business. Employees don’t understand the thinking behind the decisions, have no input into the decisions, and often feel like they’re just cogs in a machine. It’s not a very rewarding feeling.

The other worst kinds of organizations are the ones who invite everyone to be a part of the decision-making process, but don’t provide any means of resolving conflicting input, conflicting priorities, or any other conflicts. Those companies often get stuck in analysis paralysis, going round and round with what they could do, discussing the pros and cons of every possible choice, and in the end making no choice whatsoever. The best organizations have a decision-making framework in place, so they have guidelines for how they want to make decisions.

To use an extreme example, most military organizations have these decision-making frameworks built right in. A general may say, “We need to take that hill in order to gain a tactical advantage.” But the general knows perfectly well that it’s the sergeants who know how to take hills and that the sergeants’ expertise is an important input into the decision-making process.

“You know, this other hill is a bit higher, and positioned just as well tactically,” the sergeant might offer. “It’ll also be a little easier to take, since it’s already closer to our lines.”

The general might nod and reply, “Yes, but our allies are going to take that hill. I know it’s easier, but it’s been a rough ride with them for the past few weeks and we need to give them a win if we’re going to maintain a civil relationship with them.” The sergeant would likely nod and head back to their team to start planning.

The military is built around the idea of lower-level experts providing input to higher-up decision makers, and then accepting the decision. I just found out today, as I was sitting down to work on this chapter, that Amazon has adopted a similar leadership principle, which they call, “Have Backbone; Disagree and Commit,” meaning that you can and should offer your input, but if the ultimate decision-maker goes a different direction, get behind that decision and do your best to make it happen successfully.

My current employer uses a decision-making framework called RAPID, which was developed by Bain, a management consulting company. RAPID stands for Recommend, Agree, Perform, Input, Decide, and for most major ongoing decisions, we identify the job roles within the company that own each part of the RAPID, so it’s clear to everyone who is involved with each of these five steps. Here’s how we break down these roles and responsibilities:

• Recommend—Makes a recommendation for the decision; in the case where there is no clear-cut “win,” may make multiple recommendations and outline the pros and cons of each. For example, a senior developer might recommend a particular software library for use within a project.

• Agree—Stands behind the recommendation, which means they’ll work with the Recommend role to come up with a recommendation everyone can Agree with. For example, given a software library recommendation, the DevOps, Security, and overall Development teams might need to agree that the library will work for their various needs and concerns.

• Perform—Executes the decision; usually provides valuable input to the recommender on what will and will not work. For example, the actual software developers using a new software library will perform the implementation of that library.

• Input—Provides additional input and data to inform the recommendation; this includes business analysts and other decision-support roles. For example, a variety of people potentially impacted by the adoption of a new software library might have input into which library is chosen.

• Decide—A single person who ultimately decides what will be done, and is accountable for it. For example, the manager of software development might ultimately decide on which library to adopt, based largely on the recommendation brought to them.

Ordering RAPID by chronology RAPID is a nice, easy-to-pronounce acronym, but it confused me when I first learned of it because the tasks aren’t performed in the order in which the acronym implies. Chronologically, you’d start with the Input, get people to Agree to a Recommendation, Decide what to do, and then Perform. But IARDP is a terrible acronym!

Figure 17.1 shows the chronology for how a RAPID decision is often made.

Figure 17.1 Making a RAPID decision

Every bit of RAPID except the “D” can be a single person or a group of people. The fact that only one person can “own the D” means that there is one voice, typically someone responsible to the business for whatever outcomes are being considered. This is the person who ends the debate and adopts the direction in which everyone will move. Once the “owner of the D” makes that decision, it’s everyone else’s job to implement it. The decision doesn’t have to be popular, and it doesn’t have to be something everyone agrees to, but it is the decision, and everyone must work to put it in place.

Can only one person “own the D?” It’s possible for a small group of people to “co-own the D,” but it can create problems when that group can’t unanimously come to the same decision, right? After all, if they “own the D,” who acts as referee? Sometimes, it means reconsidering ownership. For example, in one organization I’ve worked for, we had certain high-level decisions that my team’s executive technically “owned the D” on. However, for day-to-day purposes, her leadership team of four people had delegated ownership. Provided they all were on the same page, the executive didn’t get involved and those four “co-owned the D.” If they couldn’t come to a consensus, she would step in and exercise actual ownership.

As an individual contributor, your job is to do the best you can at providing data-driven input, helping the decision-maker make the most informed decision possible, and compromising when needed to create agreement. Once the decision is made, it’s your job to get on board, and not continue to argue or debate. This framework only works when everyone can commit to their roles, and commit to respecting the final decision that’s made. There are plenty of other decision-making frameworks out there; the point is that a good company has one in place, so everyone at the company knows how decisions are made.

17.2 Deciding what to do: OKRs, rocks, and pebbles

Almost all companies have more things they could be doing than they have resources to actually do. That means they need to decide which things to focus on. Given all of the things we could do, in other words, which ones will create the most positive impact? Deciding what to do, and what not to do, is a huge deal.

Frameworks like RAPID can help identify the people contributing to, and making, those decisions about what to do and what not to do, but there are additional models that businesses can use to help weigh the pros and cons, as part of the decision-making process. These models can also help the entire company understand why a particular prioritization decision was made, and help keep the company focused on those priorities that the company had decided to pursue.

These models can help on anything from a small team to an entire business, and they’re a great way to communicate what the priorities are, and to keep everyone aligned to those for a given period of time (like a quarter, half-year, or year).

17.2.1 Rocks and pebbles

The first is an analogy from Stephen Covey, who wrote the best-selling The Seven Habits of Highly-Effective People : rocks and pebbles. Imagine you have a bowl. This bowl represents the time you have in a day, or month, or quarter, or whatever. The bowl is, therefore, a fixed size: just as you cannot create more time out of thin air, you cannot make the bowl any bigger.

Beside the bowl are rocks of various sizes. Big ones the size of your fist, and little ones you’d need tweezers to pick up. These are all the things your company could choose to do. The big ones take up the most time and require the most resources, and the little ones take the least time. As a result, the big ones also tend to be the ones that generate the most significant impact on the company, and the little ones tend to generate the least impact. A big rock might be creating a new customer self-service portal, where customers can look up answers to questions about your products; a little pebble might be picking up the phone and answering a single customer’s question.

Decision-making frameworks like RAPID can be used to decide what’s a rock and what’s a pebble, giving every appropriate role in the company the right amount of input, and ensuring the decision sits with whomever will be ultimately accountable for the outcomes that the decision is meant to drive.

Prioritization becomes a process of deciding what to put into the bowl. You could just fill it with little pebbles. They’re easy, and they get you an “instant win.” They’re often the “low-hanging fruit” you hear people talking about. But they’re not going to make a definite long-term impact, even taken as a group. You could just focus on the big rocks that you know will create a significant long-term impact—but doing so will mean ignoring some of the little, day-to-day tasks. It goes without saying that you can’t do it all because the bowl is a fixed size. The trick is in deciding what mix to put into the bowl. And the big trick is realizing that there’s no objectively correct answer, and the biggest trick is realizing that you won’t know if you got it right until the bowl is full and you can look back.

This kind of prioritization is a struggle for all people, and all businesses, all of the time, always. You’ve always got more that you want to do, and not enough time/ money/ whatever to do it. You’ve always got people happy to second-guess your decisions, but you don’t know in advance if their decisions would have turned out any better in the end. Running a business is a compromise ; it involves making a lot of bets over the short, medium, and long term, and it’s often a long time before you see if those bets paid off or busted. Any time you’re thinking, “I don’t know why the business doesn’t just do X,” it’s because adding something to the bowl would necessitate taking something else out. And while X might be some wee little project that wouldn’t take any time at all, X might also be a pebble that won’t generate the kind of long-term impact that the company needs and wants. In the end, you might be right—doing X might have been smarter than whatever else was being done. But if you’re not the person with skin in the game (see chapter 15’s discussion on risk), then you’re not the one who gets to make bets with what goes into the company’s bowl.

17.2.2 OKRs

A related and sometimes complementary model is Objectives and Key Results (OKRs). An Objective is something you want to gain by performing some set of actions. Relating back to the rocks and pebbles analogy, an Objective is the reason you put the rock into the bowl. Objectives have to be observable, which means an objective person needs to be able to look at the situation and determine whether or not the Objective happened. “Increase Sales” is certainly an objective, and it’s something that can be measured and agreed upon. “Increase customer loyalty” might be an Objective, if and only if you have a plan for accurately measuring customer loyalty in the first place.

Key Results, or KRs, are the ways you tell whether you’ve achieved an Objective. “Customer Satisfaction Surveys Exceed 80% Completion with a Rating of 75% or Higher” is a good Key Result.

“Conduct Customer Satisfaction Surveys” is not a Key Result; it’s a task that you might undertake on the way to achieving a key result. “Conduct 100 Surveys” is also not a Key Result, or shouldn’t be, unless you’ve defined some “soft” Objective like “Learn More About What Our Customers Think of Us.”

I don’t like soft Objectives because they don’t move the business in any direction, and they aren’t tied to a meaningful business outcome. In most cases, I prefer Objectives that specify something the business’ customers would care about.

So let’s consider “Learn More About What Our Customers Think of Us.” Do customers care if our company learns more? Probably not. And just because we’ve learned more doesn’t imply that we’re doing anything with that new knowledge. Simply performing tasks doesn’t necessarily achieve something that will create a positive impact on the company. So how might we improve that? By asking why. Why do we want to learn more about what our customers think of us? Perhaps it’s because we want to increase customer retention. In that case, a better Objective would be, “Increase Customer Retention by [some useful measurement].” One means by which we might achieve that is better understanding what our customers think of us, and so we might establish a Key Result similar to “Survey [some meaningful number] Customers to Understand Why They Would or Would Not do Business With Us Again.”

Notably, that Objective will clearly create a positive impact on the business. That Key Result is a measurable step toward creating that impact.

Objectives are things that will measurably improve the business; Key Results are the measurable milestones along the way that let you know you’re headed in the right direction.

OKRs are something a company can set for itself, and it’s good when it can do so. But you can also do OKRs at a department level or even within small teams. Ideally, team OKRs will be connected to a department OKR that they support, which will be connected to a company OKR that it supports. The idea here is to get everyone doing the tasks that will help the company achieve its overall goals. Teams and departments will often have other OKRs that don’t directly address a company OKR, but are still relevant and worthwhile.

17.2.3 Priorities, priorities

Clearly I’m a fan of companies (and departments and teams) that use mechanisms like these to communicate top-level priorities to the whole company. However, I realize that not all companies do this. But there’s no reason you can’t ask. Ask how you, in whatever your position is, can understand on a day-to-day basis where the company, department, and team priorities lie. Ask how those are measured. Ask whomever makes sense, likely starting with your direct leader and working up the org chart as needed. Make it clear that you want to line up your own daily actions with whatever will have the best impact on those priorities. If you’ve got suggestions, lining them up against those priorities will be the best way to have them heard. “Hey—I know our priority is to get new customers to sign up faster. I had an idea about modifying our sign-up screens that would shave about 10 seconds off per customer. Where would be the right place to take that suggestion?”

17.3 Deciding what to drop: Opportunity cost

In our physics-based universe, almost nothing is limitless. Every resource we have is finite, and that means we have to make choices about how to use them. If you get two weeks of vacation from work, you have to decide what to do with those—much as you might want to take an 80-day trip around the world, you can’t, unless you’re willing to lose your job. Businesses work under the same constraints: to do something is to also not do some other thing. This is always true. I’ll sometimes get amused by employees who’ll make observations like, “Well, we could do this thing that I think should be done, and it’s not like it would cost more or take any extra time,” when those same employees are usually the ones also remarking on how overworked they are and how little time they have to do anything extra. Every endeavor will require some expenditure of resources, and that means those resources won’t be available for some other project.

Businesses usually discuss this decision-making process in terms of opportunity cost. If I do thing A, what will I miss out on? I’ve had to struggle with this question myself innumerable times in the various businesses I’ve owned or run over the years. Mind you, it’s a lot easier to wrap your head around this concept for a small-scale business because the numbers involved are both smaller and more readily available. For example, we once had an opportunity to do some extraordinarily exclusive and lucrative consulting work for a division of Microsoft. However, with our sharply limited resources, it meant basically dedicating the entire company to that work and nothing else for about a year. That dedication meant rapidly closing out our existing commitments, taking no new commitments for that period, and, more seriously, potentially damaging our pipeline for future work. By stepping away from our then-current line of business for that long period, we risked those customers throwing up their hands and finding someone else to do what we’d been doing, which means after the year-long gig was up, we’d potentially struggle for new work. The opportunity with Microsoft, in other words, came with a cost that we’d have to be willing to pay.

Number-crunching commenced. So, to use big, round numbers, let’s say the company was making $500k a year doing what we were doing. Let’s say we figured it’d be six months to re-ramp back to that after concluding the consulting gig, with revenue slowly coming back online during that ramp period. It means our “opportunity cost” was about $675,000, meaning the Microsoft gig needed to pay that much or it’d end up losing us money.

Opportunity cost happens everywhere, all the time in business because to do something always means to not do something else. It’s just a numeric way of looking at the rocks and pebbles analogy; if my bowl is only a certain size, and I need to decide which rocks to put in it, I need to look carefully at the value of those rocks. I need to select the rocks that will produce the most long-term value because the bowl is of a fixed capacity. With everything you do, you have to learn to ask yourself, “What value am a I creating in doing this, and what potential value am I forced to leave behind because I’m doing this, instead of something else?” Ask that for every project, every meeting, every initiative, at some point down to every task you take on and every moment of your day.

Now, look: if you’re not in a leadership role in your company, you might not get to make the decisions about what gets done and what, as a result, doesn’t get done. However, you should ask questions, and work to understand the decision-making process that went into those decisions. You should try to get as much context as possible around things like opportunity costs so that the business decisions are comprehensible to you.

Let’s take a moment to talk about that word comprehensible. I learned, as I was coming up through various companies and figuring out how businesses were run, that I needed to work to comprehend a company’s business decision before I formed an opinion on it. There’s a fine line between arrogance and confidence. Confidence is knowing what you know, and arrogance is not knowing what you don’t know but behaving as if you do. I don’t need to agree with business decisions until after I’m sure I fully comprehend the decision and where it came from. In fact, I tried very hard to assume that if I saw a decision I disagreed with, I was probably wrong, and I’d work as hard as possible to understand why. At the end of the day, there were still plenty of decisions I didn’t agree with. When those started to pile up at a given company, I started brushing up the résumé. But more often I found that given a decision I didn’t agree with, if I learned a bit more, I could understand and accept it. My acceptance might be tempered with thoughts like “Oh, OK. I mean, I wish there was another way, but I kind of get it.” But at least I understood why it came about.

Business decisions are often a matter of choosing the least-destructive option from a long-view perspective, and while you don’t always have to love the decisions, you can often at least respect the company’s intent behind the decisions.

Opportunity cost is one of the important pieces of context that go into business decisions. It’s far from the only one, of course, and different types of business have different concerns. The point here is that there are different bits of context, and you need to understand as many of them as possible if you hope to comprehend the decisions that your company makes. Work with your leader to not only gain that context, but to have them validate your correct understanding of the context you’ve gained.

17.4 Deciding what’s enough: Good, better, best

Back in the day, one of my responsibilities was for our company’s PBX—the phone system. Our system was relatively new, and it was well-equipped, but one particular area of challenge was the voicemail system. We had many salespeople who spent much time away from the office, and they saved every voicemail. Our system kept filling up. We’d run out of room for the entire company, and callers couldn’t leave voicemails. I should mention that this was before internet email was broadly available, so voicemail was crucial. My boss asked me to contact the vendor and work out an expansion so that the company could look at the budget. So I sat down and did the math. I’d already been going in every time the system hit “full” and manually clearing out older voicemails. So I had a good idea of how fast we were going through our storage and what it would take to hold about 30 days’ of voicemail companywide. We needed to roughly double our capacity.

Capacity expansions for that system came in “blocks,” and I could either add a “small block,” which would add about 20% or a “big block,” which would add about 400%. There was no middle ground. I ran up a quote for a big block and took it to my boss. This solution was, I reasoned, what we needed and then some; in my young, “engineering mindset,” I’d rather overbuild and not run into the problem again, right? It was a lot of money—close to a quarter-million if I remember correctly. Phone systems are expensive. My boss pointed out the massive expense and asked if there was anything else we could do, and I said—truthfully from my perspective—“No.” I mean, a small block wasn’t going to make any appreciable difference.

A few weeks later, I had another meeting with my boss, and she chastised me. She had called the phone system vendor and spoken to them in more detail, and they’d said that it was entirely possible to install multiple “small block” expansions and that we could get a roughly 80% increase—close to the doubling I’d been after—for much closer to $170k, a bit over half of what I’d been quoted. It turns out the “big block” also came with a bunch of other stuff we did not need, and involved some prerequisites we did not have, and both these contributed to making it so expensive. I learned two lessons.

Lesson one: ask more questions. I had made some assumptions that turned out to not be correct. For instance, I assumed that, for our very large company, $250,000 was not an insurmountable sum. The money meant nothing to me because I had no idea what the money meant to the company. I had no idea what else we might need money for. So I didn’t dig very deeply into the possible solutions. I didn’t take the time to really understand that “big block” option because I didn’t see the need to. It was just money, right? We had lots of money, right? I was perfectly happy to throw someone else’s money at a problem because I had no context for that much money, and what it meant for our company. Asking more questions helps you correct or validate your assumptions, learn more about the business, and make better recommendations and decisions. Ask your direct leader first, of course, but try to form relationships with other leaders in the company so that you can gain more context for different situations.

Lesson two: offer options. I also learned this lesson from a friend who works in Procurement at a large resort hotel. In Procurement, you try to reduce the number of things you’re buying so that you can get better deals by buying fewer types of things in greater quantities. There were several restaurants on the property, and each chef was very particular about their tools and supplies. Every chef specified different . . . well, everything, down to spatulas. With ten food outlets, he’d be buying ten different kinds of spatulas. So, when he took over, he put a stop to this. “I have three options,” he said. “There’s a good one, a better one, and the best one, in terms of price and quality. The low-end outlets like the buffet are assigned the good one, because it’s less expensive and perfectly adequate for their needs. Higher-end outlets can pick from the three choices, since we afford them a little more latitude on their expenses.”

In expanding the voicemail system, I should have researched it to the point where I could provide a good, better, best scenario. Then, in my meeting with my boss, I could say, “We can do this option for this much money, but it won’t meet our needs for very long. We can do a better option, and it’ll come closer, but it’ll cost a bit more. We can do the best option, which will set us up for life, but it’s going to cost a good bit more.” Then my boss could have evaluated those options and chosen one, asked me to dig into them more, or modified the criteria a bit and asked me to go back and reprice options that fit the new criteria..

By only offering one option, and settling on that option with essentially no business context, I was not helping my boss; I was compounding her problem. My “solution” didn’t fit with all the business criteria she was juggling but that I was unaware of. With a good, better, and best option, I could have provided her with some context, with a sense of the shape of the solution. “Here are three ways to tackle this, and the trade-offs between them,” I could have said. This is what we needed to inform the next round of more-precise questions that we could have used to drill down to an actual solution.

Now, to be fair, my boss could have helped me realize all that at the time. So in a way we were both wrong in different ways.

I’ve since learned to present good, better, best options along with a concise summary of the trade-offs, a recommendation about how I think we should proceed, and the assumptions that went into that recommendation. Those assumptions are essential because my boss can quickly scan them to see if there are any considerations I did not take into account and determine if I missed some parameter that might change the equation. By implicitly letting my boss see where I’m missing information, I create a better opportunity for my boss to fill me in on the missing pieces. This process educates me more about the company’s needs and priorities and helps me make better recommendations the next time around.

Business leaders are not always asking for solutions. Sometimes they’re asking for options, because they’re trying to inform themselves about the shape of a problem. They may ask from a particular perspective, or they may ask questions that don’t immediately seem relevant, but that’s because they know how they themselves process and learn from information. My boss and I need to be partners in the decision-making process. The boss is charged with a particular set of responsibilities and outcomes that I’m not entirely filled-in on because it’s not my job to know all those things at all times. So I need to provide a spectrum of options that give my boss a feel for the overall situation and the possible trade-offs between good, better, best. My boss, in turn, can help me better understand their concerns, their outcomes, and what they’re accountable for, which enables me to bring recommendations that are better aligned with those.

Very notably, I try not to “steer” my boss in one direction or another. If I believe I have a recommendation that is a best-fit for the situation, I’ll say so, and I’ll try to explain why I believe that. But I’m always cognizant that I might not have all the information. I may be missing context, or I may be unaware of some criteria that my boss knows. As my boss fills me in on additional context, I’ll revise my recommendations accordingly.

17.5 Deciding what to believe: Being data-driven

Human beings are unique on earth in our ability to believe. That is, we can accept and treat something as a fact even if there is absolutely no evidence for it, or even if there is evidence that contradicts what we’ve accepted as fact. This is different from merely holding an opinion or stating a theory; we behave as if the thing we believe is absolutely, irrefutably true, and are often resistant to a discussion about how our belief relates to any available physical evidence.

Your dog doesn’t get excited around dinner time because it believes you’re going to feed it; it gets excited because it’s operating from a pattern of past activity where you did in fact feed it. That’s not a guarantee that you’ll do so again, but a dog’s world is based on those past experiences, which definitely occurred.

A human, however, can believe, for example, that a particular politician committed a particular crime or other offense, with no experience or objective evidence to back it up, and can continue believing that even if an overwhelming amount of evidence refutes their belief. We want a thing to be true, and so we create a narrative for ourselves where it is true and then behave as if our narrative has been confirmed by objective, physical evidence.

This way of believing gets especially tricky in business. Good businesses do not operate from belief; they run from theory, and they confirm or refute theories based on facts. That is to say, good businesses are data-driven. So if you’d like to be taken seriously in such a business, you too will need to become a data-driven person.

I used to work for a division of the telephone company Bell Atlantic (it’s now part of Verizon), and at one point I was responsible for migrating us from our aging and overwhelmed Lotus cc:Mail messaging system to a new system. Much of the rest of Bell Atlantic was going with Lotus Notes, another IBM product and the “obvious” successor to cc:Mail. As a standalone division, however, we were free to make our own choice. So my team and I started collecting data. We had some specific criteria. We needed, for example, to be able to place a fixed maximum size for each user’s mailbox. Our research discovered that Notes didn’t provide that capability; you could set a maximum size on an entire mail database, but a database would typically contain many, many different mailboxes. One colleague said that his company’s workaround was to have one database per user, effectively giving them a per-mailbox size limit, but with the expense of vastly more complex system management, backups, and performance problems. We made a note of that, along with a variety of other facts about our business needs, Notes’ capabilities, and the capabilities of Microsoft Exchange Server, the primary competitor to Notes at the time. In the end, we expressed the opinion that, based on the data, Exchange was the better choice for our division’s business needs. This choice was not a belief of ours; we had collected objective facts that informed our recommendation. Some of my team were die-hard Notes enthusiasts; others loved Exchange. However, we agreed that the facts would be the primary driver of the decision.

Our recommendation was not popular with some of our superiors who believed Notes was just a better product. However, our division’s leadership was accustomed to making data-driven decisions. We brought up our fact-chart. We went through each business criterion and asked our superiors to confirm that we had each one correct and that each was still relevant to the discussion. We indicated how each product met, or didn’t meet, each criterion. They nodded, asked a few good questions, and accepted our recommendation because it was data-driven and the facts that drove our recommendation were valid, meaningful, and relevant.

I’ll point out that we took some pain to ensure our facts were free of any bias that couldn’t be supported by more facts. While facts themselves are, by definition, true, the way you present those facts can indeed impart bias and create, if not a false impression, then at least a steered impression. We tried to avoid that because when someone catches you trying to “spin” a fact, they start to call the rest of your facts into question, and the whole process impugns your credibility. Neither Notes nor Exchange came off as perfect in our analysis; both had problems that we’d need to work around. We tried to provide context for those workarounds, to categorize their difficulty and long-term impact, their costs, and so on, and we tried to be very clear about where we departed from objective fact and entered a world of estimates and guesses. We were, to sum up the entire process and attitude in a single word, scientific.

Many people have difficulty pulling themselves away from what they want to be true and operating instead in a purely data-driven fashion.

For example, I have one friend who believes that Android phones are superior in every way to iPhones. That’s an opinion, and he’s certainly welcome to it, but there are no facts that support either platform being objectively better than the other. Instead, he will take pieces of information—not data per se—and “spin” those to support his opinion: Android is more open, he’ll say, which means it is inherently more secure. Android is less expensive, he’ll say, which means more people will buy them which will make them part of a larger and therefore more robust ecosystem. He is an extremely vexing person to be around when he starts on that path, and you wonder exactly what kind of financial incentives, and from whom, he’s under to be such a die-hard proponent. Belief is his problem. For most humans, it is not enough to believe something on your own; you must also win others to your belief— as if belief was a kind of democracy where the largest crowd of believers “wins” and gets to have their beliefs magically become proven fact.

Try not to be that person at work.

People also mistake correlation with fact. “IBM servers,” a former colleague once told me, “are far less stable. I can prove it because we have to reboot them 3-4 times as often as our Dell servers.” I pointed out that the IBM servers were only used to run a particular application that was known to be poorly written, and that it could very well be the application, not the server hardware, that necessitated the frequent reboots. The fact that the crashes happened on IBM hardware was a correlation—two distinct things that happened at the same time—rather than a causation, where the one thing (being an IBM server) automatically led to the other (frequent reboots). By his logic, we could state that tomatoes are toxic to humans because every human who has ever eaten a tomato is either dead or will be dead at some point. There’s a correlation—people do eat tomatoes, and people do indeed die—but the two are not causally connected. This argument got to be such a stalemate that I installed the poorly-written application on a Dell server, which wound up needing to be rebooted just as often, and removed it from an IBM server, which suddenly didn’t need to be rebooted as much. Because my colleague so committed to his belief, however, his response was that I’d messed up the servers somehow—the evidence itself didn’t sway him.

Try not to be that person at work, either.

Here’s the thing: for millennia, humans haven’t had data. Sure, we had experience, but experiences can be subjective, and they’re not always universally shared. So learning came, in large part, from instinct and perceived, as well as actual, cause-and-effect relationships. So even in today’s modern, always-connected world, it’s still easy just to observe and then go with your gut. That’s a terrible way to become a better businessperson.

I can already hear the objections, so let’s be clear: observing and going with your gut is a great way to form a theory about something. “Hey, I see this happening and I think this is what I should do about it.” Fine. But then gather data. Gathering data is rarely fun (unless it’s something you’re personally into), and it’s not always easy (which is why data engineering is such a “thing” in businesses these days). However, it’s what you need to do to make a sound decision. Dig into the data around that thing you see happening—do you see something whole and real or just the edge of something or something completely imaginary? Let the data show you how, your gut-instinct solution will help—or how it won’t help. So if you decide to go ahead with your solution, measure more data. Consider yourself a scientist: “I think this is what’s happening, and I have some data to validate it, so I’m going to try an experiment. I’ll measure that experiment, and decide if I made a positive change or not.” Be that person at work.

17.6 Deciding together: How to negotiate

Negotiation is a hugely important part of any relationship, and the many relationships of the business world are no exception. For example, negotiation comes into play whenever you are involved in

• Figuring out what your team can do and what they’ll need to drop

• Getting hired or promoted and discussing your compensation package

• Resolving an interpersonal or interteam conflict

Negotiation is a way of making decisions together. Even if you’re using a decision-making framework like RAPID (which I discussed in the first part of this chapter), negotiating is often one of the first things that happens. The various people in the Agree role are all supposed to agree on the recommendation (or recommendations) that are being put forward; that almost always involves some negotiation between them. “Yes, my team can commit to that—but only if your team can commit to picking up this other responsibility we currently have.” The final recommendation, which is sent to the ultimate decision-maker, normally includes all of those negotiated trade-offs, so the responsible business leader can make a decision.

Negotiating can get tense and nerve-wracking sometimes, because it can get so personal: I don’t want to give up whatever it is you’re asking for, and you don’t understand why that’s so important to me! I’ve created a kind of checklist for myself, to help me navigate negotiation. My list might not be appropriate for the type of salesperson-customer negotiations that you normally think of when you see the word “negotiate,” but I’ve found it useful for internal negotiations where we’re all basically on the same team:

• Have I been clear about my priorities, what lines I don’t feel I can cross, and why I feel that way? In other words, am I sharing context with my fellow negotiators, so they know I’m not simply being obstinate? This is an opportunity to validate my priorities and “lines not to be crossed” as well, to make sure they’re still supporting the organization’s overall outcomes.

• Is everyone putting something on the table? In a healthy negotiation, you should get something for every thing you give. That’s not intended to mean that negotiation is a zero-sum game and everyone has to both win and lose; it’s a recognition that it’s only a negotiation if everyone is putting something on the table. If I’m the only one being expected to “give,” then it’s railroading, not negotiating. Sometimes that’s how the business has to operate, which is fine; I just want that fact on the table up front so I know what’s happening.

• Have I taken the time to understand the contexts of my fellow negotiators? Do I understand why they’re asking for things, and how those things relate to the organization’s top-level outcomes? It might be a situation where they’re right in asking my team and I to do something, in which case the “negotiation” is just us figuring out what might need to be dropped in order to make it happen.

I’ll offer a personal example: I once worked for a startup that was having trouble securing its next round of funding, and was burning through cash too quickly. I was a senior leader, and was being paid a considerable salary. They came to me and asked me to take a salary cut. Obviously, that didn’t thrill me, but I understood why they were asking: it was in part to ensure they could continue to pay other people too, and I wasn’t the only one being asked. I decided to negotiate. I asked if, in lieu of my full salary, I could be granted additional equity in the company that vested monthly. In other words, I asked if I could be paid partly in cash, and partly in company stock. It demonstrated my belief that the company would eventually succeed (or the stock would have been worthless), my willingness to contribute to the greater good, and my understanding of the situation. But I added another request: I wanted twice the value in stock as the salary I was giving up. That put the company on notice that I wasn’t going to be the only one making a sacrifice in the situation—I was giving something up, and they would have to as well. After some discussion, we agreed.

Negotiation can be a healthy part of any business. Most businesses try to create intentional “points of tension” within the org chart, with different stakeholders—like Finance or Legal—representing different perspectives. There are deliberate “tensions” between them. For example, Finance might ideally prefer to spend no money at all, while Marketing might want to spend everything! They come together and negotiate, and between them come up with solutions that best represent the competing concerns that any business has to have. When that negotiating can be done professionally and respectfully, and with an eye toward the shared outcomes of the entire organization, then it’s a great way to mutually create the right decisions.

17.7 Further reading

• Bain’s RAPID framework, http://mng.bz/aKgz

• Decision Quality: Value Creation from Better Business Decisions, Carl Spetzler et al. (Wiley, 2016)

• Measure What Matters: How Google, Bono, and the Gates Foundation Rock the World with OKRs, John Doerr (Portfolio, 2018)

• Start Less, Finish More: Building Strategic Agility with Objectives and Key Results, Dan Montgomery (Agile Strategies Press, 2018)

• Business Analytics: The Science of Data-Driven Decision Making, U. Kumar (Wiley, 2017)

17.8 Action items

For this chapter, consider some of the decision-making that happens in your own organization. If you don’t know the answer to these, find out! Start with your own manager, and work together until you both know the answers:

• Does your company use a decision-making framework like RAPID? If not, is there value in considering such a framework for the commonly made decisions on your team?

• How does your company communicate priorities? When upper management communicates priorities, do the successively lower levels of management “translate” those into more-specific actions for their teams?

• How does your team or company deal with evaluating opportunity cost? That is, if an opportunity comes along that would require dropping something else, how are the tradeoffs evaluated and how is a final decision made?

• What data sources does your team or company use to make decisions? Where does the source data come from, and how is that data made available to decision-makers?