1. About
  2. Features
  3. Explore

In a few days' time, a collaborator is going to be giving a talk to our research group. He has sent me the slides in advance (just to check that it all runs OK on our system). Having looked over the slides, I have noticed a mistake in his methods (a major assumption that is not just unsupported, but definitely incorrect) that unfortunately invalidates his entire analysis. This mistake is potentially fixable, but only by going back to square one, and the new analysis could (and I suspect probably will) yield different results.

Obviously, I need to raise this with him, but when is the most tactful time to do this? My concern is that if I raise the problem immediately, it leaves him with too little time to redo the analysis before his presentation, and leaves him stewing over it knowing that his prepared work is invalid. Also, I wasn't specifically asked to give feedback at this stage. On the other hand, if I leave it until the talk, it means that I have to bring it up in front of the rest of the research group, and he has no time to prepare a response.

I feel like both situations leave me looking cruel. Which option is preferable, or is there an alternative approach that I've not thought of?

[And to anticipate the comments, I am 99% sure that there is an important mistake and that it's not just my misinterpretation]

1 Answer 1

On the other hand, if I leave it until the talk, it means that I have to bring it up in front of the rest of the research group, and he has no time to prepare a response.

Not necessarily. You have the option of bringing it up with your collaborator privately, after the talk. In general, a talk is not the ideal time to figure out whether the work presented is correct: that makes things stressful for the presenter, and unless the group is small and well-chosen, likely there will be some people there who are not invested enough / do not have enough background to want or be able to follow such a discussion.

If you talk to your collaborator afterwards, then this is less awkward in case you are mistaken or there is some kind of misunderstanding. (In my experience, a lot of perceived mistakes in other people's work turns out to be some kind of misunderstanding.) If you are right, you can still offer him help to fix the problem, in a way which might not work in the context of a talk. In particular, in order to recognize and correct the error your collaborator will likely have to stop and think for more than a minute or two, which is the one thing that is almost impossible in a talk.

Maybe you feel bad having a talk in your research group that you strongly suspect is wrong. Well, certainly if it turns out to be wrong that information will be conveyed to the group: your collaborator can send out new slides, a new paper, and so forth. Moreover, just because the results are flawed doesn't necessarily mean the talk itself isn't worthwhile: it still may be.

It could be that you feel strongly that the material is so flawed that it is not worth subjecting your research group to a talk about it. That's a tough situation. Fortunately you've collaborated with your collaborator, so you may have some insight into how he would behave if he learned a few days before his talk that you think his results are seriously flawed. If you've given this kind of negative feedback to him before and he's reacted well, I would risk it and let him know ASAP what you think is wrong. If he agrees, maybe offer him the opportunity to reschedule.

For what it's worth, here's one data point: if someone that I worked with found what they thought was a flaw in my work, I would like them to tell me immediately. I would much rather cancel a talk then give a talk that I later found out was wrong, and if given a few days' notice I would probably just switch to something else.