Delivering Tech Showcase Presentations

What’s a Tech Showcase?

A Tech Showcase is a conference call that allows developers from across teams and locations to describe and explain the technology that’s used to drive products and features they’re working on.

For example, this might be a new library or framework that’s being brought into the team’s technology stack to deal with a particular problem.

It could also be a new DevOps feature or management practice that’s streamlining the process of getting code deployed to the end-user.

Why Do Companies Have Them?

These calls give developers a chance to learn from each other and ask questions. They also give engineers the opportunity to develop their public speaking and presentation skills.

What’s in it for Me?

It depends.

When listening to other developers speaking, in the past I’d estimate maybe one/two in five presentations contains information that’s closely relevant to the libraries and frameworks I work with.

While gold nuggets of information can come up and are valuable, there’s a lot more to be gained if you’re presenting.

These calls give you the opportunity to make yourself known across teams to other developers, technology managers, and directors.

A confident presentation will go a long way and represent your team and product in a very good light.

Fail to Prepare…Prepare to Fail!

Forgetting things on calls is not a show-stopper, but when things go wrong it can be devastating for your confidence — and we don’t want that to happen.

Some people are naturally good at public speaking, while others are reluctant and would rather stick sharp pins in their eyes than volunteer themselves to present something on a call.

This might surprise some people: I’m actually quite a nervous person. However, I mitigate the effects of my nervousness through preparation.

Unfortunately, anxiety can cause me to completely “go blank” in the middle of delivering my update on a call. What makes things harder is that a known side-effect of a medication that I take is short-term forgetfulness and “brain fog”.

For example, when I was in the early stage of writing my book Best Practices for Software Engineers: A Soft-Skills Guide for Junior Developers, I had to immediately write down any good ideas that floated into my mind on sticky notes to stop me from forgetting a great topic for a chapter or sub-chapter of my book.

Why Have a Script?

So when I’m lined-up to present something on one of the showcases, I need to put practices into place to mitigate the negative effects of my forgetfulness.

One of the things I do is write a script, for three reasons:

  1. It guarantees that I’ll cover all the points I intend to make on the call.
  2. It reduces my anxiety because I know I’ve got something to fall back on should I get stuck.
  3. It allows me to focus more closely on what others are presenting on the call when it’s not my turn yet to speak, rather than nervously sitting there, repeatedly going over in my head what I intend to say.

Delivering the Presentation

It’s a good idea to keep a template that can be changed to suit all kinds of presentations.

When it's your time to talk, you’ll want to share your team’s application on your second monitor, while keeping your speech on your laptop screen. This is for two reasons:

  1. It allows you to present your code without the audience seeing your script.
  2. It gives the illusion that you’re speaking directly to your laptop’s camera to everybody on the call, between glances to your second monitor. This doesn’t matter quite so much, as everybody will be focused on your code, but it's worth bearing in mind.

How much you rely on your script is of course your choice. Just remember to raise and lower the tone of your voice throughout the call, keeping natural breaks in your speech now and again, to give others the impression that you’re talking without a script.

Making a Powerful Start

When it’s your turn to present, the first thing you should do is confirm that the audio and visuals are good. You’ll want to thank the call leader for the opportunity to speak, then check that everybody can hear you clearly and see your screen:

“Hi thanks [call leader]. Can everybody see my screen and hear me okay first of all, before we start?”

After that, you’ll want to give a confident introduction; telling everybody a little bit about who you are, what team you work for, and what product you’re working on.

Remember, not everybody will know who you are — particularly if you’ve just joined the firm — and people from other teams will need reminding about what your product is and why it contributes to the profitability of your firm:

“So hi everybody! For those of you who don’t know me, my name is George and I work with [team leader name] on the [team name] team. Today, I’m going to present to you a new feature we’re adding to [product name] product, which is a module that allows users to leverage [key benefits].”

Next, you need to set everyone's expectations about how long your presentation will take:

“This presentation should take around ten minutes, with five minutes at the end for questions.”

Setting the Scene

You’ll then ensure that everybody has a high-level understanding of what you’ve accomplished using a particular technology. Perhaps you’ll also want to demonstrate what a user can now on the UI:

“Before we start looking at how we’re using [code/framework/library], I want to, first of all, give you a high-level business overview of our new feature from a user’s perspective . . .”

Once you’ve done that, you’ll want to signpost to your audience that you’re now going to discuss the code:

“Okay, so now that we’ve got an idea about what this new feature does, I’d like to turn your attention to the [code/library/framework] we’ve used to implement this change and what benefits this offers us.

From here on, it’s your territory as a programmer, and hopefully shouldn’t be too difficult provided you’ve done your homework on the topic you intend to speak about. One thing you’ll want to remember to do is to contrast what was previously done with what’s done now. For example:

“So, previously we’d need to have done [X] to accomplish our goals. However, with [Y], we can write considerably less boilerplate code . . .”

Opening Up to the Audience

You’re almost done! You’ve explained your code. You might now want to politely invite your line manager — or another team member with more experience on your topic — to add anything else they think you’ve missed:

“So folks, I believe I’ve covered all the points I wanted to discuss on the call. [Team leader] I was wondering . . . do you have anything you want to add that you think I might have missed?

After that, you’ll want to take any questions from the audience:

“Okay thanks [person]. I’d now like to open up my presentation to take questions from the audience. Any questions at this time? Do speak up.”

Dealing with Questions

You have a choice about whether to allow users to interrupt your speech with questions, or to instruct them to keep these to the end of your presentation. If you’re going to allow questions in the middle of your speech, and it's not a big problem with the Tech Showcase host if you run over your time, you can say something like this to invite audience participation:

“If you’ve got any questions, please feel free to interrupt me and I’ll try my best to answer them.”

You could also have natural breaks at the end of each paragraph and confirm that everybody understands what’s being presented:

“Are there any questions at this time?”

Handling Interruptions

On every presentation, there’s always one person loudly typing, munching a sandwich, or scolding their dog.

There was one call I had years ago where somebody — and I have no idea how this happened — placed their phone on hold, blasting out music to everyone on the presentation. I think that call was abandoned and everybody was forced to dial in again!

I’d find out from the Tech Showcase host if you can mute everybody on the call while you speak. If that’s not possible, you’ll need to stop speaking when interrupted by noisy people and say:

“If you’re not speaking can you put yourself on mute please . . . thank you.”

or, more firmly:

“Please put yourself on mute if you’re not speaking. I’d like to do my presentation without interruptions . . . thank you.”

Finishing in Style

You can now breathe a sigh of relief — you’ve reached the end of your presentation! But. . . you’ll want to go out with a bang, buzzing with good feelings about how well you’ve done.

I’d conclude gracefully in the following way, thanking everyone for their time and inviting any future questions that audience members may have:

“Well thanks very much to everybody for listening to my presentation. If after the Tech Showcase anybody has more questions that come to mind, please feel free to send me a direct message and I’ll try to answer as best I can. I’m now going to hand back to [call leader] and stop sharing my screen. Thanks.”

Written by

George is a software engineer, author, blogger, and tech enthusiast who believes in helping others to make us happier and healthier.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store