8 Tips for Technical Speakers

8 Tips for Technical Speakers

As a seasoned technical speaker at the Telerik Academy, I received an invitation for one of my favorite technical events – DevReach.

Despite the fact that I am too biased with Open Source and normally try to stay away from Microsoft and other companies relying mostly on closed source products, it’s always helpful to see how other experts think, what sort of issues do they have, how does a language evolve etc. Also, the folks from the Microsoft field have decent training programs (just as we have Sun’s certificates, now Oracle’s in Java and the one PHP-related Zend exam).

For those just starting, there are common pitfalls to be aware of. But remember, the key to mastering public speaking is to consider both your perspective as the speaker and the audience members’ experience. Here’s how to think about it:

Common Issues for Beginning Speakers

  1. Overloading Information: One of the typical issues is the temptation to pack too much information into a single talk. While it’s essential to be thorough, information overload can overwhelm the audience.
  2. Lack of Engagement: Beginners often focus too much on the material and emphasize the importance of engaging the audience through eye contact, relatable examples, or interactive elements like Q&A sessions.
  3. Technical Snags are more specific to technical presentations but are nonetheless common. This can range from software glitches to difficulties presenting complex data in an easily digestible form.
  4. Pacing: Novices often struggle with pacing—rushing through the material or dragging on too long, which can lose the audience’s interest.
  5. Lack of Clarity: Technical jargon, complicated sentence structures, or a poorly organized flow can confuse the audience and make the presentation less effective.

Tips For Technical Speakers

I regularly watch videos of other technical speakers and attend different conferences, and occasionally I find it curious to why people do one thing or another. Call it a “common sense”, but I see no reason in  doing something or acting in some way.

It’s my 4th DevReach after helping with the organization of the first one in 2006 (I guess) and I’ll outline several mistakes I’ve noticed during some of the talks.

Long Pauses

When you have a 30-60-90 min talk long pauses are annoying. During a conversation a pause often means that a question has been asked, and it causes confusion during a talk.

There are normal pauses at the end of a sentence, or during a real question, otherwise frequent pauses increase the tension. The session should be a story with beginning, explanation and conclusion, just like an essay.

Low Energy

A session has two purposes – to teach and inspire. Technical speakers who don’t inspire are labeled as boring or not helpful, this is not the reason for them to be invited to conferences with 50, 250, 1000 attendees.

Dozens of Questions

A trained professional can play with the audience and ask questions here and there, it’s fine.

But asking continuous questions with multiple answers is weird, people are shouting different responses, audio recording after the session is either blurry, or only the pauses are heard (no responses either). “Raise your hand” questions are fine to get some attention back to the talk.

Broken Demos

We all know the “demo effect” with “Shit, that used to work 1 hour ago”. It happens. But if that happens to all of your demos, than probably something is deeply wrong. Try to bring your notebook with the right setup and make sure that your environment is in tact.

“Just for the Demo”

Teaching people on best practices is quite important. Occasionally, for the sake of the demo, one might do a “not really the standard” sort of demo, but it should be avoided and the best practice should be explained and eventually provided after the session in the demo (uploaded on GitHub for example).

Text-Driven Presentation

Many professional speakers avoid text at all, maybe except for a slide title/heading. Even if you need to add some demos and bullets, make sure they are short, strict, clear and visible for the back rows.

If you really need your audience to read that, make sure it’s possible. This reflects the color scheme as well. If you want to provide more text for the people, prepare another text or presentation with text but in addition to the original one.

Wrong Audience

Try to provide as much details for what sort of audience is the talk appropriate for. Bringing the “big guns” for beginners or wasting 80% of the session time for 101 issues with full room of experts is just bad planning.

Lack of/Useless Examples

No matter what your subject is, you need to provide examples.

Elaborate on why a session important for the audience, where does it apply, or how can people benefit from it in practice. Code samples, use cases, real use scenarios are necessary. Don’t skip that part or provide useless examples.

There are various issues one could notice during a session, but that’s a gist of common troubles for beginning speakers. Try to use your common sense, imagine being in the hall, what would be awesome to see from a technical speaker and what would be annoying.

Ask in advance what sort of audience attends if you are not aware of the fact, and find out how many people (averagely) would attend a session etc.


My name is Mario Peshev, a global SME Business Advisor running digital businesses for 20 the past years.

Born in Bulgaria, Europe, I gained diverse management experience through my training work across Europe, North America, and the Arab world. With 10,000+ hours in consulting and training for organizations like SAP, VMware, CERN, I’ve dedicated a huge amount of my time to helping hundreds of SMEs growing in different stages of the business lifecycle.

My martech agency DevriX grew past 50 people and ranks as a top 10 WordPress global agency and Growth Blueprint, my advisory firm, has served 400+ SME founders and executives with monthly ongoing strategy sessions.


Follow me at:

Latest Editions:

Browse by Category

Latest Answers: