Roscoe Explains His Theory

"Well, it's like this. We could start out by saying that software engineers just want to be treated like professionals. They not only want respect, just like all human beings, but, like doctors and other professionals, they expect it. If you think of them as 'just programmers' or 'hackers,' you will get their backs up. So your 'going in' attitude is important."

"Heck," I offered, "sounds like you're talking about a bunch of prima donnas."

"Not really," he said, which surprised me. "You have to understand that software engineering is the newest engineering discipline on the block. Everyone knows what mechanical, civil, electrical, and chemical engineers do, and aeronautical engineers even get called 'rocket scientists' now and then. But not many people know what a software engineer actually does. Problem is, software guys often feel like the Rodney Dangerfields of engineering.^[3] So I cut them some slack."

^[3] For our overseas friends, Rodney Dangerfield was an American comedian whose tagline was the ungrammatical "I don't get no respect!"

"OK," I said, "spare me the psychobabble about their inferiority complex. Some of them seem pretty arrogant to me at times."

"Well, do you want to communicate, or don't you?"

I swallowed hard.^[4] It was time to listen some more.

^[4] It reminded me of my mother-in-law's response when I criticized her for putting sugar in the peas: "Do you want the kids to eat them or not?"

I wondered, by the way, about Roscoe's classification of software developers as "engineers." There are many in the software development industry who feel as though we're a long way from becoming a true engineering discipline. But I decided to let sleeping dogs lie. Regardless of the label we use, managers still have to talk with the folks who design and write our software. And I knew that when I wanted Roscoe's opinion on the subject, he'd give it to me. Heck, when he wanted my opinion, he gave that to me, too!

The Four Steps

"Actually, there is a simple, four-step method for conversing with software engineers. Sort of like the Texas Two-Step, applied twice."

Roscoe was getting warmed up. He took a few puffs on his cigar and refilled his coffee cup.

"If you follow these four steps, you'll most of the time come out of it with a whole skin. If you make assumptions and try to skip over some steps, you will get all wrapped around the axle. So listen carefully."

Step Number One

"Now the first thing to remember is that you are dealing with an engineer. Engineers don't usually like to make small talk; they consider it a waste of their time. And boy, do they consider their time to be valuable. So, first off, they want to know what the problem is."

"You mean," I said, "that every conversation has to revolve around a problem? What if you are coming to the engineer with an opportunity?"

"Ah yes, challenges and opportunities, as you managers always call them. Well, call it an issue if it makes you feel any better. The fact is, engineers are problem-solvers, and they naturally assume that if you come to them, you have a problem that needs to be solved. So I usually start out by simply stating that I think there is a problem that I'd like to talk about, and then I simply state the problem."

I could see that setting up this kind of baseline for a discussion would be a good thing. Rather than beating around the bush, just come out and say why you are there. So I nodded to Roscoe to go on.

"Now sometimes you will get a grunt, and then a quick explanation of why your problem is not a problem. Sometimes you'll discover you were misinformed. Sometimes you'll find out that you didn't state the problem correctly. It's OK to be persistent. Clarifying what the problem is, or isn't, will actually get you some respect from the engineer. Just remember that what the engineer is doing is qualifying you and your problem. Because he doesn't want to spend even one second on a problem he sees as unnecessary or unworthy. If you disagree, you'd better hash it out, because until he is convinced there's a problem, you're not gonna get anywhere."

I recalled several discussions I'd had where I jumped ahead prematurely. Sure enough, we always had to backtrack until we agreed on what the problem was. Engineers sure are funny that way.

Step Number Two

"Well, now that you have agreed that there is a problem, you need to establish ownership," Leroy continued.

Ownership? Roscoe was clearly getting comfortable with business lingo.

"You see, it comes down to this. If it's your problem, then what are you doing here? Seeking advice and counsel? That's OK. If you are implying that it is his (or her) problem, then he or she might actually have to do some work. So before an engineer will go further into the discussion, he wants to know: Whose problem is it?"

"There is another possibility," I said. "It could be neither my problem nor his problem, but a problem for some third party."

"Yeah, that's possible. In that case, you can bet the engineer will ask you something like, 'Well, why are you coming to me with it, if it's not your problem or my problem? Let him (the third party) worry about it.' So you have to explain to him why it has an effect on him. Otherwise, he'll treat the problem as either uninteresting or unworthy of his time."

I was starting to see that this was a little more complicated than I thought.

"Now, if it's your problem, the best you can hope for is some thoughtful analysis, maybe a recommendationand then it's time to get out of Dodge.^[5] An engineer is loath to spend too much of his time on your problem. That's just the way they are.

^[5] Once again for our overseas friends, Dodge City was a town in the Old West that was known for violence and "frontier justice." It was generally considered to be a rather unhealthy place for the uninitiated. Hence the instruction to "Get out of Dodge" came to mean "Don't hang around too long in a dangerous place."

"On the other hand, if you think it is his problem, then you have some selling to do. Once an engineer accepts responsibility for a problem, he will act professionally and work on it. But because of that, engineers are reluctant to accept just any new problem that shows up on their doorstep. And you will be amazed at the lengths some will go to in denying that the problem is their problem. Sometimes they may even start to deny that the problem actually exists."

"Aha," I exclaimed, "that's why you need to do step one first! You have to establish that there is a problem so that it doesn't evaporate as the discussion proceeds."

"You're catching on," Roscoe said, "you're catching on."

So, I noted, the beginning was simple. Establish that there's a problem, and convince the engineer that it's his problem. The first Texas Two-Step was a piece of cake.

"OK," I said. "Now what about the second Two-Step?"

Step Number Three

"Well, here is where it most often goes off the rails," said Roscoe. "What you have to do is not suggest a solution."

Well, I'll be darned, I thought. What is so awful about suggesting a solution?

"It's the reason many software engineers bristle at the word requirements. In days of yore, people would come to them with preconceived ideas of how things should be implemented, and call them 'requirements.' That attitude led to lots of really unnecessary conflict.

"What the engineer always wants to know is what you want done. They never want you to tell them how to do it. After all, that is what they are getting paid for. If you come marching in with a proposed solution, there is almost certainly going to be some friction.

"And there's another problem with coming in with a solution. Often, the engineer will work backwards from your 'solution' to try to figure out what you really want to do. He may get it wrong. By proposing a solution, you actually add work and risk to the whole proposition."

"So," I wondered out loud, "how do you get at the solution?"

"The really smart managers," Roscoe continued, "sort of feel out the engineers to see what the possible range of solutions is. They get them to talk about what the options and trade-offs are. Exploring the 'solution space' is OK, provided the engineer is supplying most of the data. But for heaven's sake, don't tell him how to hold a pencil.

"In the software world, there is almost always more than one way to solve a problem. What engineers will do is consider alternative options, and then try to select the best onewhat they call the optimum solution."

"Wait a minute," I interjected, "who decides what's best?"

"Good point," responded Roscoe. "'Best' could mean 'fastest,' 'cheapest,' 'lowest risk,' 'lowest maintenance,' 'best-crafted,' 'most elegant,' or a bunch of other things. So part of the exploration of the solution space with the engineer is to understand what 'best' means in your business context. Otherwise, you may get the 'best' technical solution, which may not be appropriate to your needs."

"OK," I countered, "but what if the solution is going to take too long?"

"Another valid point. The purpose of exploring the solution space with the engineer is to also give him an idea of what your constraints are. That way you can work with him to negotiate a solution that makes both of you only moderately unhappy. Sometimes that's the best you can do."

Well, let's see, I thought. We've defined the problem, we've got ownership, and we've got the solution space somewhat mapped out and negotiated around some alternatives. Not bad. What's left?

Roscoe, of course, read my mind.

Step Number Four

"Closure," said Roscoe. "When you are dealing with engineers, you always have to get closure. As in, 'What are the next steps?' and 'Who needs to do what and by when?' If you end the discussion without covering this ground, you will most surely come to grief."

"Why is that?" I asked.

"Well, it's like this. Engineers are busy folks. They always have more work to do than they have time to do it in. You have already taken up some of this time going through steps one through three. And it's all wasted, because if you don't do step four, nothing will happen once you leave the room."

"Huh?" I blurted out.

"Well, look, did you tell the engineer to do something? Did you tell him to actually begin work? Did you assign this new task a priority, relative to all the other things he is already working on? No. You did none of these things. So clearly you were there to discuss the problem, not get it solved.

"Now if you want the engineer to actually do something, you have to say so, and be clear when you do. What's that ten-dollar word? Oh yeahyou need to be explicit. And when he commits to do something, you will of course ask him to commit to a date. Because without a date, there is no real commitment.

"Now there may be some more work to actually complete step four. The engineer may ask you for more data, ask you to better describe the scope of work, and yes, even ask you to put it all in writing. And he may have to think about it a little more, and then the two of you may have to finally agree on the solution to be implemented. All reasonable requests. At least now you know he is engaging with you, and you may actually get a result."

Beyond the Basics

So Roscoe's formula is pretty simple:

1. Define the problem, and agree on the definition with the engineer.

2. Establish that ownership now lies with the engineer.

3. Explore the solution space, letting the engineer take the lead.

4. Make explicit and agree upon what will get done, including scope, priority, and date.

Why, I asked Roscoe, was this simple formula not followed more often?

"I think it comes down to what engineers would call an impedance mismatch.^[6] Managers take lots of things for granted and make lots of assumptions that are just not true. Sometimes they are misinformed; often, they don't know what they don't know. But because they are smart, and they know that engineers are smart, they assume that there is a common context for the discussion. So they skip ahead. Often they jump ahead to the solution, working on steps three and four.^[7] And here's the engineer, still stuck in his own mind on steps one and two. Things bog down at that point.

^[6] A term with an interesting history. It comes from electrical engineering, and refers to trying to connect two circuits that have different capacities to absorb or transmit energy. When this is attempted, the resulting circuit is particularly "lossy." In common parlance, the term has come to mean a communication between two parties in which differences in the respective parties' contexts (or differences in the language they use to express themselves) is so great that communication is difficult and may at times break down completely. Or, to put it another way, the process generates more heat than light.

^[7] Ironically, managers who have previously been engineers often make this mistake. They should know better.

"Sometimes, to save time, you have to go more slowly," opined Roscoe.

"And of course, there's this other problem. Often the solution that the manager proposes is of the 'quick and dirty' variety, an expeditious way to resolve the problem. Perhaps it is a low-cost approach that involves some throw-away work. At this point, you can expect the engineer to go ballistic."

"Why's that?" I asked.

"Well, it's the nature of the beast. Engineers hate to do throw-away work. They would rather spend their time crafting the solid solution that will not need to be redone. Sometimes there is excessive intellectual purity here, rather than a careful analysis of engineering trade-offs. But it takes a really technically deep manager to argue these finer points with engineers. That's why it's best not to come in with a solution, but to let the engineer suggest options to you."

That sounded politic. Did Roscoe have any other suggestions, I wondered?

"One more. Be careful of asking software engineers to do too many things at one time. They believe that they work best when they can concentrate on one task and give it their full attention.^[8] They know what multitasking is, but they don't believe that it is the optimum way of working. And you know," he winked at me, "if they believe that, it is probably true. So don't fall into the trap of even talking about piling too much different stuff on their plates. It just gets them in a really bad mood."

^[8] Word has it that some studies support this position. Roscoe couldn't cite any, though. And, to be completely correct, I should point out that there are engineers who like to work on several problems simultaneously. I have found them to be in the minorityhence, the generalization.

Sounded like a good insight. Anything else?

"You've got to be careful in all this. Remember, your objective is to improve communication. If your partner in the dialog thinks that you are patronizing or trying to manipulate him, all is lost.

"Talking with engineers is a process, not an event. The dialog needs to be ongoing. You are not going to talk with this engineer one time and then never again. That alone argues against bending him too far out of shape, doesn't it? You are going to have to talk with him againif not on this subject, then on another one.

"So I try to establish this pattern, where the fella knows what's coming. I think of it as establishing a comfort zone. If he knows I'm first going to try to establish what the problem is and who owns it, he can be ready to discuss that. Perhaps he can get me out of his office in five minutes. Might save us both some time. Then, once we're past that, we can have the interesting part of the discussion, from his point of view. That's step three, where we discuss alternative solutions. That's where he gets to shine.

"And, of course, he needs to know that step four will always follow. That shows him I am serious, that I don't want to just talk about it, but that I want to do something about it. Once again, engineers respect that.

"And, by the way, when an engineer comes to you to talk, you can expect him to follow the four-step approach. The reason is, engineers talk to each other that way, more or less."