Note: I wrote this as a section of an unfinished book about managing software engineers, "Managing the Unmanageables", when you are not a software engineer. I keep copying it and pasting it to people so I thought it should just live here.

Applying Psychology: The Power of Why

One of the powerful tools in your arsenal of management techniques for dealing with software engineers is three letters long — why. As a manager, even as a non technical person managing technical people, you always have the ability to ask why. I would argue that if you don’t ask why, at least some of the time, you’re not doing your job. Understanding “why” is, after all, at the heart of management. The power of why taps into four of these psychological vectors: pride in his work, poor social skills, the desire to not explain his or her self and the belief that they are smarter than you. So let’s posit a dialog between you and a software engineer:

Manager: Bob — we need to get that download bug fixed today. Its a big deal. Bob: Well that’s actually pretty hard. I’d need to nerd level gobbledygook gook speak here

A lot of times that’s where the dialog ends. The software engineer throws up a wall and relies on you not understanding this. Now let’s revisit that and add why to the mix:

Manager: Bob — we need to get that download bug fixed today. Its a big deal. Bob: Well that’s actually pretty hard. I’d need to nerd level gobbledygook gook speak here Manager: That’s interesting and I don’t understand everything you just said but I do know that our product used to be able to download data and now it can’t. Can you explain why?

And this is the point where Bob either has to explain himself as a human being or do the work. And, honestly, he’d rather do the work than talk to you. Don’t take offense at this. It is actually both what you and and to you advantage so its a good thing. Bear in mind that Bob would rather talk to a computer than talk to you. If he really wanted to talk to people, he’d have your job. Finally if he really is smarter than you, or at least things he is, shouldn’t he be able to fix it?

One thing to know about technical people — we hide behind our jargon because it gives a way to make difficult social interactions go away. If I use words that you don’t understand then it naturally intimidates you because it makes you feel stupid and me feel superior.

The power of why is a very real thing. I cannot tell you the number of times that simply asking “why” has resulted in the engineer saying “Fine! I’ll just fix it”.

The other thing to understand about the power of why is that software can be intimidating as hell even to the engineer who is working on it. By forcing them to explain themselves, in a way that you can understand, you are inherently forcing them to work thru the issue at hand in their own head. And, very often, you force them to realize where they went wrong. Let me illustrate this with an anecdote.

Once upon a time there was a software company that was making CD-ROM indexing software and an indexing operation just would not finish. Finally I dragged the engineer in question over and made him watch how astonishingly, mind numbingly slow it was. The very next day a 24 + hour process executed in 8 minutes. What changed? To this day I do not know. All he said was “I was stupid[1]”.

This second example tapped into the engineer’s belief that his code was “fast”. By confronting him with the real world where his code was not fast, I forced him to either admit that his code was slow (which conflicted with his pride) or just fix it or, worse, explain himself. And the normal thing happened — he fixed his code. And, just so you know, the engineer was not me. I was the lowly user in this case.

[1] This actually operated on several emotional vectors — the desire to not have to explain himself coupled with pride in performance (every engineer thinks his or her code is fast).