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?
Suppose you think your boss is wrong. You have three options
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.
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.
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).
http://en.wikipedia.org/wiki/Assertiveness
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.
http://www.amazon.com/People-Skills-Yourself-Resolve-Conflicts/dp/067162248X
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.
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:
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.
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!
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:
