I am software developer. During last five years I have tried to grab knowledge from various technical areas and from colleagues. And now I landed up in a company where the people in my team are either have only manager role/ scrum master, QA's, BA's' and developers with only a few years of experience. But in technical discussions, all of them have a say about implementation, bandwidths, timelines, even though they are unaware of what the path is going to be for development of certain features.

Now the thing is whenever some issue comes up in our project, I can hear the other developers in the team/ members discussing the various reasons that why that may have happened, passing their own judgement. However at that point in time I listen to them silently because I have seen people getting offended when you try to correct them. However when the dust settles, I do add my opinion to the discussion.

The actual problem lies in the fact when you provide them with a solution, then the people with the knowledge gained from the little Google search start challenging your knowledge and suggest that we should go with the other solution without understanding the problem completely. As a result one more task gets added in my list, to explain the pros and cons of the other approach.

Now My Question is how to handle such challenges, the challenges which are raised by people in your team having no knowledge of your domain and still you have to politely explain to them why the approach you suggest is the best/better then the approach they suggests, (even though they are unaware of the domain.)

Should I be answerable? Or Should I take part in the conversations? Or just let them discuss, and let them maintain the essence that they know it better.

  • 9
    If you have the domain knowledge, then why can't you simply explain why your approach is better?
    – sf02
    Oct 3, 2019 at 17:59
  • 2
    @sf02 because some you have to work with are “all mouth and no trousers”...
    – Solar Mike
    Oct 3, 2019 at 18:02
  • 5
    @SolarMike These are team members on the project, so if OP is going to reject their suggestions he should be capable of explaining why. I think correcting these colleagues would be less offensive than simply ignoring their suggestions.
    – sf02
    Oct 3, 2019 at 18:23
  • @sf02 because I know upfront that they know nothing about the stuff they are asking and they are either gonna get convinced or will just delay the final decision a few days which even then will be the same solution as suggested by the expert before.
    – nobalG
    Oct 4, 2019 at 7:45
  • @sf02 for reference , see this
    – nobalG
    Oct 4, 2019 at 7:55

6 Answers 6


I too am a software developer.

The answerers telling you that "if you're actually a domain expert you should be able to explain it" and quoting Einstein are not actually answering your question. The situation you find yourself in is extremely common.

I am fortunate enough to have a ratio of software developers to management of 5:1. The managers have been wrong enough times that they now know that they can trust the devs. Not everyone is so fortunate.

  1. Work on your communication skills. I have found as time has gone on that the more metaphors I use the better people understand me. I have actually learned a lot about communicating to a wide audience by studying the parables of Jesus. I prefer talking to computers over people. This was the biggest adjustment I had to make in my professional life.
  2. Do not wait until the end of the meeting to contribute to the conversation. Many people who become decision-makers become that because they BS their way through things in a confident manner. Not contributing to a conversation because you're waiting for all the hot air to dissipate may be read by these people as a form of acquiescence. Having a game plan for the meeting before you go in so you can cast your vision early will go a long way to shortening the meetings and getting the blowhards to trust you.
  3. Do not communicate condescendingly. You want them to trust you, not to feel stupid. Be positive and enthusiastic about your solution.
  4. Learn what the decision makers care about. Some times it is time. If you explain in an understandable way (see point 1) why solution A will take 3 weeks and solution B will take 10 weeks, you will probably convince the decision-maker to go with your solution. UNLESS that decision-maker doesn't care about timelines. Find out what the decision-makers value and sell your solution along those lines. Saying, "The framework you're suggesting is out of date" won't matter to a decision-maker concerned primarily with timeline. It may have more sway on a decision-maker tormented by security vulnerabilities.
  5. Talk with a decision-maker directly beside or above you about your solution and why it is better before the meeting. They will advocate for you in the meeting, sometimes without knowing why. They simply feel smarter because you've gotten them on the inside of the better solution before the meeting. And these people love nothing more than feeling smarter than everyone else in the room. Give them that warm fuzzy feeling.
  6. Make sure your solution is actually the best solution. Don't become one of these people who wants it your way. Genuinely want it the best way. If you don't, all of this is a waste of time.

As far as not offering to implement their solution.... In some places that will get you fired. At the least it will make you unpopular. In my company you will be reassigned to a miserable job and kept there until you quit. My philosophy about work is to do your best work, even if you know it isn't your idea. Even if you know your idea is better. Do not intentionally delay your implementation of their solution.

The long term goal is to educate the decision-makers about the domain. If you focus on this goal rather than on the short-term goal of having your way, you will eventually end up with the trust of the decision-makers. And that generally leads to a better workplace experience, compensation, etc. Your situation is frustrating. I have been there. During that time it can be easy to see it as a me vs. them problem. Viewing it as a team problem is the right way to view it.


When I was a beginner many years ago, there was a situation when I understood something, the PM understood it, but the rest of the team did not. My explanations were not very useful. The discussions only closed temporarily until they opened again on the same topic.

I was initially confused by the approach of the PM, but I eventually understood it and adopted it. It was very helpful throughout the years.

The Method

Do not explain.

Let them present a solution. Then ask a question. Let them answer. Ask them another question. Let them answer. Continue until they understand that their solution is flawed.

Repeat until no more flawed solutions exist.

If a good solution is found, adopt it. If no other solution can be generated by the team, suggest a solution. Receive questions. Provide answers.

In the end, everybody will have to be happy - even if some egos might get hurt a little.

Clarification: All the procedure above happens during EXACTLY one meeting, not trial and error throughout the life of the project.

Worst case: a follow up meeting may be necessary, if something needs to be actually tested in the real world.

Gradually, they will come to understand that you understand things better and faster, and they will eventually come to trust you and let you talk first - what you actually want.

  • repeat, repeat, repeat... that can happen very late and can be very damaging from many points of view, to very many people. I strongly disagree.
    – Solar Mike
    Oct 16, 2019 at 12:58
  • 2
    "which wastes your time and their time" - actually I see it as invested time, rather than wasted - invested in their education. In this way, you become a coach, a knowledge leader, and they have a chance to learn things the correct way, without actually reinventing the wheel.
    – virolino
    Oct 16, 2019 at 13:07
  • 1
    I like this answer because it encourages the other employees to feel like they invented the solution themselves.... and thus improves buy in on their part. Oct 16, 2019 at 20:48
  • 2
    FWIW: That ask questions until they realize their own problem is "The Socratic Method" - wikihow.com/Argue-Using-the-Socratic-Method Oct 17, 2019 at 21:21
  • 1
    I think this is definitely one of the better ways to address this issue, if it works. The problem I've run into is that some people are just unreasonable. For example, most of my more aggravating experiences around this are people who question the value of abstraction layers. The approach you lay out is problematic here because the abstraction layer solves for a problem that doesn't exist (yet) and we can't get past the YAGNI arguments regardless of how many times that particular solution has been re-engineered. If you get to that point, you may have to push the amateurs out of the discussion.
    – JimmyJames
    Oct 18, 2019 at 17:07

You make your suggestion and if they don’t accept it then let them choose their own.

But don’t offer to do their solution...

If they then come back to you as it has failed or struggled, re-offer your solution. Worked for me in several spheres but don’t offer to repair their solution : that way madness lies...

  • 1
    I think this is the right approach. As they say in the boy scouts: learning by doing. Just a warning though: some people will not get it anyway... Oct 3, 2019 at 19:40
  • Well this is the most practical thing I can do, however I am still worried for the explanations which I have to give at later stage for the failure of their decisions
    – nobalG
    Oct 4, 2019 at 7:53
  • 2
    @nobalG sometimes I find the explanations take longer than just doing the task...
    – Solar Mike
    Oct 4, 2019 at 7:59
  • "If they then come back to you as it has failed or struggled" - that can happen very late and can be very damaging from many points of view, to very many people. I strongly disagree.
    – virolino
    Oct 16, 2019 at 12:54
  • 1
    @Nelson: The discussion is not about managers, neither the question, nor the answers. It is about employees, with vs. without experience.
    – virolino
    Oct 17, 2019 at 7:16

If you can’t explain it simply, you don’t understand it well enough.

~ Albert Einstein

You need to be able to explain your work in a way that makes sense to someone with no knowledge of your field. The more complicated your work gets the better you have to get at explaining. When you learn to explain your work you mostly get to know your field even better. It's one thing to be able to write good code but it takes a lot more knowledge to explain why your code is good, and it takes even more to explain that to someone who might not know a thing about programming. Practice your explaining skills.

In my experience most situations like the ones you are describing arise from you knowing a lot, or thinking you do (no offense, but it happens to me a lot), and not being able to explain it in a way that others grasp it. This leads to others being hesitant to follow your lead and you getting frustrated with them for not grasping the stupidity of their ideas (especially if they come from one Google search). Again, the hard way's the best way and that's to practice your explaining skills. Learn to draw on examples that they understand, use metaphors, do what it takes to make them understand you. In the end they might still not listen to you but it's a skill that will help you immensely in just about every area of your life.

  • 4
    There is a reverse also: “There are no simple answers to complex problems.” - Valerio Massimo Manfredi That is, not everything can be explained "simple" to anybody - not when having to actually do some serious technical job. Explaining black holes to a grandmother using metaphors is one thing. Using metaphors when designing an airport's air traffic management systems - is another thing. If the engineers there understand ONLY metaphors but not engineering, they should actually go search for another job.
    – virolino
    Oct 17, 2019 at 12:52
  • 1
    And another, also from Einstein: “Everything should be made as simple as possible, but no simpler.” Some things are complicated, and they should remain complicated. Simplifying them more, leads to undesirable results.
    – virolino
    Oct 17, 2019 at 12:55
  • @virolino I agree that there are things that are complicated and will remain complicated. Solutions 'or answers' can't be kept simple but the explanation of that solution can be made at least so simple so that it's understandable. I am not suggesting simple solutions, just simple explanations.
    – user74534
    Oct 18, 2019 at 6:41
  • I understood your intent, both in the answer and in the comment. But your quote greatly oversimplified things, no matter how you look at it. And it can be hurtful for somebody who does not know how to read your answer.
    – virolino
    Oct 18, 2019 at 6:47
  • I am not so sure. Your first quote refers to solutions and has nothing to do with explanations. An answer is not the same as an explanation and an infinitely complex answer (or solution) can have a very simple explanation. The second one is, again, not directly referring to explanations. It's also not a very clear quote because what is the difference between simple and 'too simple'? It leaves a lot of room for arguments. I appreciate your last comment and edited my answer to make it sound less like 'this is the only way'.
    – user74534
    Oct 18, 2019 at 7:10

You need to back up your suggestions and your solutions with scientific arguments and proofs, design thinking methodology. Don't through singular solutions share your opinion with structured procedures

  • What do you mean by this phrase, "Don't through singular solutions share your opinion with structured procedures"? It doesn't quite make sense
    – Draken
    Oct 10, 2019 at 7:29
  • 2
    Suggesting a solution in one phrase does is not be convincing or powerful, better to make a detailed presentation of all the arguments or behind the solution as well as the emplementation of its procedure. Oct 11, 2019 at 9:01

A few things I would like to suggest here.

  • Keep an open mind. Often people get lost in minute details and makes mistakes, that are basic.
  • If you are challenging someone else's solution, then be ready to be challenged back. Many times explaining things to someone, sharpens the idea.
  • Concealed talent brings no reputation. If you want to be accepted as an expert, reflect your knowledge, in your work.
  • Take part and offer suggestions in these "discussions" only if they are genuine and productive and if not, walk away.

You must log in to answer this question.

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