When the game is rigged

I’ve been thinking a lot about Victoria Brouhard’s recent blog post on “no-brainer” decisions. It’s a clever idea. When you’re trying to decide about accepting something like a job offer, ask yourself, “What would it take for me to say hell yeah?”

In other words, how would you change the offer–if you had the power–so it becomes something you couldn’t imagine rejecting?

Key insight

Brouhard’s corollary to this concept is: if you can’t find a way to make it a “hell yeah!” then the answer is definitely no, and you can feel good about it.

It doesn’t just apply to jobs. The “no-brainer” technique (and by the way, it’s short, and I do urge you to read it all the way through) would have been awesome for me in terms of selecting a college, capital-R Relationships, finding a place to live, even deciding what to have for dinner.

Oh dear. Definitely the Relationship thing. Ouch.

On a larger scale, national leaders could have used it in 2002 and 2003 to, you know, decide not to invade Iraq. Because honestly, what would the best possible outcome have been? You’re looking at it on Google News right now in another browser tab.

Here’s what’s cool though

Brouhard’s No Brainer is the same as Schumann’s Guaranteed Fail. If you have my signature article, “Don’t Do That! A contrarian guide to fixing software projects that suck,” and you should, then you know about #8 on the list of eight reasons why software projects suck. If scope and specifications are vague, the project sucks because there is no way for it to not suck. (Yes, that’s an opt-in link. Hope you don’t mind.)

Suppose you apply the Brouhard Formula:

Make a list of all the things you would need to have (or not have) in order for the project to become worthy of Yays and Hoorays.

You would find that list impossible to fulfill, or even to imagine. And that is the point. When you don’t have a clear goal, or you lack a solid justification for that goal, it doesn’t matter how many developers you put on task or how much you manipulate the project plan. It’s not gonna work, because there’s no such thing.

Basically, the game is rigged.

I used to know this cop who liked to say that when you’re playing cards, and you’re losing over and over again, don’t keep playing. Knock the table over and stop the game, because it’s obviously rigged. (Yeah, he liked to wear cowboy hats too, why do you ask?)

This is the equivalent of knocking the table over.

So.

The next time you’re starting a software project, or even if you feel a need to re-evaluate the one you already have, take a few minutes. List all the things that, if you could magically make them happen, would make this software project so awesome you would totally work for free on it. Or at least so awesome you wouldn’t feel annoyed and resentful over it.

If you can’t even imagine such a list, it’s time to kill the project. Or if you’re not in charge and cannot successfully communicate this to the business leadership, it’s time to find another project to work on.

If you can imagine that list, consider that the core of your agenda for things to consider changing about the project.