What the Consultant Did
The consultant was astonished by the programmer's response: "That's not an error. Actually, the formula was in error, so I corrected it. The formula I programmed is correct, whereas the original formula was simply wrong."
The consultant understood, which the programmer did not, that a program error occurs when the program does not do what the customer wanted, not what the programmer thinks the customer should have wanted. That was the programmer's first mistake.
The programmer's second mistake was not understanding who his customer was. He seemed to think that the French were the customer, but the actual customer was the consultant.
(NOTE: If the actual customer had been the French, the programmer's action was still wrong, because of his first mistake. If a programmer thinks his customer has asked for the wrong thing, he could, politely, bring this thought to the customer's attention. So, if the French had been the customer, the programmer's third mistake was not bringing his thought to them. And even if the customer had been correctly identified, the programmer's fourth mistake was being rude and arrogant. That's simply not the way to get your point across, especially if your point is that your customer has been wrong.)
What the Consultant Said
"You didn't understand your assignment," the consultant said. "We're trying to simulate the precise formula used in France so we can compare it to the formula used in other countries. It's not a question of right or wrong, but merely of matching the existing French formula."
"Well," the programmer replied, "anyone with half a brain and a smattering of knowledge of inventory theory can see immediately that the French formula cannot possibly be correct, so what's the sense of programming it? Tell them to use my formula, if they want to improve their inventory management."
The management consultant decided to try another approach with the recalcitrant programmer. "That's a good idea. If you're right, I'm sure they'll really appreciate getting a better formula. In the meantime, it will help them to accept the new formula if they can see how it compares with their original one on this data, so I'd appreciate having their formula programmed as soon as you can manage."
"You don't seem to understand," the programmer insisted, "Why should I waste my valuable time on a formula I know is wrong? Just show them my formula and they'll understand."
At this point, the management consultant gave up on the programmer and got himself another one. The French formula was programmed and found to give the claimed results which were, in fact, superior in many circumstances to the approaches used in other countries. It turns out that the programmer's fifth mistake was overestimating the "correctness" of "inventory theory."
Readers' Comments
A number of readers correctly (I believe) said they would try talking with the programmer. In the actual case, the consultant tried this, but learned that the programmer was not going to listen. Perhaps this was the consultant's fault in the way he tried to talk to the programmer, but in any case, if your employee (and the programmer was, of course, working for the consultant) won't talk with you about a situation, then you have to get rid of that employee. So, attempting to talk is a good approach, in that it gives you essential information even if the programmer refuses to talk.
Other readers warned the consultant to consider his own role carefully, and to consider myriad possible interpretations of what's going on. This is always good advice for a consultant.
Several readers correctly identified one or more of the programmer's mistakes (above). Clearly, someone needs to educate the programmer about what his job is, and how to do it, but evidently the consultant lacked the skill to accomplish that. So, again, the consultant needs to consider his own role, at least for the future. In a similar situation, for example, he might take more care in choosing the programmer and/or making the programmer's task much clearer from the outset.
Those who advised the consultant to get "on the ground" with the inventory application were also on a productive track. In this case, the consultant was in the USA, and meekly accepted the refusal to pay him to travel to France and study the French approach first hand. If the consultant knew what he needed but didn't insist on having it, he made a major consulting mistake. If you insist, but your client won't supply it (time, or access, or money, or whatever), then the consultant should simply resign from that assignment.
Using specific examples rather than simply theory—what a good idea. Both the consultant and the programmer were probably "intuitives" in the MBTI sense, so they kept the discussion on the level of theory, which often misses some crucial data. In this case, if the French formula actually worked in practice, that would have thrown an entirely different light on the discussion.
Next Steps
All in all, the case example seems to have done its job—namely, stimulating an outpouring of darn good advice about consulting and programming.
Now that you have the "whole story," what further observations would you like to make as comments?
7 comments:
I don't necessarily consider what the programmer did to be a mistake. Perhaps he could have been more diplomatic, however I'd much rather work with a programmer who used his brain instead of simply following instructions.
I thought these two posts were great though, very interesting to see different perspectives and how the scenario actually played out.
I agree with Jason. I'm very much in favor of brains, yet this example shows how the mouth can undo what the brain solves.
These were very useful posts, thanks Gerry. I was a bit late to comment on the first post but my feelings were as follows.
Part of the original scope was an evaluation of the French procedure. The consultant wanted to do a comparison on the French procedure. To do the comparison you need to use the same formula or the comparison is moot.
I would need the answers to a few questions before I could decide the best way of going forward. My first step would be to set about getting the answers to these questions.
1. Why does the developer believe that the French formula is incorrect?
2. Why did the developer choose to keep that pertinent knowledge to himself and change the formula without informing anyone, especially the consultant?
3. What is the difference between the 2 formulas in terms of the procedure and the results?
I also really wanted to know the ins and outs of the inventory process in as much detail as could be gathered, or rather as much as would be pertinent to my understanding of the results.
I agree that to question is almost always a better way forward than to blindly follow, but questioning should be accompanied by discussion and understanding of why it is done that way to begin with. Blindly changing something to your own flawed process is as bad as blindly following another’s.
Joanne,
Your comments rather nicely summarize the issues. I particularly like your statement:
"Blindly changing something to your own flawed process is as bad as blindly following another’s."
I'm going to tweet that, giving you credit, of course.
The programmer might've had a valid point, but I question how he would have been sure that his own formula was correct in the context of the situation. The reason I have my doubts is because it seems like he didn't have any direct communication with the customer, thus his comment about his own solution being correct sounds like hubris to me.
As for the consultant, I think he took the right approach - attempt to provide clarity and get buy-in from the programmer, but ultimately resolve to cut him loose if he doesn't co-operate.
Interesting Post..
I'm in the process of building a "Lean IT" consulting practice after many years of managing IT teams in the corporate world.
As a manager, I had smart technical folks telling me everyday that we "should be" doing things this way or that way. Often, but not always, they had a good point and it made sense for me to remain open to hearing what they had to say. I learned a lot from them and I hope they learned a few things from me.
In the end, though, I made it clear that it was not their decision (and perhaps not even mine) as to how we would proceed. I would try to explain why things were going to be done a certain way, which may not have (technically) been the "best way." Sometimes I felt that the tradeoff was justified and sometimes not (one of my reasons for eventually leaving).
For this to work, there has to be mutual respect between both parties. In this case, I feel that the developer was out of line. If I paid someone to code x, I don't want to get y without having them come to me first and explain what they were doing. If he did come to me first, I'd thank him for his insight and then explain why it was essential to code x to fulfill the engagement.
I don't know all the details of this case, but it's a shame when an IT person acts that way because it reinforces a negative stereotype (held by management) many of us have spent years to overcome.
Jeff wrote:
"it's a shame when an IT person acts that way because it reinforces a negative stereotype..."
We need to be reminded that it's much easier to destroy an image of a profession than it is to build it in a positive way. We're not acting just for ourselves, but sadly, some folks just don't seem to care, or appreciate the many years of work that have been done to support them even before they were born.
Post a Comment