Monday, July 18, 2011

"Make Me"

Adam Goucher said this on Twitter today: "how to fail at anything 'my boss is making me use java for this'. equally true for any language w/ 'making me'. (just more so with java)"

Now, I'm not going to say anything about Java; that's not today's point. Bash it or love it, it really doesn't matter to me.

But Adam's right about "My boss is making me use..." being a huge red flag. This person - whoever it is - will almost certainly fail at whatever task he's being asked to accomplish.


Because he's already decided to fail. You can tell because he said, "making me". When we say, "making me", it means several things:
  1. a decision has been made
  2. we didn't agree with it
  3. we're angry about it
This is a classic setup that almost always leads to "proving" that the decision maker "got it wrong" by failing.

Let's take a step back and look at this from two directions. First, let's talk about how technical decisions get made. Second, let's look at how we can help ensure people don't want to undermine those decisions - how we can avoid the "make me" moment.

Making technical decisions generally goes something like this:
  • Identify that there is a decision to be made
  • Identify (some of) the possibilities
  • (Maybe) do research to ensure the feasibility of those possibilities
  • Identify a decision maker
  • (Maybe) consider the pros and cons of each choice
  • Make a decision
In some cases, this can take seconds and be done by one person. For example, choosing whether to use a for loop or a while loop is a technical decision that is usually made by one person alone, and that's completely fine. In other cases, this is a huge decision made by a large team of people. What technology stack to use for a new platform is an example. Another example is the creation of a design that will be the heart of a next generation product. These decisions take a lot longer (days, weeks, months, even), and frequently involve research, prototyping, etc.

With these large decisions, the human factor becomes very important. After all, none of us is actually psychic, so we're all just guessing. Some of us are just better guessers than others due to experience, research, or simple skill. Similarly, there often isn't one clear winner. It's perfectly acceptable, for example, to write a web application in Ruby on Rails, Java, or .NET. Any of those are great technologies with various pros and cons, and any one of them might be right for this particular project. It's a decision that will be made on human factors and circumstances, rather than on technical feasibility. These are the decisions that are more likely to lead to the "make me" moment.

So now we know we're at risk of the "make me" moment. We're at a point where someone may decide they don't like the decision and decide that it's going to fail, consciously or not. (By the way, someone who has decided this won't work is a lot more likely to fail than someone who thinks it will work!) We need to head off that problem before it starts. And once again, it's the human side of things rather than the technology decision itself that will determine this. So, how do we make sure that the recipients of a technical decision are at least willing to give it a chance?

Try these:
  • Identify a decision maker before starting the process. This helps reduce surprise at the point of decision. It also tells the team who they have to convince about their views, and this is actually helpful since at least they know their voice was heard by the right people.
  • Make sure the decision maker has the technical prowess to make a decision intelligently. Being handed a decision by someone that the technical team respects makes a big difference in how likely they are to accept it. For many engineers, this means that the decision maker needs to be an architect or engineer, not a product manager or the like.
  • Give the team a voice. Let team members who care about the decision describe what they would choose and why. They probably have some good insights, and can at least make sure that the decision maker is addressing the relevant concerns, no matter what the decision ends up being.
  • Explain the decision. Describing why a decision went the way it did makes it look less arbitrary, and helps cut off a lot of dissent.
  • Provide a feedback loop. Sometimes a decision really does turn out to be wrong. You need the freedom to unmake the decision if it's ultimately harmful, and the earliest way to know that is to listen to the feedback from the people most involved with the effects of the decision. Provide explicit feedback mechanisms and timelines, and use those to rethink the decision if it's going unexpectedly poorly.
Making decisions is hard, and when the decision isn't clear there will frequently be someone who is angry about it. Understand and defuse the anger, and avoid the "make me" moment. You'll increase your chances of success.

No comments:

Post a Comment