I’ve been channeling my inner two-year-old recently and thinking a lot about the word “no.” It's not a word that's usually valued in (American) corporate culture. I doubt that Getting to No would have become a business best-seller. We learn early on that “yes” is positive and “no” is negative. “Can do” is going to get you further then “I can’t.” These are principles buried deep into our collective psyche. And yet “no” is a word we should embrace more.
As software builders, we're always riding a storm surge powered by two powerful and synergistic forces—the desire to build, and the desire to meet our customer’s needs. Face it, at the core of any great development team is an obsession with building stuff. With teasing a problem apart and crafting and ultimately building a solution. Doing so feeds into our basic human desire to get things done. To be able to say, “I built that” and “look what I did today.” And what better justification then a customer’s need?
These two forces together make an almost unstoppable momentum towards building. Towards building more features, towards building more complexity. How often have we heard (or said!) “could we add just this one little thing?” True confessions: I said exactly that last week. The result so often is that we go ahead and do the thing because, well, we want to build and we want to make our customers happy. The cycle feeds itself.
It is much, much easier to say yes then it is to say no. Not just because there might be pressure from our colleagues, or our bosses, or even our customers, but also because yes feels good (kpop tangent). There is a kind of existential reassurance in adding that new feature, or in fixing that bug.
Some examples. Which of these have you heard this week?
It's just a small tweak — let’s cost it and decide.
This is one of the most insidious of scenarios, rife with potential for bad decision making. The simple act of costing is work, usually requiring a developer or dev lead to come off task and do the costing work, which itself distracts the team. Then, once that analysis is done, it's especially hard to say no to the feature because there has been investment in it. In behavioral economics terms, this is called “sunk cost bias.” Once you put in any work, it's hard to not move forward with the rest. On top of this issue, a quick estimate is likely to be of low quality and planning fallacy means the lousy estimate will be low. You've also set up one of the least important factors (cost of the feature) as perhaps the most important determinant. To summarize – engaging in the costing process makes it more likely that you'll interrupt your schedule to do the feature, that the estimate will be low, and that you’ll end up scrambling around a blown schedule. I guarantee the ROI of all this will be low.
We won’t get that customer if we don’t build this feature now.
Sometimes you just have no choice, right? You’ve got a customer or potential customer that's demanding a feature. Maybe your cashflow is tight and you need the revenue – and the customer is demanding the feature (or worse, custom work! But that's another article in itself). I submit that there is always a choice—and I've found that in the vast majority of cases the customer could have been won without the feature, or the customer is lost even though we built the feature they asked for. Most of the time it turns out that the feature is being built on spec, rather then as a contractual obligation. This scenario is a fabulous time to practice saying no. As a side-note, one of the main issues here is not the building of the feature, it’s the building of it now. So a great strategy is to set the customer’s expectation that it won't be done now, but be added to the roadmap for a more appropriate time. Most customers will appreciate this professional give and take.
Yeah, the feature is small now, but we need to design for what it will eventually be.
This one usually comes from your dev team, and it should be an automatic red flag. I’m not saying that you should never build for scale, but especially in a start-up context, building for the now feature as opposed to the future feature is the right way to go. Why? The most important reason is because we don't have perfect vision of the future. Who really knows if that feature will need to scale? We expect that our feature or product will take the market by storm (yep, there's a term for this, “optimism bias”), but we don't actually know. We think that it might, we hope it will, but in point of fact, we're usually wrong. Sorry, but it’s the truth. So why invest the resources in possibilities? It’s really hard to argue with the scale rationale, but it stems once again from optimism bias...and the sunk-cost fallacy will make it that much harder to pivot in the future. Just say no.
So, What Have We Learned?
These examples are just a few opportunities to say no. I've been focused on software development, but as they rely on pretty fundamental human behaviors, the premise of this essay is applicable to pretty much any human endeavor.
Remember: saying yes often leads to:
- Distracting the team
- Blowing a schedule
- Bloating the product
- Causing regressions
- Creating complexity
So work on No.
Don’t get me wrong. Agile is good. Flexible is great. All plans were meant to be changed. But, it’s cricital to pay attention to the proportion of times that yes beats no.
Steve Jobs is supposed to have said “a thousand no’s for every yes,” which is certainly hyperbole, but makes the point.
Exercise The No Muscle
As a mental exercise, try this:
For a week, be mindful of your decisions, and try to think of a “yes” as negative (visualize thunderstorms and earthquakes) and a “no” as positive (lollipops and sunbeams). Every time you are asked a yes/no question, try to think of it in this context and you’ll be amazed at the change in how you think about decisions.
It takes guts to say no. But keep in mind this 900-year old Hindu expression:
First a man must learn to say “no,” only then does his “yes” have meaning.
You too can channel your inner two-year-old. Why not start now?