©Joe Armstrong
Nobody loves the bearer of good news, I said.
Haven't you got that wrong, wasn't it bad news?
Technology transfer, in particularly in the fast-moving high-tech computer-telecoms world is often characterized by rapid paradigm shifts and greatly improved ways of doing things.
So here's the good news, we've found a new way of doing things that's a zillion times better than the old way - the bad news is that you have to write off your old multi-billion dollar investments in hardware and software because it can all now be done by some ten dollar zingo.
So what happens when you are the bearer of good news?
We can do what you want with 10% of the effort and deliver in nine months instead of two years.
The bearer of such good news is often surprised at the reaction. Since I have often been a bearer of good news let me tell you some of things that do happen and some of the things that don't happen:
What I'd like to happen is that the recipient of the good news would say:
But this reaction is the stuff of dreams and has never been observed in practice. More common is one of the following:
All the above patterns of behavior are extremely common. So what can the bearer of good news do to make the news go down better?
So where do we go wrong in bearing the god news?
Here's a example of this:
A few years ago we were approached by a man with an acute and (as he thought) difficult problem. Two members of the computer science laboratory were dispatched post haste to try and solve the problem. This is what happened:
Years later, and it has taken me years to realize this I realize that the problem lay in the conceptual gap between the mind-sets of the people involved.
As it happened, we got the job (I'll tell you why later) and as the job progressed we learnt the reason behind the disbelief.
What we didn't know was that the man with the problem had tried unsuccessfully to find a solution to his problem and had gone to several different people in his search for a solution. He'd always got answers like
It'll take 24 man months with a delivery time of 9 months to a year.
The answer he got from us was a shrug of the shoulders a smile and
two weeks for a prototype - then maybe an extra month to productify it.
The conceptual gap between the reply that he expected , 24 man months, and the reply he received 6 man weeks was so great that he could not believe the offer. He went into disbelief mode smiling and not saying much.
Lessons learnt.
So what should we do here. The crucial point is to get inside the customers head and find out two things, firstly how much effort they think the job will take and secondly when they think it can be delivered.
In our example our man thought the work would take 24 man-months and would have a 9 months delivery time. We thought 6 man weeks. A credible offer might have been 6 man-months with a 5 month delivery (but if we work really hard 4 months). He might just buy this if we don't over-sell how easy it is.
If you have a problem with your conscience here remember that you should always tell the truth but you are not obliged to tell all the truth. So if your estimate of the job is 6 man weeks and you say 5 man-months, possible less and if your intention is not to screw the customer then fine.
This is why they say never let your your technical guys talk to the customers.
I have, of course broken the rule of lesson two on several occasions and it has caused me no end of trouble. The first time I was young and inexperienced. In two weeks I solved a problem that had occupied one Professor, and his research group in a couple of years work and had generated a considerable body of papers. They were certainly not pleased when I announced that the problem was "trivial" and that "all you had to do was twist the problem a bit and look at things in a new way" and then it was easy. Boy did I suffer from that one. Almost 18 months of problems and battles ensued. Did I learn? - no way. I had of course expected reaction 1 (Joy).
And then there was the time I told European Space Agency that six people had built all the software for a satellite control system (The six were fictitious, invented to the disguise the fact that one and a half people had done the job)...
And then there was AXE-N (Mike and I told 'em) - were we popular? I'll leave you to guess the answer!