The scenario is usually similar to this: I am presenting my work, which involves software related decisions and scientific related methods. I have almost no direct management from my actual managers who also know very little about the technicalities of my work, but I have many colleagues with varying levels of knowledge on the tools and theories I employ.
During presentation meetings (sometimes with external people involved), where I'm presenting completed deliveries of my work (software features, analysis reports and so on), I am often questioned by colleagues something in the lines of "Why didn't you do it some other way?" or "Why not doing/using X instead?". And I'm starting to believe this has become an issue within my workspace culture. To be honest, I'm not the only one dealing with this problem.
TL, DR: the question I'm posing here is:
- How can I prevent this type of questioning in this specific context?
- How can I discuss with management with regards to the consequences of those questions and their posture relative to it.
- How should I respond to repeated offenders of this type of questioning?
Details/Context:
Regarding the answers, they often come from a selection of the following, with varying levels of sugar coating:
- I personally prefer technique Z instead of X.
- X could be good for ABC reasons, but for DEF reasons I've chosen Z.
- I've preliminary assessed X and found ABC problems with it.
- Summarized technical reasons.
To be clear, these are often stupid questions or just very early high-level ideas. I would actually be glad if the question was worth the "why didn't I think of this before?", and either way I would gladly welcome ideas in a brainstorming meeting or in a personal conversation while I'm starting to work with something, but they are quite annoying when I'm delivering finished (even if unpolished) work. The blunt honest answers would be respectively:
- I never used technique X. I know it's unnecessary, and until presented better reason, I don't want to face the burden of learning/implementing it. Alternative: This is mostly a matter of personal preference, so I've made my choice, as I am doing the actual work.
- I think Z simply does not work, you have no proof otherwise, and should waste your time and not mine if you think it's a good idea.
- It seemed borderline unfeasible, if not simply impossible to use X, but maybe you could be lucky enough to find the right code ready to use on GitHub. But I didn't find it, and you should have checked and concept-proved it before suggesting after I'm done proceeding with Z. Alternative: Would be nice if we had an expert in X, which I'm not, and neither are you.
- Painfully long technical discussion, which would be a waste of time for everyone else in the meeting.
The problem with the blunt honesty is that I could come across as rude and/or incompetent, especially when talking in front of managers who can't really distinguish brilliant ideas and suggestions from stupid ideas, nor standard technique usage from sketchy paper or salesman word claims based idea. They also wouldn't tell the difference between me saying "I don't know how to solve Riemann's Hypothesis problem" and "I don't know how to use some features of a programming language" (i.e. something that may take centuries and geniuses to solve, vs. something any programmer can do in a month). The managers have never asked for anyone to justify their questioning or make their homework to contribute.
It happened once that one such question was made in form of a non-compliance report, which usually should be used to point out requirements not being met or deviations from specifications. It took me (calendar) months to archive this non-compliance report and maybe a week's worth of office hours from me and other people. That could have been avoided if the responsible manager had just rejected the report in terms of "this is just a suggestion, talk to him instead". Yet, he just overlooked it and passed the report along. It also happened that a decision making based on an analysis of mine was postponed due to these questionings, and while I was not tasked with handling the questionings, no work was ever shown for it, and after a long while the decision was just taken as I recommended. (I think either the halting or the lack of feedback was inappropriate).
So, the problem with the questions themselves is:
- They can make me look bad, as if I didn't considered obvious and better options, and just did things the wrong way.
- They require little effort on the asker, but have in the past required much dedication on my part, with little to no gain for the company or product.
- Even when constructive, they are mistimed. I would have appreciated ideas during conceptual development especially if given in a personal conversation, but once code is fully tested and ready for production, I honestly dislike someone suggesting I should go back to conceptual design for no good reason.
- Sometimes, they pretty much sound like public criticism. And even if later I take my long while to explain things to the asker in person, I'm stuck with a feeling that I've been publicly offended but received apologies in private. However, it seems excessive to demand for public apologies.