I'm fairly young in my career, and thus hold a bottom-of-the-totem position on my team. However, thanks to the rapid development of the industry, my recent education has introduced me to theories and "best practices" that many of my older coworkers, who have been in the field for a long time but have let their education and training lapse, do not understand.

One coworker in particular has a habit of grabbing onto the first solution he sees and arguing in favor of it as long as possible, "digging his heels in" as it were. (He does this to everyone, even other senior staff members or superiors of his). He eventually comes around when the alternate idea really is better, and I don't mind taking the time to explain, but I want to avoid sounding impertinent or implying that I know more than he does (I definitely don't, but what do know is very different than what he knows). How can I handle a lengthy conversation like this without coming off as arrogant?

  • @enderland Definitely similar, but my question has a different focus. This guy does listen, but it's a long conversation in the mean time, and I'm much better with a few sentences than a lengthy conversation Dec 6, 2012 at 15:10
  • 2
    Also a comment (this is not really an answer) - the reality is that just because something is better to you doesn't mean it's better to the company. "Best practices" for optimizing speed might create maintenance nightmares later because of cryptic code. Refactoring bad code/architecture takes a lot of time, which directly translates to $$$. A less superior but more understandable data model might be easier to maintain. etc. There are plenty of examples where better coding practices doesn't result in the best long term result for the company. Be very aware of this when saying "best practices."
    – enderland
    Dec 6, 2012 at 22:30
  • @enderland I didn't mean to give the impression I'm always right or that I somehow magically have all the answers or that I'm disregarding business needs. This is exactly the kind of tone I'm trying to learn how to not take. That said, I do feel like I retract my position when there's a reason to, and mostly I try to push the issue with things like putting re-usable code into a method instead of copy-pasting. (I intentionally didn't give examples in the OP to avoid this discussion, but that one should be fairly universal) Dec 7, 2012 at 0:46
  • @enderland And yet, the senior dev should be able to explain the advantage of their approach in the terms you just used. If they can't, then the suspicion that ego or laziness or something else is involved is a valid one. Feb 11, 2017 at 11:08

6 Answers 6


In a perfect world ideas should have no ownership, and egos should not be tied to technical decisions. Unfortunately cool heads don't always prevail.

Regardless of how senior or junior you are, the best way to prove a technical point is to use the Socratic method. That way the person arrives at the correct decision themselves (with your guidance) and not by you telling them and directly contradicting them. It avoids putting people on the defensive.


Mr. Man says: "Here is how we do things, and it's the best way because I have been doing this for 35 years and I KNOW!"

You say: "Great, but how does this compare with this other approach that people have been taking?"

Mr. Man says: "Oh, well I guess some people just do this this and that, but my way is better!"

You say: "So what then is the advantage/disadvantage of this this and that?"

... and you keep doing this until the truth is distilled. That way there's no arguments, no egos, and in the off chance that you are actually wrong you won't look like a fool :).

  • 13
    I also find that by asking questions rather than making assertions is helpful in attaining consensus without appearing arrogant or condescending. Dec 6, 2012 at 18:19
  • 2
    I am trying to picture a very junior bottom of the ladder person having an uninterrupted back and forth with the CEO while the whole room just listens ... not seeing it.
    – NickNo
    Jun 9, 2014 at 2:29
  • @NastyNick of course my answer assumes you are in position to be having a conversation in the first place. The OP asked "how best to handle a lengthy conversation".
    – MrFox
    Jun 9, 2014 at 13:49
  • Got it. OP is a dreamer too I see. lol
    – NickNo
    Jun 9, 2014 at 14:00
  • 2
    "You keep doing this until the truth is distilled". Or until the other guy has enough of being pestered by you and will not ever listen to one thing you say, and will tell anyone else to never listen to one thing you say.
    – gnasher729
    Feb 11, 2017 at 11:22

How to Win Friends and Influence People has more than a few ideas that I'd consider worth noting first here:

Fundamental Techniques in Handling People

  1. Don't criticize, condemn, or complain.
  2. Give honest and sincere appreciation.
  3. Arouse in the other person an eager want.

Six Ways to Make People Like You

  1. Become genuinely interested in other people.
  2. Smile.
  3. Remember that a person's name is, to that person, the sweetest and most important sound in any language.
  4. Be a good listener. Encourage others to talk about themselves.
  5. Talk in terms of the other person's interest.
  6. Make the other person feel important – and do it sincerely.

Twelve Ways to Win People to Your Way of Thinking

  1. The only way to get the best of an argument is to avoid it.
  2. Show respect for the other person's opinions. Never say "You're Wrong."
  3. If you're wrong, admit it quickly and emphatically.
  4. Begin in a friendly way.
  5. Start with questions to which the other person will answer yes.
  6. Let the other person do a great deal of the talking.
  7. Let the other person feel the idea is his or hers.
  8. Try honestly to see things from the other person's point of view.
  9. Be sympathetic with the other person's ideas and desires.
  10. Appeal to the nobler motives.
  11. Dramatize your ideas.
  12. Throw down a challenge.

Be a Leader: How to Change People Without Giving Offense or Arousing Resentment

  1. Begin with praise and honest appreciation.
  2. Call attention to people's mistakes indirectly.
  3. Talk about your own mistakes before criticizing the other person.
  4. Ask questions instead of giving direct orders.
  5. Let the other person save face.
  6. Praise every improvement.
  7. Give the other person a fine reputation to live up to.
  8. Use encouragement. Make the fault seem easy to correct.
  9. Make the other person happy about doing what you suggest.

The first group of points is something to note when you do talk but there is also something to be said for understanding how he works through stuff. Perhaps he prefers to talk through things rather than think things through and then talk about the conclusion. Could be an extrovert/introvert clash where you may be more introverted and he is more extroverted.

  • 2
    I agree with the first point at the beginning. When you go offensive, then people get upset, angry or threatened and then they might not be open to your ideas or to even talking to you. Try to be as polite and tactful as possible. Persuade them instead of bulldozing them. This will not guarantee success, but will at least make the discussion more pleasant.
    – sid smith
    Jun 29, 2014 at 21:56
  • @sidsmith : the second advantage is that you prepare the way for the next debate. If you attack directly, people will get defensive at your sight. If you treat them as interesting human beings as in this excellent answer, then next time, they'll listen to you.
    – gazzz0x2z
    Feb 11, 2017 at 7:42

However, thanks to the rapid development of the industry, my recent education has introduced me to theories and "best practices" that many of my older coworkers, who have been in the field for a long time but have let their education and training lapse, do not understand.

I'd like to pick this apart. It may help you present your arguments better.

  1. New doesn't always mean better. There are a lot of new developments in software that are an improvement, there are just as many that have failed. Your older coworkers may recognize that what you see as a new "best practice" was hot back in 1985 and tanked.
  2. I feel like you imply that by not constantly getting formal education and training, that your older coworkers are somehow failing. They've got years more on the job experience representing a significant amount of informal education and training.

I get the impression that you and the coworker who "digs his heels in" are actually both a little stubborn. Nothing wrong with that, but you have to acknowledge it. An opening phrase might be, "OK I would like to understand your solution. After you share that I would like to share mine." You need to genuinely listen and understand his ideas and that should open the door to let your ideas be heard and understood.

I've been in the same place. My current team regularly butts heads with our greybeards. Theres quite a bit of back and forth, but we usually wind up with workable solutions to our problems. Experience is just as valuable as new methodologies.

  • 2
    I think I disagree with your #2. No matter how much experience, if a developer is not always learning then they are failing. Experience is only useful if it was educational and you were open-minded enough to take something from it.
    – MrFox
    Dec 6, 2012 at 21:15
  • 1
    I think there's a difference between 'learning' and 'education & training'. My reading of Freiheit's words is that s/he is referring to formal education and I would agree that formal training is not a requirement for learning
    – Dancrumb
    Dec 6, 2012 at 21:41
  • Edited for clarity. My intent was as Dancrumb says.
    – Freiheit
    Dec 6, 2012 at 21:43
  • Formal education is definitely not a requirement. However, I was hired precisely because I have the formal training and can bring that perspective to the team. Nine times out of ten I'm trying to learn what he has to teach me; however, that's a lot easier role to be in so I'm not having issues with that part of our dynamic. Dec 7, 2012 at 0:41
  • 3
    @Freiheit in that case I agree. Formal education, particularly after many years on the job, doesn't make a big difference. Yamikuronue - are you sure that that is the reason you were hired? We hire kids from hard programs from the best universities but that is meant to act as a quality filter. It's not that they learned a lot of stuff that we need, it's that they are capable of learning a lot of stuff - and that's what we need.
    – MrFox
    Dec 7, 2012 at 15:09

I regularly watched this play out in my development team, and in the past it has been a source of frustration and even conflict between team members. I have also seen this in other organisations when we are "rolling out" a solution, and encounter a similar resistance.

In addition to all of the excellent communication advice already posted, I would add one key point : have patience

A team can only move forward at the pace of its slowest member, which means that if you need to bring this person along with you, they have to dictate the pace of change.

Depending on their personality type, they may need time to absorp and process new information, especially if it is challenging some of their training and work habits.

If you reach a "log jam", it can be better to park the discussion so that you can reflect on it overnight.

On some of our more strategic issues, the person "pushing" the new ideas just had to stop pushing, leave space and wait for the other person to fully process what has been said.

Over time, as your "new" ideas deliver, you will find that the experienced staff members start to grow in their confidence in your methods. They will still play "devils advocate" in meetings, but these discussions will feel less confrontational. You will be able to predict the areas where they won't be comfortable, and have examples and discussions ready.

Another solution that worked well with our team was the introduction of a "lunchtime talks", where staff presented ideas and concepts as a presentation over lunch, or on the back of a meeting. This allowed ideas to be worked on before they were critical to a projects success.


I have no idea whether it applies in this case, but I've certainly known a few people (including myself, at times) who've intentionally taken somewhat contrary positions (even ones they/I knew were, shall we say, less than optimal) to give the "new guy" a chance to explain his position, and really follow through on the arguments in its favor.

At least in my case, that was often because I knew there were some others on the team with a little bit of a passive-aggressive streak (or something similar anyway). If/when a new idea was accepted too easily/quickly, they soon started thinking of objections to it privately -- but rather than openly voicing those objections where they could be considered and answered, they frequently quit carrying out their part of the plan, or in even (usually subtly) sabotaging it.

Voicing the objections up-front and openly gave the idea's proponent(s) a chance to reply to the objections. If they hadn't been openly voiced, the passive-aggressive types would have thought up the same objections -- but would not have voiced them openly so the proponent could reply. In their minds, the problems quickly became insurmountable -- at which point there was obviously no reason for them to make any effort to overcome the problems, or even stay out of the way of others.

I should add, however, that in most cases the objections had at least enough substance that the plan was improved at least a little bit by them. The mere fact that an idea is good doesn't automatically mean it's flawless. Again, however, it's at least as much about perception as reality -- a few minor modifications to a plan can get people on the team to think of it much more as their own plan to which they made a real contribution, removing a lot of the perception that it's entirely the product of "the arrogant new guy."

From your side, it's worth considering perceptions as well. Even minor changes in wording can make a big difference -- I know the phrase "best practice" is popular right now, but I generally try to avoid it, and I think it's at least worth considering doing so as well.

Saying "XYZ is the current best practice" directly implies that alternatives are inferior (and, quite honestly, makes you sound a bit arrogant). Saying "I know it's kind of new and untried, but I wonder if we could consider something kind of along the lines of XYZ?" will still get people to think about using XYZ, but without nearly as much implication that what they're currently doing is wrong, that they know less than you about the problem at hand, etc.

Which do you think is likely to work better in the end: the best idea being seen as belonging to only one person, and "shoved down the throat" of the rest of team, or a good enough idea, with the whole team behind it?

  • Jerry, I agree with you! Do the best job you can. Often times, a team member maybe a genius, but is too timid to share the bright ideas...the company and the genius end up losing. Egos are a reality in the corporate world, trying not to rock other people's (boat) ego creates a wishy washy delivery and percerception. This kind of approach also lacks direction.
    – Fiona
    Feb 11, 2017 at 2:54

Many useful answer but I feel another perspective might be useful. Sounding arrogant is to some extent in the eye of the beholder. In some cultures (national and/or corporate) sharing knowledge or correcting a superior might simply be unacceptable.

One answer is therefore: Realize this, try to accept it and do your job as good as you can. If you feel this is impairing your own development or future career or if there are legal ramifications or risks for third parties, this might not be the right course of action but ultimately you are not responsible for the whole company and all your coworkers.

Besides, is your team unable to function or deliver anything of value? Can you explain some practical benefits to your preferred approach (as opposed to it being new and considered a “best practice”)? If not, it would suggest that your coworkers' approach is good enough.

You must log in to answer this question.

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