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.

Efficiency is doing things right; effectiveness is doing the right things.

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.

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”?

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.

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.