A few years ago I happened to attend a training on public speaking. In the first few lectures we were presented with the theory of what makes a good presentation, and in the later stages we had to prepare our own. These presentations were then evaluated by other training participants as well as the head lecturer who provided their expert feedback. The idea behind the training was great, but the execution itself not so much.
Most of the trainee’s presentations went fairly well, but there was one that stood out from the crowd. It took the crown for being one of the worst presentations I have ever seen. Well, depending on how you look at the situation it could also count as one of the funniest presentations I’ve ever attended.
The person presenting their project started with a large introduction. The lecturer specifically instructed us to have an introduction, so that people from the audience who are not subject matter experts could follow along. What the lecturer failed to mention, however, is that this introduction shouldn’t take 10 minutes which was the time allotted for the entire presentation.
Their introduction consisted of a great fog of words, throughout we also heard some poetry recitations that were supposedly relevant to the topic. After every minute I thought, well surely now they will come up with a punchline and this great fog of words will clear. As their time ran out, the fog was still there and I had absolutely no idea what I was listening to for the past 10 minutes. The lecturer, bless her heart, didn’t want to hurt the presenter’s feelings so they asked the presenter if they could evaluate their own presentation.
“Well, I had a large introduction,” said the presenter. “Yeah, you certainly did.” It took 10 minutes after all. “And, I read some poetry, which I think made the presentation more interesting.” “Yes, it sure did.” Never have I ever seen that happening before. This evaluation process went on for a while, and after that it was time for the questions from the audience. Someone stood up and politely asked: “It was an interesting presentation, but it looks like you ran out of time and I didn’t quite understand what was the topic you were talking about. Could you explain in one sentence what that was all about?”
I would have never guessed, but apparently the presentation was about a toilet positioned at an angle which is supposedly making it easier to take a dump. It was totally unexpected as somehow such a practical invention didn’t fit their grand introduction, complete with reciting poetry and all that. The whole concept could be explained in less than a minute and everybody would be able to understand the benefits of owning an ergonomic toilet, if only the presenter would go straight to the point.
As I already mentioned in the introduction, the sad part of this training was the fact that the presenter didn’t get any actionable feedback due to the way this feedback was formulated. Most of the feedback that presenters received was about what was good about their presentation and very little time was spent talking about what could be done better.
If you are a presenter, getting the “everything is fine” feedback is quite useless since you already know which parts of the presentation went well. What you don’t know, however, is whether you were speaking clear and loud enough and whether the audience was able to understand your message or everybody stopped listening 10 seconds into your lecture. If all you ever hear is “yes, yes, you’ve done good,” you are just not going to improve, since not everyone is self-aware enough to be able to deduce what could be improved on their own.
I am quite sure the toilet presenter is still making grand introductions to this day, since nobody explicitly told them that you have to present your subject in a way that even a child can understand. This is especially a common problem in more technical lectures, in which the presenters often focus on some irrelevant technical detail that nobody from the audience really cares about. Most of the time the audience just want to know the essence, since for all the nitty-gritty there are either textbooks or discussions that happen after the lecture.
I believe this “praise in public, but never criticize, not even in private” behavior was taken too far in contemporary times since it’s present everywhere you go. You would think that for profit companies would take feedback seriously, considering how much they care about their bottom line, but even in situations where feedback is expected that doesn’t seem to be the case.
A great example of a situation where feedback is expected would be a project postmortem. The point of a project postmortem is to figure out what was causing problems on the project, and how to go about fixing these kinds of problems in the future. Pointing out the problems is simple, since everyone who worked on the project knows exactly what went wrong and what was bothering them. Coming up with a potential solution that would prevent such a problem from happening again is of course a much harder task, but more on that later.
This specific situation happened a few years ago, on a project that was led by a customer. The customer didn’t have the necessary expertise to solve their problem, thus they have outsourced parts of the development to us. Throughout the course of the project, however, the customer went silent and our emails with questions went unanswered.
A common problem of large projects is that the specifications are never written down in enough detail and you will always encounter edge cases which you won’t know how to handle. These edge cases should be discussed with the customer, who should provide the necessary answers. Since the customer was not replying to emails, the developers had to make their own decisions as otherwise the project wouldn’t be completed in the given time. Nevertheless, when it was time to demonstrate a working prototype, the customer complained that whatever was delivered was not what they had in mind.
Unfortunately, this is quite a typical scenario that happens on outsourced projects. Such projects are also often done on a fixed budget, since the customer would like to protect themselves from the ever growing costs that a project gone wrong could bring. For the company that has to deliver a solution, however, working on a fixed budget also means that they can’t just go and redo everything in the middle of the project as that will make them go over the allocated budget and eventually lose money. Meanwhile, the customer has the final word when it comes to accepting your delivery, and you better make them happy or you are not getting paid.
It’s a tricky and unpleasant situation to be in, that is tackled on a case by case basis. When such a problematic project is finished, this kind of a problem will most likely pop up in the project’s postmortem meeting. In this specific example, the project manager in charge had to create a postmortem presentation and they came up with the following insight:
The customer didn’t respond to our questions, so we had to redo a large part of our project and wasted a lot of time in the process.
Solution: We will try to communicate better next time.
People around the table started nodding along; yes, yes we have to pay more attention next time. Of course paying attention is not a solution for this kind of a problem. Saying that is merely stating the obvious. What I wonder is how you will actually achieve that? Will you call your customer every day until they throw the constantly ringing phone out of their window? Will you send them 1000 emails so there is no way they can wiggle out of the situation with the old “I overlooked your email” excuse? If communicating better is all it takes to prevent such a problem from happening, why didn’t you communicate better this time?
Since it was not nearly as obvious to me how they are going to communicate better next time, I’ve ended up asking for an explanation. Considering nobody around the table voiced their concerns, I thought I was missing something obvious, but all I lacked was a training in office politics for I was met with a deafening silence.
Asking this simple question gave other people around the table the push they needed, as suddenly a lot more questions pointed out the flaws in the presentation. Somehow the presentation consisted of a few high level bullet points that were simply hand waving problems away, so that the project manager appeared to their superior as if they had the project under control.
The presenter realized they had messed up and they spent the next few days analyzing the situation. They came up with solutions to all major customer relationship problems that the company had faced in the past and we lived happily ever after with well defined specifications, rested developers and happy clients.
Of course, that only happens in the consultant fairy tales and the reality is a bit different. It turned out that after this incident the engineering team was no longer invited to that particular project manager’s postmortem presentations. I am sure it’s just a coincidence.