In many organizations, developers tend to be insular, with little external communication outside their team.

Part of this is simply the nature of the job, but a much of this stems from belief in developer stereotypes. I have seen organizations that jump through hoops to prevent developers from interacting with clients or other stakeholders. Even organizations that claim to follow agile processes such as Scrum often do not like developers showing their new features.

At some point, developers will need to present their proposals or products to a non-technical group. The fear is that a developer will immediately descend into techno-babble, alienating the room, confusing the audience and frustrating everyone.

In reality, I have found that this is very rarely a problem. All but the most junior developers are able to tailor their language towards their audience. Every techie has had to teach a relative how to use their webcam…

That said, I have seen that developers tend to make the same mistakes while giving presentations.  Of course, presentation mistakes like these are not exclusive to developers, but I have seen these happen enough times to notice a pattern.

These suggestions are intended for meetings with external clients or outside management.  Many of these suggestions do not directly apply to developers presenting a narrow concept to an internal, informed audience.

Mistake: Fixes or enhancements are always “easy”

An audience member suggests a change or makes a request. The developer immediately responds that the fix is easy. Changing that query, tweaking a report, changing the format is all “easy”. This is especially common after the developer has had to say “No” to a previous request.

Some clients will hear “Easy” and interpret that as a commitment to adding the feature to the next release at minimal or no cost. It may also turn out that the fix is not so easy, because when the client asked if you could “Change that font.” she was really asking for a complete redesign.

Instead: Document and commit to researching the problem, not solving it

You should answer whether or not the change is viable, and commit to examine it for later implementation. Avoid language that implies length or cost such as “a quick fix”. Ideally, someone else in the room will be documenting suggestions during the meeting.

Mistake: Presenting the process.

When presenting ideas to a client, developers tend to focus on the implementation process rather than the topic of the presentation. An excited developer may present all three possible solutions to the problem, explain the pros and cons of each, and only then explain to the audience which option should be chosen.

In a few days, participants may not remember whether option 1, 2 or 3 was chosen or become confused to the differences between them. The audience may start second guessing that option 1 was really the correct choice, because that option had a minor feature they liked.

Instead: Present the solution.

Focus on the team’s accomplishments and only deal with alternatives if you are asked to do so, or if there are significant time/cost differences.

Mistake: Overreacting to technical problems during the presentation.

Everyone has had the embarrassment of having a demo fail during a presentation.  This feeling is even worse for a developer, and they may try to fix the problem.  While the audience waits, the developer attempts to force the feature to work,  or try multiple alternative route. I once witnessed a developer attempt to open an IDE to debug an issue while about a dozen attendees eyes started to glaze over.

Instead: Acknowledge the problem and move on.

A presentation is not the time to correct problems. If a form is not properly updating information, then the presenter should simply talk through it. In many cases, the audience doesn’t need to witness the results. If this is a sprint review, the story has likely already failed, so keep your chin up and move on.

If the issue absolutely needs to be fixed in order to continue, the situation should be quickly explained to the audience and the problem fixed with the projector off. If the problem will take more than a few minutes to correct, politely inform the room that you will need to reschedule the meeting.

If none of this works…

Occasionally you’ll have the misfortune of presenting where the audience demands timelines on all of their enhancements, insists on seeing all alternatives, and chooses to sit in silence while you attempt to re-connect to their broken wireless network.

The advice at that point is to simply smile, work your way through it, and know that you’ll have a great story to tell at the next happy hour.