I believe I have specialized expertise in a specific area of technology. At work, I often have to sit through presentations given by others in the same area of technology that I have expertise on.

The presentations are of two types:

  1. declarative presentations that declare the current architecture and design of internal projects in that area of technology,
  2. training sessions to bring the rest of the company up-to-date with what is going on in this area of technology.

My problem:

I often, but not always, happen to know more than the presenter, and I become restless when I see that the presenter/trainer is presenting the topic in a more confusing manner than it should be, or is wrong about certain things. I find myself constantly nitpicking (in my mind) what the presenter is saying. Sometimes I do end up voicing my opinion or correcting the presenter. Sometimes the audience may ask a question to the presenter which the presenter would answer. I would find the answer very unsatisfactory and I would end up speaking for a while and answering the audience's question in my own words.

I am worried that this kind of behavior may be obnoxious to others. I am also worried that it may affect the morale of the presenter. In many cases, the presenter is very junior to me and I am their team-lead. I want everyone in my team (presenter or not) to feel valued and important.

How do you think I should handle situations like this? One thing I feel is that I should probably keep quiet and let the presenter be in complete control of the session whether he is speaking correctly or incorrectly. It is his session and unless asked for, I should not be offering feedback or correcting mistakes. Have you been in a situation like this? What strategies did you develop to deal with such situations?

  • 75
    If you are the team-lead then why are they giving the presentation rather than you? If you delegate the presentation then live with the outcome. – paparazzo Dec 12 '17 at 15:06
  • 81
    @Paparazzi I don't understand your question. What prevents a junior from presenting something? Is there an unwritten rule that the team-lead only must do all presentations? Our company culture is like this: If a developer develops a certain module or service, he/she owns it completely, so he/she presents it, trains the rest of the company about it, and so on. Sometimes, he/she might be the trainer and I may be the student because I did not work on or oversee the module/service he/she developed. – Lone Learner Dec 12 '17 at 15:09
  • 87
    Plus it is very good experience for juniors to learn to do the presentations. That is part of how juniors get to be seniors. – HLGEM Dec 12 '17 at 15:26
  • 29
    Is it possible if they are a junior on your team for them to run their presentations by you before they present it to others so you can check it's factually correct? – Tom Bowen Dec 12 '17 at 15:50
  • 19
    @LoneLearner Are you sure that juniors who have to give presentations would view "first running them by the more experienced person and getting feedback & tips before going live" as "additional overhead" and not "a very welcome help?" – Angew is no longer proud of SO Dec 13 '17 at 8:59

As a speaker, I never want to be nitpicked or corrected. I can sometimes handle it when it's important and relevant for this audience. Usually, it isn't. Usually, I've decided to simplify things because I want to get a concept across, so it's not my lack of knowledge, it's a choice.

And yes, I have been in the audience and cringed a little at things I have heard from the stage. Here's what I try:

When the audience looks confused (and only when the audience looks confused) a question-as-suggestion may help without correcting:

Are you saying it's kind of like [analogy that you know is good]?

Is the key thing here the [key thing that isn't being talked about because they're down a rathole on something nonkey]?

When the audience looks happy as can be, but you know a vital important concept is being skipped, write yourself a note. If, by the next break or the end of the presentation, it is still not covered, approach the presenter one-on-one:

You didn't mention the security risk of X at all. I really think that should be included. Can you make sure you cover that next time?

When something completely wrong is being said, and it would hurt the company for it to go uncorrected, you need to say something, but you can spare feelings:

I've found that opinions on X are not uniform. You're saying it's very useful, but our coding guidelines (which I wrote) say never to use it. I'm concerned about A, B, and C and I think in this application Y would be a much better choice. Are you able to cover Y in this session at all?

I would reserve this only for the sorts of situations in which it's ok to correct someone in front of others, meaning you're trying to prevent a dangerous situation, not just "actually the second Darren was played by..."

I've been in the room when a "question" is just "you're wrong" and the thing is, it rarely enlightens the room. The presenter has the stage. It's usually just an interruption that lowers the quality of the rest of the session because the presenter is jangled now. Reserve it for exceptional circumstances. If you can help, help. That's more important than being right.

  • 46
    If you find yourself in a situation where you have to take issue with something the presenter is saying during the talk, I think it helps to nod in agreement later when the speaker says something you agree with. After you say something critical, the speaker will probably be more conscious of your reaction and it will help for them to know that you are really on their side and not just trying to be confrontational. – Brian Moths Dec 13 '17 at 1:59
  • 3
    To add to this excellent answer: Do you guys peer review your feature branches? Questioning rather than asserting, leading with positive feedback, presenting alternative "options" rather than the "right way forward" - that's exactly the type phrasing that one ought to employ in reviews and in which I enjoy my code being reviewed the most as well. This extends to all types of feedback, guidance and criticism. Assuming that your team does reviews and that you as a senior lead have given many: Handle presentation critiquing the same way. Avoid sugarcoating, preserve dignity. – Johannes Pille Dec 14 '17 at 8:35
  • I usually find this kind of suggestion-as-a-question thing to be transparent and condescending. – MissMonicaE Dec 14 '17 at 18:05
  • I think it's also very difficult to do question-as-suggestion for any 'general knowledge' presentations. These types of presentations already come with a "go try it and see what you get" caveat and don't pretend to get into nuanced views. Unless it's a math problem and the answer is literally wrong, correcting generalities = condescending. – Martin Dec 15 '17 at 1:58

You're the team lead, so you should be mentoring in this respect. Offer feedback, but do this away from the team so that you're not publically undermining your team members.

Be supportive of what they do right, underplay what they do wrong (and address that separately). In the meetings, concentrate only on what's important and correct those points, but in a guiding fashion rather than pointing out that they're wrong.

  • 13
    I admit I have to improve on my own social skills here. May I ask you for a concrete example for a very hypothetical situation? Say a junior says in the presentation, "This module be better written in C because we all know how slow Java and Python are", and say I know from experience that the same thing written in Java or even Python (say with numpy) would be just as fast and a lot safer due to automatic memory management, how could I phrase my feedback without appearing critical or arrogant? – Lone Learner Dec 12 '17 at 15:06
  • 45
    @LoneLearner For that issue, frame it historically. Early implementations of Java were indeed slow, but there has been a lot of progress in its performance. More generally, pick up points of agreement and then transition to where you differ. – Patricia Shanahan Dec 12 '17 at 15:32
  • 36
    And this is definitely something you want to deal with in mentoring not during the presentation. – HLGEM Dec 12 '17 at 15:59
  • 4
    And what kind of organisation/team lead allows a dev to go off doing a bunch of things without running it past you first? Autonomy is one thing, but teamwork, mentoring and standards are quite another. The issue stems from not having control over the team - discovering how your product is built in a presentation by one of your staff is too late. Lone Learner needs to become a mentor and a leader up front, not sniping from the back. – LoztInSpace Dec 13 '17 at 23:03
  • 2
    @LoneLearner "You were right to highlight the importance of speed for this module. I think you might be surprised at the performance you can actually get from Java or Python in this situation though, and of course you get the benefits of … , so I'd encourage people not to overlook that option." – nekomatic Dec 14 '17 at 9:14

Have the presenter preview the presentation with you when the person is your junior and help him or her strengthen it. That is a part of your job as their boss. It is certainly what my bosses did for me when I was junior and what I do for people junior to me now.

What you want to do is make certain the person doing the presentation gets more in-depth knowledge to be able to answer questions, so make sure to give that knowledge to that person on the topic at hand and tell them to be free to call on you if the questions get outside the area they are familiar with. You might even give the presenter a hand signal you will use when you would like to add something. It looks better if he calls on you to add something than if you barge in. You are also then able to correct any errors or misconceptions before they are made in public.

My view on giving presentations (and I have given thousands since I used to teach) is that you should have roughly twice as much knowledge on the subject as the amount you are presenting to be able to handle questions.

Now you are going to have to contain yourself when helping the junior prep for the presentation. At all times, you need to be thinking about what the audience needs not how much you could say about something. An audience new to a subject often doesn't yet have the background to understand all the nuances you know and to give them to them too soon will likely make you lose their attention and they won't learn what they need to know.

If you really need to answer a question during the presentation that you felt was not answered good enough, then start with a polite phrase like, "To add some more detail to that..." But remember, the level of detail you know is not necessarily the level of detail that people just learning the subject need to know or are ready to know. So only do it when the knowledge is critical to what they will be doing as beginners in the subject. And pay attention to the way people are responding. If eyes start to glaze over, then it is time to stop.

Then you also need to work a bit on dealing with being the "Smartest person" in the room. When you think (even correctly) that you are the only person in the room who is smart (and that smart is the best and highest value a person can have), then that will make you project an unconscious arrogance which will turn people off.

One thing I read once was that it is very hard for people to communicate with people who are not within about 20 points of their own IQ and I have found it to be true in many cases. This make it hard for very smart people to communicate with less smart people.

So if you are truly extremely smart, you have to make an effort to learn how to communicate at the level that other people will understand. The onus is on you for this as you can't change other people, only yourself. You need to tone down your vocabulary and think more about what they need to understand that what you want to present to them.

I've worked with genius level people and people who were not very smart. All of them had value as people and as co-workers. You are not better because you have more knowledge. I think from what you wrote, you are starting to tend in this direction, but it is something you need to consciously do. And it's tricky because you don't want to come across as talking down either.

Now when the presentations are from outside your group, then the calculus of when to add detail to an answer is different. You want your people to shine and you want to support them only when they are floundering. Outside your group, you want to consider the politics of the situation.

Do you need to make the point that your part of the organization has the real expertise in this area? Then you may need to jump in more often. Is the presentation to senior managers who are not really concerned with the nitpicky technical details, maybe less often. Is the person doing the presentation your manager? Definitely, less often. If you have concerns about something he or she said, then approach in private and have that person send out a clarification in an email. Is the person doing the presentation someone who you will be working closely with or a client? Be aware of the nuances of political realities as much as you are aware of the nuances of your technical subject.

  • "That is a part of your job as their boss" in my experience, a team lead is not a boss. – zzzzBov Dec 12 '17 at 15:42
  • 8
    A team lead is a boss even if not a supervisor. They are generally responsible for the technical quality of the product. Any lead who doesn't act as a boss is doing his or her team a disservice. Yes, you may have to work with your manager to deal with a performance problem, but mentoring is ALWAYS part of a team leads job. It is one of the most critical parts. – HLGEM Dec 12 '17 at 15:49
  • 3
    "boss - a person in charge of a worker or organization." That is the definition I'm using for that particular word. It appears that you seem to be using some other definition. It sounds to me like you're conflating "boss" with "mentor". If that's the case, then I agree that mentorship is absolutely part of the team lead role, however the term "boss" does not convey that meaning. – zzzzBov Dec 12 '17 at 16:10
  • Being in charge of a product or technical quality != being in charge of a worker or organization. You're not a boss just because you're a team lead or mentor. – Martin Dec 15 '17 at 1:55


Your behavior is, unequivocally annoying to everyone around you. Speaking as a former teacher, we referred to people that did this as "that guy". The one who holds themselves forth as an expert on all things related. You should listen. Quietly, critically but non-judgmentally. Evaluate what is being said, perhaps you can learn something, even if it is how to correct the person later in order to help them learn.

Disrupting a presentation because you "know better" is irritating and is not only damaging to the morale of the presenter, but also to your reputation, as you will be seen as the "know-it-all" that no one wants to present in front of. If you're so knowledgeable in the subject, give the presentation yourself.

Also, just a note, thinking you're more knowledgeable is self-important nonsense. You may have more knowledge or experience, but you don't have the same perspective as others. Many times I've known something to be true 100%, but by listening I learned how others percieved it. In a lot of cases I was still right, but by listening I knew how they were approaching a situation and was able to shift their perceptions around so they could see the flaws they missed by going at it a certain way.

  • Another way to say this is -- public corrections during the presentation can create a hostile learning environment, not just for the speaker and commenter, but for the entire audience. Those kinds of conversations have been proven to reduce retention and engagement for everyone. – Martin Dec 15 '17 at 1:56
  • 2
    When doing Karate, and maybe having to redo a kata I had done 1000 times before, I learned to "check my own feet". If the teacher said to some beginner, "your feet are wrong", I did not think "dumb beginner", I checked my own feet, and often they were indeed not placed perfectly. If someone is talking about something you already know, listen hard: is he telling you something new? Has he seen something you missed? Maybe there is a detail you have been missing all this time. – RedSonja Dec 18 '17 at 8:00

Unless the presenter says something so outrageously, horrendously wrong that it will literally cause harm in the next few minutes, your intervention can wait until the discussion time at the end of the talk. (Of course that means someone - preferably not you - should make sure the speaker keeps to time, so that there is discussion time).

Then if you think something was unclear, you could say

I'd like to go back to the section where you talked about thing, because I think that's a really important part to understand. Could we go through that explanation again please, so we can be sure that everyone's got it?

If you think there was missing information, or alternative views that should be considered, you could try

I'd like to open a discussion on thing. Does everyone agree with what presenter said, or does anyone have a different experience?

If you think something that was said is wrong, there's

I'd like to challenge what you said about thing, because that didn't agree with my experience - can you give us some more background on why you say that?


I was surprised to hear you say that thing, because I've always understood that other thing. Can you say some more about what led you to that conclusion?

In all these cases, try and make it a discussion involving the audience rather than a confrontation between you and the presenter. If it turns out that everyone else had the same misconception as them (you could even ask for a show of hands), they won't feel nearly so bad. Maybe someone else has an analogy for explaining a topic that's even better than yours. Maybe someone has taken a particular interest in a topic and found out something that's even more up-to-date than your own knowledge!

I'm a great fan of the I'd like to challenge ..., because construction, because it puts the focus on the facts, not the person, and emphasises that all assumptions are open to challenge with evidence. When your juniors start using it on you, you're doing something right.


Phrase a comment as a genuine question

This is best to do in time allotted to questions. Different speakers have different styles (some prefer to answer questions during presentation, most however like it at the end).

When in question phase, formulate a question for example:

I've noticed during the presentation you've decided to do A with B, however I've found that doing it with C is a better option in the context of D. Any particular reason you choose the B technique?

To which response might be:

I've presented the B technique since it's easier to use for beginners, of course someone as experienced as you would use C technique.

However it might also be:

We don't use C technique anymore because it has been proven to cause severe maiming in edge cases. You should check X and Y that describe how the technique B even though less efficient greatly reduces a risk of accidental maiming.

You'd learn something new and as a bonus don't make an ass of yourself when you attempt to correct someone only to find out that your approach could lead to someone loosing a limb.


There's probably more than two ways to do this but here's two:

  • Create a better presenter. Have them give the presentation to you privately and confirm ahead of time that the information is correct - if there's a mispeak you can either nod or actually interrupt (everyone knows you're the lead and responsible for the correctness of what is being offered).

    Stay out of it as much as you can, nothing worse than an interrupter; unless he's your boss and he keeps roasting you in front of everyone.

    [Joke: See other question: "Why does my boss keep interrupting our presentations and nit-picking."].

    The best time for feedback is prior to the group presentation. It can be as simple as running over a few key points or you can ask to hear the presentation beforehand. That instills confidence in the presenter and might let you sit at ease during the presentation.

    During the presentation feedback might be given utilizing a carefully worded question and offering a clarification if it turns out a fault of the presenter and not of your listening skills. Interruptions should be limited to more critical parts and minor points let go. If you need to interrupt a lot there's something wrong with the delivery or the receipt of the information, who's fault is that? Review and criticism in front of a group disrupts the person and might reduce the confidence of everyone in the information being provided.

    Afterwards is a great time to review if you feel unable to give the whole presentation your stamp of approval. Review the notes you took and ask about why some particular advice was offered as opposed to another preferred explanation. Explain what and how you want particular information to be presented.

  • Alternately make the "presentation" a "Training Session on Giving Presentations". This will be easier when representing established knowledge.

    Have each person get up and do part of the presentation. It's easy if it's a "slideshow". Look how simplistic many presentations are when a new Phone or CPU is being released, often there's little that goes over people's heads.

    Then you'll have a team of expert presenters, if you need someone you can ask anyone. No different than being in school and being asked to get up here and teach.

    Using the teaching method permits you to provide welcomed feedback during the presentation and polish the results to your satisfaction. Next time this information session is offered you ought to have no cause to interrupt.

Not everyone is a public speaker and not everyone is equally good at giving explanations or responding to questions. If the presentation isn't good and interesting you run the risk of meetings that some people don't like going to and cause restlessness in the room.

Just because you know more about the information than the presenter doesn't mean that everyone else does too, or welcomes your comments. You could 'guest speak' on a particular area of expertise if you can establish ahead of time that the person isn't ready with some of the information.

Holding questions (feedback/answers) until the end is often appreciated.


The right or wrong way to go about this lies within the team itself since this is at work. There should be a little more familiarity with each other and presenters should recognize when they are not the authority. A public speaker would be given much more slack.

Send an email or hold a meeting and get feedback on what the audience should do when they disagree with the speaker. If I'm at a public presentation and everyone leaves misinformed, it's not going to negatively impact my job, so I can afford to leave it alone. At my workplace, I would think everyone would want someone to speak up if this information is going to do harm. Everyone may want to wait and have comments handled after the talk. Or your team may decide that it's in everyone's best interest to bring it up and discuss during the presentation.

Most people get stuck having to present something at work and they are rarely an expert in the area. This is going to happen with several juniors and one senior. Also, many developers are not strong public speakers, so the goal should be to help them develop that skill even if you have to refrain from a technical correction. Be tactful. Be professional. Let everyone know you are trying to help them. Hopefully if you create the right environment, everyone will be open to a few corrections.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .