by Steven Cerri
In this article I’m going to analyze one technical management case. In this case study I’ll set up the initial conditions and then tell you what I did and how it turned out. These are real world cases. These situations happened to me. I’ve changed the names.
Management Case Study #1: Tom Won’t Release His Software
Initial Conditions: Tom was a young programmer with a BS in computer science. He’d been with our company for about three years. He was sharp, confident, personable, and a good programmer. He was our chief engineer in charge of the development of the user interface for a large database we were developing for a very important customer. The contract called for rapid prototyping of the user interface, allowing us to receive customer feedback on the human-machine interaction as early in the development cycle as possible; at least that was the plan. Tom had agreed to a three-month prototype development schedule. But five weeks had passed and Tom was a week behind schedule on the delivery of the first iteration of the prototype interface. The project manager asked Tom when the prototype would be delivered to the customer for interface input and Tom said; “Just a few more days.” A few more days passed and again Tom indicated that the interface was not ready. He needed “a few more days”. This went on for another week until six and a half weeks had passed since the beginning of the contract. Tom was close to being three weeks behind schedule… and the customer was getting worried, as was the project manager. Tom seemed reluctant to release the prototype interface to the customer.
The project manager asked for my help, pleading that Tom must release the prototype interface immediately. Unfortunately, the project manager didn’t understand the software well enough to know if Tom was being reasonable or if he was being a perfectionist. Reasonable was fine… a perfectionist we didn’t need…this was after all the rapid prototyping phase to get customer feedback.
What would you have done in this situation? Would you have ordered Tom to deliver the prototype software? Would you have given him all the time he wanted? Would you have renegotiated the contract? Would you have threatened Tom? Would you have put an expert with Tom to evaluate the software status? Would you have reasoned with Tom? What would you have done?
My Actions: This is what I did. First, my basic assumption is always that people are doing what they think is right. I don’t believe people are trying to be difficult. I believe people are always doing what, in their mind, is the best, most reasonable thing for them to do. That meant that Tom hesitation in releasing the software had some reasonable rationale in Tom’s mind.
So I wanted to understand why Tom was unwilling to release the software, and since I believe people will basically tell you the truth…I asked him. I said: “Tom, I understand you aren’t yet willing to release the prototype software to the customer. What are you attempting to accomplish?” Then I listened and I just let him talk.
He responded that he wanted the prototype interface loaded with enough ideas so he could get all the feedback he possibly could from the customer before developing the final program. Now I knew that Tom was after the same thing we all were…good customer input.
This was the key. If I could find a way to satisfy Tom’s goal and get the software in the customer’s hands immediately, everybody wins. So I next said to Tom; “You know Tom, you have just about enough time… if you give the software to the customer tomorrow… to actually get one more iteration of the customers’ input. Seems to me that rather than delaying delivery and getting only one iteration, you could release it tomorrow and actually get a second opportunity for the customers’ input. That would make your interface much more of a match with what the customer really wants, because they’ll get smarter as the project goes along, and so will you. Just think about it Tom.” And I walked away. The software was in the customer’s hands the next day.
What did I do in my conversation with Tom? I actually matched what Tom wanted with what our company and our customer wanted. I could have ordered Tom to deliver the software but that was only one choice. By my conversation with Tom, I refocused Tom’s intention so that he was motivated to release the software as soon as possible. Why be autocratic when I could just as easily motivate Tom to deliver the software?
By understanding the motivational maps of colleagues, direct reports, and customers, you can have impact beyond that provided by positional authority.