Saturday 11 April 2015

Presenting status updates: do-s and don't-s


Presentation is one of the most neglected skills among software engineers. It's hardly surprising: software professionals are rarely hired for their flamboyant keynotes, ability to entertain, elevate and amuse, or massive PowerPoint skills. 

Nevertheless, as people progress through their careers, they start consciously or subconsciously improving their soft skills: written comms, cross-team collaboration etc. Yet, it is rare that someone wakes up one morning and decides that from now on they shall be a great presenter. 
The pervading opinion is that this is what Marketing and Sales do, while we code and test.


But do we really have to present?


Yes, we do. We're Agile now, so engineers do demos, iteration kick-offs, retrospectives and what not. (I'm not even going into more advanced exec or customer technology presentations - not yet).

For example, one of my favourites is the department update meeting. The chances are that you know the drill: a department consisting of several teams gathers and each group goes on about what they've done and what they are going to do.

An example update from a team might look like this:



Now, I'll paint a temporary target over the bulletpoints, but will leave them alone for now. Let's listen to the presenter.

Right, so we developed widget A, and then we refactored module B, and, um, we did not quite deploy feature C, but we had to look at urgent customer problem D. 

Sounds familiar? If not, then count yourself as lucky, and classify this post as rant. If yes, then you probably had the same mental reaction as me: "I can read! I don't need you to vocalise the bulletpoints!".

The reason people do this is simple: reading and writing bulletpoints is easy, but conveying memorable information is not.

When we mix that with the tendency of IT professionals towards introversion, and hence keen desire to tick off the meeting rather than revel in the opportunity, we get a rather boring result.


Ok, stop the rant. How can it be done better?

Well, for starters, PowerPoint is a visual aid, not a subtitle. Whenever I present, my mental goal is not to repeat anything that the slide already has.
More importantly, I need to understand what my audience cares about, and how the information can be rotated in their direction.

In this case, our audience is fellow engineers; what do they care about when reclining in their chairs during a departmental update meeting?

In the order of priority:
  1. Is this meeting going to be quick and when can I get back to my work?
  2. How anything of what he/she saying is going to impact me?
  3. Is there any cool technology involved?
  4. What are other teams working on and why?
Of course, I am being facetious here, and many engineers might well have number 4 as their top priority. Many will also care about the business side of things. However, let's keep things simple and stick with these four. Here's how I would go about presenting the same slide:

We were finding more and more defects in our logging layer, so we refactored it to a plug-in system. We might want also to simplify back-end interface, so back-end team - we'll come talking to you. 

Feature C was our first deployment using Docker, but we missed some network configuration specific to production, so it got delayed. If anyone is interested in the details, please go to the Wiki page. 

We had an interesting defect uncovered by customer X - turns out we had a classic off by one in our report calculation, and they managed to pick it up. 

Main thing, we finished our cool new customisable skin engine, here are a couple of quick slides on how it looks like.

This might also elicit little reaction, but at least there is genuine attempt to convey new information and share what we've done. It's also not hard to extrapolate and talk about what we are going to do.

There are also many little techniques to keep the audience engaged:

  • For example, rather than explain the off-by-one defect, I could pull out a slide with the erroneous report, and ask whether someone can spot the issue. People enjoy showing how smart they are, and more importantly, that they are smarter than everyone else around them.
  • I also would jump randomly across topics rather than go top to bottom - the last thing a presenter needs to be is predictable.
  • Giving a nod to someone else (e.g. and here we used Docker techniques shown by Mike in the last demo) is also very important psychologically - it shows Mike and everyone else that these meetings and their efforts are not done for nought, and emphasizes collaboration.
  • It also helps gauging the audience's reaction visually, and deciding where and what we should zoom in.

There's not much to it really: just a combination of small rules and an ounce of self-confidence. Far simpler than understanding intricacies of modern programming languages
It won't make one a world-travelled keynote presenter, but should go far enough to keep fellow colleagues interested.

What about bulletpoints then?

I don't like them. To be precise, I don't mind them being in the presenter's notes, but not on a 16x9 projected screen in front of 50-odd people.

Why? They're not very visual. It's me who is conveying the bulk of the information, and the job of PowerPoint is to visualise it. They are very good as talking points reminders, and they are fine as an offline list for those who can't be at the meeting or listen to the recording. 
But, that can't take away the fact that they are bland, and the last thing any presentation need to be is bland.

So, coming back to the departmental update meeting - I'd move the bulletpoints to the notes section where they belong, and use the slides to show off screenshots, high-level architecture diagrams or PowerPoint SmartArt.

Of course, someone from Marketing would run circles around this, and create slides that put my list to shame. That's fine - we are not visual arts majors, our job is to create adequate, not great, presentations.

Do the same techniques work for other presentations?

Not exactly. A customer meeting and an exec presentation have complete different audience and focus. There's less merit to jump across topics or give credit to someone in the audience. Of course, attendees' agenda is also at a completely different angle.
Maybe a good topic or two for another post...

No comments :

Post a Comment