Dealing with "Why didn't you do it some other way?" questions

Question

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:

1. How can I prevent this type of questioning in this specific context?
2. How can I discuss with management with regards to the consequences of those questions and their posture relative to it.
3. 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:

1. I personally prefer technique Z instead of X.
2. X could be good for ABC reasons, but for DEF reasons I've chosen Z.
3. I've preliminary assessed X and found ABC problems with it.
4. 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:

1. 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.
2. 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.
3. 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.
4. 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:

1. They can make me look bad, as if I didn't considered obvious and better options, and just did things the wrong way.
2. 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.
3. 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.
4. 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.

Answer 1

Take a step back and relax a minute. It's pretty unlikely that these questions are intended as simply a means to torment you, and taking them as personal attacks is doing no one any good including yourself.

First, Assume Good Intent

Assume people asking these questions are genuinely curious and trying to both learn and to help you with suggestions. Your response won't differ and it will give you less emotional trauma.

I assume, for example, the reason you're presenting isn't just to show how smart you are and flex on your audience. So the audience learning and benefiting from your presentation is likely of value for you. That inevitably involves answering questions and exposing your thought process.

Also, unless you think you are perfect, this is an opportunity to hear about other approaches from people. If you haven't heard of approach X, instead of resenting them for mentioning it, maybe it's a good opportunity to go learn about something new later.

Second, Understand What They Are Asking

Consider what people may mean when they ask people if they tried approach X. It can vary.

1. Do you know about approach X? Maybe you don't, in which case this could be helpful for next time if nothing else.
2. Did you evaluate X vs your other approach? I have projects of my own to do coming up and I'd love to know your thinking on pros and cons.
3. I think maybe approach X might have been better for some reasons and would like to give that feedback. Maybe because specific mitigations are needed now (e.g. "Support will need to be ready with something for the thing that commonly goes wrong with your selected approach) or just, again, for the future.
4. I want you to expand on this so the others here learn. As a manager I will often ask the "why X" question in a design review even though I already know the answer - if I know, for example, my engineer evaluated two options as part of their design I may ask out loud "what caused you to choose X over Y" specifically so that their thinking and work can be exposed to others who can learn from it. Because again, we're not presenting this just for kicks, we're doing it to hopefully improve the organization.

Answer Briefly and Constructively

You don't have to go on at length but you also don't look good simply being dismissive.

1. If you know about other option X and considered it, you say "Yes, I considered using X, but when I designed this solution I considered factors Y and Z to lead me to pick my approach instead." This lets them know yes, you know about X, and you had a reason to pick it, and you look smart to all the attendees. If they try to derail and talk about it at length, then you say, in a friendly and positive way, "Great, I'd love to talk about the pros and cons, maybe we can schedule some time to do that! But in the interests of time let's keep moving along here..."

2. If you didn't know about option X, or weren't aware of some problem with it they're bringing up, be humble not bullheaded. Being willing and able to learn is the hallmark of a great technologist and responding to a new approach with "bah" will cause an immediate black mark to appear in most of your audience's head about your ability and professionalism. You can say "Oh, I've never used X, I got the job done with this approach but would love to learn more about it." Or if there's a valid concern with your approach, engage with it! "You're right, I'll look at that in the next version" is strength not weakness. If they really are just beating an implementation choice point to death, you can request it be taken offline, or say "That's also a valid approach I'm sure, there's more than one way to accomplish a goal. This is working pretty well though, <transition to next slide/thought>".

Avoiding the Problem

If you're getting a lot of design questions in your post-implementation review, it is a sign you needed to get input on your design in the first place. Do a design review before implementation. Better yet, get input from people on your design before it's final. There is a Japanese concept called "nemawashi" that Lean practitioners have adopted, because getting that buy-in ahead of time makes the actual meetings go super smoothly. Your "culture problem" may be whole implementations getting air-dropped on people not prepared for them and who had no input into them, in which case they're not really the problem, right?

Conclusion

If questions or challenges really do take a lot of time and are derailing your presentation time-wise, use the techniques above to push on; defer them to the end or offline. But your question reeks of a negative attitude (How do I address "repeat offenders" with their manager? Really?). You keep dropping comments trying to explain "no but you see these questions are the bad ones..." I know you think that, but it's clear you've allowed your perceptions to become colored, and a number of other people are detecting it as well. You should probably introspect a little more about it.

Don't fall into arrogance, or feigning arrogance to stifle ideas because of a lack of confidence in your approach. Be ready to teach and more ready to learn, and you'll be more successful for it. Get people's input ahead of time (during design, at design review, during implementation) to avoid having so much of it on these occasions. If you assume good faith and act in good faith, this won't be a problem. I know the "kind of question" you mean and we've all had those, and this is the way to eliminate them as a problem - and that's 1/3 how to handle them and 2/3 adjusting your attitude about them.

Answer 2

Turn it right back around on the querent.

Q: Why did you do it X instead of Y?

You: Why do you think Y would be a better approach?

Whatever you do, don't go on the defensive. Turn it right back around on the person who is the problem.

If they continue to press, you can always use the standard"

Well, I'd rather not wander too far off topic here, but we could discuss this offline later.

or

Let's stay focused on what we achieved.

Do not let the person drag you off topic, especially not in a way that will leave you playing defense, because you are right, it will make you look weak and incompetent.

If you must bring it up to management, bring it up in a way that makes you look concerned rather than angry or accusatory.

Boss, that last meeting has me a bit concerned. I know that Jake wants us to do the best we can, but I feel that the meeting was a poor time to bring it up.

Or, you could even discuss with your boss, your point #4 and tell him that such distractions would lead to a "painfully long technical discussion, which would be a waste of time for everyone else in the meeting."

You want the distractions to be seen as just that, distractions.

Answer 3

This is a problem I run into from time to time as well. You're right that saying "it's too late for that kind of feedback" or "I didn't feel like putting in the extra effort to use that method" won't make you sound good and will likely make the suggester unhappy, regardless of how correct or true those responses might be. I'd guess you probably have three main goals for an answer to this sort of question:

• Demonstrate your solution is reasonable and competent
• Have the asker be satisfied and not offended
• Avoid getting sucked into a futile debate or discussion of the reasons for a decision which will not be revisited

I do this by acknowledging there are multiple ways to solve any problem, and their solution may work as well as any other, but I decided to go the route I went and am confident it will solve the problem. So I might say something like the following when asked when I used technology X and not tech Y:

There are lots of technologies that would be perfectly suitable in this situation, and I'm sure tech Y is one of them. However we decided to use tech X and are confident it's able to meet the needs of the project. Hopefully you will agree after you see the solution I'm presenting today.

This accomplishes all three goals. It never implies the person is stupid or wrong; it acknowledges reasonable people could make different decisions and their decision is as valid as yours. You just didn't happen to go that way. At the same time, you reiterate your solution is valid and point to solid evidence they can't easily refute: you successfully solved the problem. It also refocuses the conversation onto the purpose of your presentation and encourages feedback to be based on that. As a bonus, it should discourage future questions along the same lines, since you've indicated other approaches aren't relevant to the conversation, even if they're valid. So that helps avoid wasting time and effort by keeping things on track.

If they continue to push their technology as better, I generally respond with something like this:

There are always trade-offs between technologies, so no choice will be the best in every way. However we are confident tech X will work just fine, and are too far into development to revisit that decision. I'd be happy to discuss it with you more in depth for future projects, so let's set up a time to talk after this meeting.

Again, you aren't calling them wrong, and you are even admitting that their solution may be better in some ways. You're also saying your solution will work and the decision is made, and that any further discussion will be outside of the current topic. This reiterates your choice is also valid and alternatives aren't a useful topic at the moment.

Committing to talk about a topic later is a great way to make people feel heard without derailing your current meeting. If you have someone taking notes or you have a whiteboard handy, make a point of adding a note to get together to discuss the topic later. You're staying firm in your message that your decision is made and correct, preventing your meeting from being derailed, and demonstrating a willingness to hear what other people have to say.

I have used this strategy countless times, and it's always worked well for me. I've also seen others use it, and the people who do tend to have more meetings that actually accomplish their purpose instead of needlessly getting into the weeds. You might still get sucked into a conversation you'd rather not have at all, but at least you can have it privately and still accomplish what you need to during your meeting/presentation.

Answer 4

When they ask "Why didn't you do it this other way?" You can say, "Because I asked all of you for feedback X months ago on numerous occasions and you didn't speak up. I did hear from an Architect who agreed with my approach. Also I've profiled my solution and here are the numbers..." Always get some people onboard with your approach early on, if possible. It's sometimes helpful when you run into ridiculous questions. They will support you.

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 of salesman word claims based idea.

Confidence is what they read. If you get flustered by a question it will make them think that you don't know what you're talking about. I'm not saying I agree with that, just saying it's how it is. If you think about all of the challenges people have made to your past work, you should be able to anticipate what challenges you will face next time and prepare for them. Have answers ready. Have slide show images ready to go.

How can I prevent this type of questioning in this specific context?

Don't. Embrace questions and answer them decisively. Just take every question 100% on face value and don't try to read the asker's motive into it. The audience will see if they are trying to play games. You don't need to make a big deal of it.

How can I discuss with management with regards to the consequences of those questions and their posture relative to it.

If the person asking the question has a huge influence then you should be talking to them more. Otherwise just ignore. Find some architect(s) to discuss things with. They probably have the ear of management and will back you up.

How should I respond to repeated offenders of this type of questioning?

Take the high road. Ignore. The less you let it bother you the sooner they will stop trying to push your buttons.

Answer 5

1. How can I prevent this type of questioning in this specific context?

You likely can't prevent it, at least by yourself. What you might be able to do though is control when the questions are asked. You could perhaps request that questions be held until the end of your presentation. You can then strive to make your decision making clear during your talk. You can also offer to discuss such things "off-line", especially if your presentation fills most/all of the allotted meeting time. If questions follow you as non-compliance reports that's a less effective strategy though, so beware. Further addressing these questions will likely require help from your manager, which leads nicely into your next question.

2. How can I discuss with management with regards to the consequences of those questions and their posture relative to it?

In discussions with management you should always frame your issue in terms of business costs. You've already started to do this in your question, mentioning

[Addressing a set of these questions] took me (calendar) months to archive this non-compliance report and maybe a week's worth of office hours from me and other people.

You spending that amount of time on frivolous questions should be of great interest to your manager, and they should be able to give you company and individual-specific help in addressing it. That said, if your managers are supportive of this type of questioning you'll need to reassess your position on it. Maybe there really is something valuable to to these questions or this style of interaction. Maybe the management style of this company is one that doesn't suit you. Maybe both.

If this is a part of company wide culture changing it can be quite difficult, and is likely well outside the scope of your position. I once worked at a company where all meetings had entirely to many attendees, and the way to score career points was to be seen to be participating. It lead to a lot of the stuff you mention - questions just designed to draw (non-technical management) attention to the presence of the question-asker.

3. How should I respond to repeated offenders of this type of questioning?

Offering to discuss offline is good, and asking someone to write up their questions can be even better. Having questions written and emailed requires the questioner to invest some of their own (non-meeting) time into the questions. It also makes them more traceable so you can a) show them to your own manager and ask if they need to be answered and b) answer the actual questions rather than just having a rambling conversation.

Answer 6

One idea is to steer the presentation towards objective results. Start with the requirements and then provide details of what you came up with, i.e. the solution/strategy/idea regarding the requirement.

"Why didn't you do it some other way?" or "Why not doing/using X instead?"

Example Response: Our team needed to improve the performance of the API-Client from 10rps to 100 requests per second. The solution I put together has fulfilled these requirements.

If they keep pushing you could add: Sure we could do it a million other ways, but the requirement was 100 requests per second. Have the requirements changed?

Answer 7

This is inappropriate behaviour. You are presenting the finished work, that's not the time to be asking those questions. A project post-mortem would be the right time, certainly not in front of people external to the company.

Unfortunately this behaviour is also quite common. Some people can't seem to resist doing it. They may not even be aware of the effect it is having.

There are various reasons why people do it. Some feel insecure when the spotlight is on someone else or when someone else appears to be succeeding. Perhaps they fear their own work won't live up to this standard, or that making other people look bad somehow helps them. Some people just have to question everything, perhaps because they think it makes them look smart.

The best way to handle it is to quietly talk to them afterwards. Explain that while you welcome questions there is a time and a place for them, and your presentation was not it. As well as breaking up the flow of your presentation it both undermines you and makes the group as a whole look bad.

I had to do that once with a guy who couldn't keep it to himself in front of customers and he immediately stopped doing it.

Answer 8

It sounds like you work in a big company. At my company everybody is so busy working on their own projects, they don't have time or interest to meddle in somebody else's. In fact, in my company people have to actively seek out advice or strategy alternatives. In big companies, you sometimes have the reverse problem, as you have experienced.

Unfortunately in a big company environment, you have to defend your approach and your intellectual turf, so to speak, from encroachment. Here are the basics:

(1) Perform well. The bottom line is results. If you are not getting results, you will be meddled with. If you are producing results, people will either leave you alone or at least back off when you tell them to. If you are getting a lot of "feedback" that can translate to "start getting some results buddy or we will fire your ass".

(2) Secrecy. People can't meddle with stuff they don't know about. If you have a sensitive technology or an intricate strategy that could be harmed by meddling, it is important to keep it secret.

(3) Documentation. I have a friend who used to work at gigantic companies, like GM. He had this button on his bulletin board that said "We have charts and graph to back us up, so fuck off." It's a joke, but there is an element of truth to it. Back up your strategy with hard documents. Charts and graphs usually trump windbags in meeting rooms.

(4) Making Acknowledgements. Sometimes people don't really want to meddle with your strategy, they just want credit for it. It's a good idea to have some way to have some way to acknowledge help from other people so they can get partial credit for your success. You basically make a deal: leave me alone and I will put you on the acknowledgements.

The four points above are the biggies.

Answer 9

Basically, when someone does something like that he/she is trying to influence you.

Influence is a hot topic these days, but I consider it part of the "dark side" of human interaction.

Just say you believe that the way I did it was, in your opinion, the best way to have done it, but you don't justify your decisions once made (outside of the chain of command, that is).

Answer 10

I just don't understand what is wrong with these questions. I think they're completely legit and useful. Actually I like such questions.

If you choose one way to do something you should explain why it was selected.

Probably you're looking bad because you don't know it yourself.

You can give different reasons, for example:

• I did a research and found out that this way is better
• I have more experience with this
• It's more simple way
• Performance is better
• I just like it more

If you don't want to be interrupted during presentation, ask them to ask questions after it's completed.