Our project head is a genius software architect, a gentle and considerate person in general, a geek by nature and delicate by voice. But, at times, we (my teammates and I) differ in opinions -- especially of software architecture issues, system design issues, UI issues, etc., with our leader.

When and how (if ever) should we express the difference in opinions?

  • 12
    Nobodys perfect. What about a meeting clarifying potential issues?
    – user1249
    Commented Jul 22, 2011 at 7:48
  • 2
    Any time you feel your ideas are better, and have actual proofs. Allow him to have his way if your way isn't significantly better.
    – SF.
    Commented Jul 22, 2011 at 12:48
  • 1
    If there are problems with his ideas, then figure out what those problems are and ask him how we will deal with them when the come. If there is no solution (because it's a bad idea) then share your version and see if he spots any problems.
    – Xeoncross
    Commented Jul 22, 2011 at 17:24
  • 4
    "Confront" is a pretty strong and negative word Commented Jul 22, 2011 at 18:29
  • 1
    Even geniuses have their faults. Commented Jul 23, 2011 at 1:28

14 Answers 14


Suppose you think your boss is wrong. You have three options

  • do what he says and end up frustrated thinking that you do something stupid - not very good long term
  • tell him he's an idiot - he'll either ignore it or you get communication problems - gets you nothing or hurts you.
  • tell him that you have specific concerns about the ideas he proposes and explain those concerns - any good boss will explain his position and then you can get to a decision that is good for the business. It's quite likely you'll see that his idea is better than yours and you've been ignoring something very important.

Always think of the outcome. In most cases you don't want to be right for the sake of being right, you just have to do good job. The third option helps achieve that.

  • 1
    +1 for "specific concerns" - this is usually the hardest part to get right, but it's the most important for any constructive discussion. Commented Jul 22, 2011 at 7:46
  • 9
    +1 for specific concerns about the ideas and Always think of the outcome -- i agree
    – treecoder
    Commented Jul 22, 2011 at 8:39
  • 2
    Good answer, but I think it should be more emphasized that the first two options are BAD. Also don't forget that he is the boss - if he has listened to your concerns and doesn't change his opinion, then you have to go along with with him. Commented Jul 22, 2011 at 15:24
  • 1
    You could just ask him about the design before running in with loaded words like "confront" and "opinions." In the end since you're talking about opinion instead of cold, hard O(n) fact it's his job to keep everyone on the same page. Consider that you call him a genius and then describe how you repeatedly disagree with him on major issues. Follow @sharptooth advice, have facts and not opinions, and respect his genius and the job he's trying to do while being second-guessed on every decision. Commented Jul 22, 2011 at 16:56
  • 1
    @SnOrfus - that phrasing could put him on the defensive with the 'your design' vs 'my thought' wording. Safer might be "In the current design, would <this> be a problem? I was wondering if doing <that> would overcome the problem?"
    – Kris C
    Commented Jul 24, 2011 at 13:44

Treat him the same way - gently and respectfully when voicing opposition.


Being professional implies being respectful of your peers and superiors, it doesn't mean you can't disagree it just means it should be polite and respectful in nature.

When my team has a doubt or dissenting opinion about my directions, I look at it as an opportunity for education, both for myself and my team members.

  • I look at it as an opportunity for education -- that's easier said than done :)
    – treecoder
    Commented Jul 23, 2011 at 12:15

Isn't this an example of the old either-aggressive-or-passive fallacy?

The classic third option is assertiveness, which allows for constructive criticism and polite disagreement.

Equally important - accepting constructive criticism (without necessarily agreeing with it), and accepting reasonable disagreement (not getting obsessed with a who-is-right-and-who-is-wrong contest).


And at the end of the day, a kind of passivity - deferring to your superior - is always going to be necessary. He is the one with ultimate responsibility for the decision - ability, authority and responsibility aren't the same thing, but they at least should go together.

BTW - "People Skills" by Robert Bolton is a good (and fairly cheap) book for things like this - listening skills, assertiveness, and more.



Since you seem to respect him and he seems like a smart guy, why not just ask him in the following way:

"How does your method/way/architecture handle x problem?" If it doesn't, say something like: "Well how about doing it like this, that way x problem is handled?"

This way, you can learn if he's thought of "x problem" already and if he has learn something. Or if he hasn't he'll think about it and maybe use your solution or think of another one (maybe you'll work it out together).

I wish I could come up with a more concrete example, but I think you should be able to get the idea.

I don't think you'll get anywhere going to your boss first, especially if he isn't a programmer or something like that.

And there is no need say his way is bad, but by asking how it handles certain situations he might realize a problem or be able to tell you why it isn't a problem.

I hope this helps.


By using the word CONFRONT, you're showing that you are not approaching the problem with the right mindset.

It's not a confrontation. It's not hostile. It's not belligerent or angry. It's a discussion of different approaches and costs and benefits.

Don't go in with six guns blazing. Just tell him something you've thought of. "What if we were to do it like this?" Who knows, you might convince him.

And if you don't - and sometimes you won't - remember that he may well know things you don't, about budgets, schedules, requirements, other priorities and so forth. He's not necessarily an idiot just because he disagrees with you.

  • Don't go in with six guns blazing. Just tell him something you've thought of -- we always do it like that -- but situation does get awkward -- and it looks like confrontation
    – treecoder
    Commented Jul 22, 2011 at 12:58
  • 3
    There are physical things you can do that will help - uncross your arms, smile, speak slowly in a lower volume than usual. Emphasize that you want the best for the team and the company - it's not who's right and who's wrong, but what's the best solution. I KNOW this is hard to do - it's hard for me too, but it's the most effective way to convince someone. Your approach should be the exact opposite of confrontation. Master this and you will be the Stephen Seagall of developers. :) Commented Jul 22, 2011 at 14:11

It's not wrong to doubt on any decisions, or a given design/software architecture. Unless when you just started your first job, in which case you'll be wrong 99% of the time cause you lack some parts of the bigger picture.

When you (and/or the team) differ in opinions, ask the project leader if he has some time to discuss it, or maybe even plan a small meeting (15-30 mins). Vent your own opinion in a respectful way and listen why he made his decision otherwise. If I see how you described him, he'll be happy to discuss and share his insights on the problem. He won't say "because I said so" (such people exist sadly). In that case just ignore your own opinion if you want to keep your job, or vent it and leave for another job because you'll become unhappy.

A good discussion can end up in several ways:

  • The project lead will accept your solution as a better way to solve the problem (and he maybe learned a new technology, pattern, ... which he didn't have much experience with yet).
  • You and the team get to see a bigger part of the picture, or get a good explanation why you should do it in this and that way. You'll learn something new and understand that the initial solution was the correct one, or you'll maybe even find a way to improve it with the new information (although at some point you'll have to agree).
  • The discussion doesn't help and you still disagree. Suck it up and implement his solution (because he'll most likely have more experience), or leave.

Anyway, you should see it as an opportunity to learn and as long as you keep it civilized and respectful, you'll have great experiences with these discussions.

  • 1
    Even if you are wrong 99% of the time, it's still good to voice your doubt so that you can learn why you are wrong. Of course, if after half a year you are still wrong 99% of the time, something else may be up :) Commented Jul 22, 2011 at 7:47
  • ...most likely have more experience -- that's true, but at times i (and we) can't resist the urge to argue
    – treecoder
    Commented Jul 22, 2011 at 8:35
  • Why not, as long as you keep it respectful. It will be an opportunity to learn for everybody.
    – Bart
    Commented Jul 22, 2011 at 10:42
  • @MadKeithV -- that's fine, as long as you're not wasting others' productive time when watching and listening would be almost as effective. There are no stupid questions, but there are also only so many hours in the day.
    – mwigdahl
    Commented Jul 22, 2011 at 14:01

Just Bring it up!

In the most civil and cleaver way I can, I will typically say "I'm concerned with this aspect, what are your thoughts on this potential problem?"

I'll put the ball in his court to educate me.


The #1 sign of a mature developer and manager is that they are able to admit to being wrong. Demonstrate to your boss first that all of you are perfectly willing to admit you are wrong when you are, and make it clear to your boss that you expect the same courtesy from them.

If you have a good boss (and you say you do) this will generally not be a problem at all! You will see you can have constructive discussion and come to the best solution for all of you.

One thing you need to be careful about: make sure that most of the time you have actual technical, well-founded reasons to doubt the proposed design. "It feels wrong" is generally not enough, and will not contribute to a constructive discussion. If this happens too often, your boss will have no choice but to short-circuit the "discussion" (which is fact-light, so not really a discussion) and say "sorry guys, but you will do what I suggested until you can demonstrate with facts why some other idea is clearly better.".

That's why your boss is the boss - to make the decisions that developers may find hard to make.


In my opinion and how I generally behave with my boss:

Always give your opinion and do it ASAP whilst the topic is hot. Ideally when you are having a scrum over a new issue or project rather than doing later when you have gathered your courage and decisions have already set.

You should suggest your opinions, concerns, issues openly and ensure that they come across as suggestions or concerns rather than imposing that it must be done in such a way.

Make a habit out of it and become a better communicator, team member and in turn, a better team. A good team will talk openly about the negative things aswell as the positive. A good team leader will listen to his/her team and make a decision taking in to consideration the information provided.

Good luck.


If he is as good architect as you describe just approach him in an educated way with logical and specific reasons for your concerns.

If you have the time/resources try to make some tests of the scenarios that would prove that you are right, having some data on your side is a huge plus.

Once you talk with him he can only:

a) Agree with you: Problem solved!

b) Reject them and explain you why: maybe after all is you the one who is wrong.

c) Reject them without reason: if he is being unreasonable and you are totally sure, express your concern to the project responsible, in this case you really need cold data, and if you can, the support of the other members of the team. It won't make the architect very happy, but is the ethical thing to do (imagine you were designing a building and saw a flaw in the structure...)


My question is: when and how (whether?) to express the differences in opinions.

Absolutely Yes is the answer. Unless you have some greater out-of-your-control rare situation where even the potential of turbulence or losing your job because of it is so great, you should confront others when you have differing opinions.

The real key here is When and How.

1st the 'When': Every environment is different but some places have weekly meeting or open / round table discussions where bringing up certain topics is the appropriate arena to do this. The main thing you do not want to do is make it like you are belittling or making public some personal design argument that is between you and only 1 or 2 others. The people you are challenging will not appreciate being challenged and maybe even embarrassed in public. For these situations, try to schedule a meeting 1 on 1 with the person(s) in question to detail your thoughts.

2nd the 'How': If you are going to a Senior person, make sure you have all your ducks in a row on backing your thoughts. You can’t just ramble into a senior level persons office saying "All web forms must be stopped, and we must do MVC!". When asked "Why?" and you say, "Well that's what everyone is doing and it is in all the magazines", it will not go far. Be prepared for back-and-forth discussion and being asked about justifying your thoughts on architecture, coding, design, best practices, etc. If you have examples of working code to justify (i.e. a little test harness to prove a thought) this may help as well. The important thing here is to not get into an ego battle or allow the emotions to rise up. This will result in a non-productive meeting and you may not be able to get any of your ideas implemented.

In the end if you have solid, justifiable, and logical suggestions then they should be taken into account. However, also be prepared that there are just some unreasonable people in this world that don't want to listen to anyone but themselves. Hopefully you are not backed into a corner with this type of personality.

Good Luck!

  • The real key here is When and How. -- not just real -- tricky and delicate also
    – treecoder
    Commented Jul 23, 2011 at 4:57

I'm not sure how you can become a brilliant software architect without making mistakes and being questioned about them. I think it is safe to assume that he has been in this situation before.

Smart, mature, professional people cannot long resist the lure of better ideas. Even if he is upset at first by having his ideas questioned, in the end he should come around and you'll gain respect for it. If he's neither mature nor professional you have a bigger problem, and perhaps this will shine a light on it.


If he is a professional architect, he will respect and accept a second opinion. However, in any case you need to well prepare the alternative based on facts / expertise and also well present it. Also keep in mind, that regarding architecture there a basically two different possibilities for such issues:

  1. One approach / design can be simply right or wrong, like in math 2+2=4 and not five. In case it is wrong you need to come up with the right solution asap, based on factual objections.
  2. By far the most topics in system design are possible approaches which are not exclusive. There are other alternatives also working, which to choose depends on experience, flavour, bias, overall picture etc. In order not to oversee a possibly better approach there are usually presentations and discussions, when developers are encouraged to speak up and share their opinion. But also keep in mind, there are periods for discussions and periods for implementing, in agile programming these stages are well defined.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.