I was talking to someone about providing useful information in reports, and we got onto the subject of “Why are you telling me this” a topic I once had in a mentoring presentation.
Why are you telling me this?
I was in a meeting with the Lab Director, on a hot summers afternoon, with the sound of the bees coming through the open window, and the smell of freshly cut grass. A team were presenting a topic to us, and it was only mildly interesting. It was easy to shut your eyes and listen (a polite way of saying fall asleep). At the end of the presentation they said “And we would like you (the Lab Director) to fund £1 million for four people to take this forward.” Whoa – we all woke up. The Lab Director said he had not been listening with his “funding ears”, and didn’t think he could fund it. He went on to say “Next time you want something from me, then at the beginning of the presentation say ‘We want you to fund this project to £1 Million’ and I’ll know what you want before we start.”
It is very useful to know why someone had come to see you. It would be very helpful if the person was to say:
- I’m telling you this for your information. You do not need to do anything. You may get asked about it.
- I’m telling you this for your action. I would like you to sign these expenses; give me advice; or go and talk to someone on my behalf.
- I’ve had a great success – I just want to share it with someone!
- I’m bored and I just want a chat. (We had someone who would come round and chat. We solved this by sending a message through the computer to a friend saying “please phone me”).
Writing reports
The “Why are you telling me this” questions applies to writing reports as well. You need to know what you expect your audience to do with the report.
I was asked to review a 60 page performance report before it was presented to the customer. Although I was jet lagged, I spend the evening going through the graphs and the explanation and marked up many comments. The next day I asked who wanted my comments, and the reply was “we don’t want any comments we just wanted you to review it”!
They planned to spend a couple of hours going through the report with the customer; a senior manager and his team. I managed to persuade them that the senior manager would not know the technical details, so he would not understand most of the charts. I asked the team “what do you expect the manager to do with the report?” the answer was “give it to one of the system programmers”. “What do you expect the systems programmers to do with it?”, “We don’t know”!
We had a lot of discussion, came up with a short presentation aimed at the executive. We took data from the report and summarised it, for example
- We tested it up to 50,000 transactions a second” before we ran out of CPU. Your requirement is 10,000 a second.
- The cost per transaction stayed pretty constant. At the high transaction rate, it was 20% more than than a low transaction rate.
- In a disaster recovery it took us 2 minutes to switch to the backup servers, and continue working. It may take you longer depending on your database.
It is much better to tell people information, than have people work to get the same information. It is much quicker to read
The cost per transaction stayed pretty constant. At the high transaction rate, it was 20% more than than a low transaction rate
than to give them a chart they have to look at – read the title, the axis, the ranges of the data, and interpret it (should it be flat or should it slope up? Why is there a wobble in the data?). Many people do not listen while they are reading.
Graphs have their places, for example showing how the response time changes with transaction rate may be good. But
at 100 transactions a second the response time is 500 ms, and 1000 transactions a second the response time is 1000 milliseconds.
may be good enough if the requirement is 2000 milliseconds at 1000 transactions a second.
It all comes down to …
What you expect the audience to do with the data.
I have been working on some blog posts about z/OS performance. I had someone review it to make sure it was at the right level and I was surprised at the comments. For example
- You have told me about the RMF reports, but you haven’t told me how to collect the data, or how to format it.
- You said if this number was large, you have a problem. What do you mean by large?
I should have written a “specification” in comments at the top of the blog post.
Q:Why am I writing this?
A:So people can collect and report performance data; and see if there is a problem.Q:What will they do with the report
A:Use it to collect performance data.
A:Use it to process the data
A:Understand which fields are important, and have background to explain
why the field is important
A:Identify good and bad values of fields
A:Understand what they can do about problems.
If I had done this and written the blog post to meet these goals it would have been a better document.
Feel the weight!
I once saw a report about MQ for a customer. It was about 100 pages long! They gave an introduction to MQ, listed all the parameters, gave the size of all the data sets etc. A lot of the data was just cut and paste of other data. When I mentioned this to the team, they replied, the customer executive likes to get value for money, and a long report shows value for money (feel the weight), it shows how much work we did.
I thought the executive was out of his depth.
This reminded me of Parkinson’s law, “work expands so as to fill the time available for its completion”. He also described “the bike shed problem”. A committee has two items on its agenda
- Should we invest in a nuclear reactor?
- What colour should we paint the bike shed?
No one had any experience of nuclear reactors, so after 5 minutes discussion they approved it. They spent the next 55 minutes discussing the bike shed. The cost of them discussing it was much more than the cost of a person to repaint the shed if they made the wrong decision.
They understood the bike shed problem, and knew nothing about the nuclear reactors, so focused on things they knew about rather than getting experts in to advise them.
This is not to be confused with the Peter Principal which observes that people in a hierarchy tend to rise to their “level of incompetence”. If the person is competent in the new role, they will be promoted again and will continue to be promoted until reaching a level at which they are incompetent. Being incompetent, the individual will not qualify for promotion again.
Nor is it to be confused with The Dilbert principle which says that incompetent employees are promoted to management positions to get them out of the workflow.
ColinPaice 