I’ve mentioned this idea in several conversations recently, so I figured it was time to blog about it. In particular, I’ve been telling people about my career and how it’s much easier to be right than it is to make the right thing happen. So, like any good wanna-be management consultant, I came up with a two-by-two matrix to illustrate the possibilities.
In case it’s difficult to read, the horizontal axis goes from Wrong to Right, and the vertical axis goes from Ineffective to Effective. I’ve labelled each of the quadrants with an appropriate name.
- Wrong and Ineffective: Fools are wrong about what needs to get done, but fortunately, they are also ineffective so at least they’re not moving the organization in that wrong direction. They’re annoying to have around as they waste other people’s time, but are more obstacles than active hindrances.
- Wrong and Effective: Players are effective at getting what they want even when it’s the wrong things. They’re the ones that play the political game successfully and get resources for their projects despite the project being a waste of time. These kill the motivation of others in the organization, as Players get rewarded for doing the wrong thing.
- Right and Ineffective: Martyrs like to say “I told you so”, as they have a sense of what the right thing to do is, but are completely ineffective at actually convincing others in the organization to do that right thing.
- Right and Effective: Leaders are clearly what you want – people who both can figure out what the right thing to do is, and can also mobilize others to their point of view and create action within the organization. Hard to find these people, of course.
Most engineers end up in the Martyr quadrant, as they have the powers of analysis to figure out the way things should work. But they don’t necessarily have the people skills and observational skills to understand how decisions get made within the organization. So they complain vociferously when decisions get made that they don’t understand, but are singularly ineffective at changing the decisions. I spent several years as a Martyr at a couple different organizations, so I’m very familiar with the feeling.
The engineers are living along one dimension in this space – they see Right and Wrong, and see that they are more Right than the Player, so they can’t understand why the wrong decisions keep on getting made. That’s why I think it’s helpful to introduce this second axis of Effective and Ineffective, to illustrate the axis on which they are failing. I’m still learning to be more effective within an organization (it’s a slow process), but just being aware of my failings is a good first step.
Of course, “Right” can also be optimized along multiple dimensions, and which dimension you choose to optimize on changes the decision as well. Engineers prefer to optimize for the correct technical solution (scalable, clean design, etc.) while marketers might choose to optimize for what the customer wants, sales people commissions, and executives revenue or profit. But that makes my two-by-two matrix too complicated.
Anyway, I have found this distinction of Right/Wrong from Effective/Ineffective to be a useful conversational prop recently, so I figured I would share it in case it’s helpful to others.
I use the same words for similar purposes. A hard thing for Martyrs to accept is that moving upward on the Effective axis may only be possible if you move leftward on the Right axis.
Is it possible to be “right”? Surely it’s a matter of viewpoint?
Similarly, effectiveness is presumably contextual too: effective with respect to a goal agreed by a number of people. Effectiveness in process improvement, for example, may result in a local minimum that’s ineffective when viewed from the POV of the larger organisation.
I also suspect that time plays a part. Something that seems “wrong” now may be viewed by history in a more favourable light. And vice versa.
You seem to be saying that what the martyred engineer is missing is simple awareness of the effectiveness dimension, which I think is inaccurate. I think a lot of the time people in that position are fully aware that they have no leverage, which only exacerbates their frustration with bad organizational decision-making.
Sharing information is not an effective solution to this problem. Telling those people “Hey, you’re right, just ineffective!” is not going to improve their situation, it’s just going to piss them off…
Brian, great point that to get something implemented often involves compromise, which is an evil word to a Martyr.
Kevin, yes, this is definitely a simplification, and both “right” and “effective” are fuzzy terms. But I still find the distinction useful.
Beemer, I disagree that people have “no leverage”. That’s what I mean by “effective” – everybody in an organization can have leverage if they figure out how leverage works in that organization – who the decision-makers are and how they make decisions. Engineers in particular do get frustrated with bad decision-making, and say “It’s all politics” and refuse to play that game, and then stew in their corner muttering about stupidity. Or they go around telling decision-makers, “You’re stupid because X is clearly the right thing to do”, and then are surprised that the decision-makers don’t choose X. Or at least that was how I used to react.
The thing I’ve learned over time is that there’s always a way to influence the decision makers, but you have to learn to present information to those decision makers in the form that they prefer, and create a compelling story for them using terms they understand. So, for me at least, being told that I was right, but not being persuasive or effective in conveying my point, got me to start thinking about what I needed to be more effective and influential. As I said, I’m still working on it, but just recognizing that being right isn’t enough was a huge step for me.
Interesting view… I definitely see those same distinctions a lot with the people I have interacted with.
One aspect of it that I think comes into play is how much responsibility someone is willing to bear for their decisions, which is the most common form of self-unempowerment I see along the “effective” axis. It’s scary to have to make decisions, and much easier to throw rocks at the people making decisions. Particularly when often no decision is unambiguously correct (and had you taken the other path, the people complaining about the downsides of choice X would be complaining about the downsides of choice Y instead). So people specifically put themselves in the Martyr category.
Of course sometimes that’s not even conscious I think, but rather happens through sins of omission. Understanding why decisions happen outside of narrow technical interpretations of the problem is a very common source of self-limiting on the effectiveness axis too, I think. Programmers commonly underestimate the risk of rewriting systems, for example, or in general people don’t understand external dependencies.
Sometimes it’s amazing to me that we get anything done at all. 🙂 In all the big software projects I’ve seen, very rarely was technology actually the limiting factor, it’s almost always communication and teamwork issues.
I like your graph! I’m a huge fan of graphing everything, myself, so I definitely appreciate when other people communicate in Cartesian. 🙂
I would, perhaps, suggest another word instead of “player” in that upper left quadrant, as I think it’s giving the idea of play, with it’s curiosity, exploration, and humor, a less than positive name. Also, Fred Kofman of MIT/Sloan School fame, actually uses the term “player” as describing the best kind of leader, someone who’s actively participating in the game, as opposed to someone who is simply watching from the sidelines.
I’m not sure what the best word might be, though. “Amature” perhaps? “Novice”?
Oh, and I notice that your map here is essentially the same as my own map for plotting the positive/negative possibilities for “physical” (your effectiveness) and “intellectual” (your rightness). If you add in the third major human arena for motivations, emotional (your joyfulness!), you’ll have an even more complete, if less easily conveyed in two dimensions, map of human potential.
It’s much easier to be “effective” when you aren’t constrained by reality, for the same reason that it’s much easier to convince people to eat ice cream than a salad.
The reason that engineers aren’t “effective” is because they are constrained by the ugly reality of actually having to deliver products that work. This takes time, money, and smart people.
Management doesn’t want to hear that.
Management would rather listen to the “effective” managers and marketing guys who promise them a unicorn that craps rainbows by fiscal Q3, and then blame the engineers for not delivering it.
Brilliant – bookmark and borrow!
This reminds me of Drucker’s quote:
Efficiency is doing things right; effectiveness is doing the right things.
Xemu: Great point about taking responsibility for decisions. I definitely was one of those throwing rocks for several years, but have come to appreciate how difficult and ambiguous many decisions are. And often times, a decision that seems wrong technically is right for another reason, so understanding the criteria by which a decision is made is important to judging its “rightness”.
Also, totally agree that technology is rarely the limiting factor – it’s almost always a communication/teamwork/management issue, which is one of the reasons I’m so interested in that stuff now. Even the one project I was on that failed because it was literally physically impossible (we would have had to maintain temperature stability to a millionth of a degree), we should have recognized much earlier it was hopeless and fallen back to plan B which eventually turned out to be successful.
Turil: Yeah, I wasn’t happy with “Player” either – I meant it in the connotation of a “player” in the realm of women, a jerk who uses techniques to get what he wants without a thought of who he’s hurting in the process. But if I did another version, I’d probably choose a different word.
John: I’m sorry that you’ve had bad management that doesn’t take real world delivery into account when making decisions. I think that, in general, engineers have a credibility gap with management because we consistently blow our deadlines or deliver something that isn’t what they had led themselves to believe they were getting (the “unicorn”). Partially that’s because management pushes back on deadlines that are actually realistic and include testing and integration time. But in my own experience, I’ve started to learn that it’s also partially my responsibility to take the time to explain to management (repeatedly, using short words) what they’re going to get, and how cutting the schedule will impact what they get. It may not make a difference on this project, but over time, I believe it makes a difference in building the trust that when I say I can’t do something in a given timeframe, I mean it.