How can I debate technical ideas without being perceived as arrogant by my coworkers?

Question

I'm somewhat new in this job (6 months) as a frontend/backend developer. My boss, whom I consider a really capable and smart manager, has a system for measuring developer performance, in which I constantly get many more points than the second best developer.

I'm trying my best to win these points since my boss gives all developers above average a free day per month.

Last week my boss had a talk with me, saying that some of my coworkers feel that I'm arrogant. He said that probably was because of the large difference in performance, and because I'm too assertive in technical debates. He told me to "mellow down" my attitude, and to always look for solutions that include all opinions in technical discussions.

I'm trying to be more passive but I feel like I'm walking on eggshells when communicating, especially when debating topics in which I'm specialized and where is not possible to have a "middle-ground solution". I also feel some "negative vibes" from some of my coworkers when communicating.

I feel that this political correctness is leading to design by committee problems in some of our projects, especially in areas such as database design and software architecture.

There aren't any tech-lead/software architect positions in my team.

Is there a way to effectively debate technical ideas, in an assertive way, without being perceived as arrogant?

Note that I'm very assertive and competitive by nature, and in my previous jobs I had a feeling of "healthy competition" between colleagues and never had any problem, I still have good friendships with several of my former colleagues.

Answer 1

Personality traits are often observed and confirmed through subtleties in your behavior, and I suspect you're oblivious to those subtleties. Just as an example, I'm going to dissect a single sentence from your question:

my boss, which I consider a really capable and smart manager, has a system for measuring developer performance, in which I constantly get much more points than the second best developer

• Considering your boss "smart and capable" is perfectly fine, but it:
  • does not matter in relation to how your coworkers feel about you
  • comes off as incredibly biased and/or manipulative since you then continue on mentioning that you personally do very well in your boss' evaluation
  • is only being used as further justification of why this evaluation that puts you in first place is supposedly a really good evaluation metric. It's not intended to compliment your boss, it's intended for you to indirectly self-aggrandize.
• Why point out that you constantly do better?
• Why point out that you do much better?
• "I do better than the second best" is subtly trying to say "I'm the best" without outright stating it.

These are all red flags. A more humble person, even when getting the same evaluation as you, would've stated something along the lines of:

I've received positive feedback in these evaluations

And when you go on to read the rest of your question, this is really the purpose of that paragraph: telling us you score well on the evaluations.

The rest of the way you phrased it doesn't add anything of value, but it adds a whole lot of boasting, mutual favoritism, and reveals how much you focus on separating yourself from others competitively. In other words, you've basted your message in arrogant sauce.

I'm trying to be more passive

Your boss didn't ask you to be passive, he asked you to be inclusive of others' opinions. The fact that you think that the only way you can contribute is by stifling others' input (or else be passive) is a worrying sign.

I feel like I'm walking on eggshells

Another red flag. You're asked to include others in the discussion, and you perceive this as if you're now having to carefully handle these "fragile" coworkers.

This just goes to show exactly how much you prefer cutthroat competitivity (being the best) over mutual cooperation (working together).

specially when debating topics in which I'm specialized and where is not possible to have a "middle-ground solution"

You're still missing the point. Including others in a discussion does not equate to forced compromise. It means that you need to hear everyone's concerns and thoughts before making a decision together.

Even if your solution is objectively the better one, that does not prevent you from listening to your coworkers' input, discussing the pros and cons of each different approach, and then cooperate on deciding what steps to take.
If your argument is correct, then the exploration of the pros and cons will prove that point, which is going to sway opinion in favor of your solution.

But if you come in heavy-handed, ignoring others' input and immediately proclaiming to already know the solution, then you're going to meet a tremendous resistance to doing things your way. You catch more flies with honey than vinegar.

I also feel some "negative vibes" from some of my coworkers when communicating.

I'm not surprised. Even in your question, where your have the benefit of us only hearing your side, your arrogance and lack of cooperative spirit already oozes through. I can only imagine how much clearer that picture gets in the context of being your coworker every day.

Those negative vibes you get are bouncing back off of your coworkers. You negatively interact with them, and so they negatively interact with you. You can't blame the mirror for being ugly.

politically correctness

I refer back to the eggshells comment. You're repeatedly implying that you have to unfairly dial yourself back, simply when you are asked to cooperate and respect everyone's input.

is leading to design by committee problems in some of our projects

"Design by committee" refers to cases where everyone does their own thing without much coordination or forethought.

You are being asked to coordinate with your coworkers. You're not being asked to design by committee. You're being asked to not design by dictatorial rule.

Note that in my team there aren't any tech-lead / software architect positions.

And what gives you the idea that you, with your 6 months of seniority, get to therefore usurp the leading position?

And that's not even mentioning the fact that leaders should not call shots, but coordinate others to call shots. Even if you take that leadership position, you can use that position to ensure everyone's input gets heard, instead of ensuring that everyone hears your input.

Leaders are elected by their citizens, not by self-proclamation or a power grab. You're trying to be a dictator (quite literally: someone who dictates the solution), not a leader.

Note that I'm very assertive and competitive by nature

This is just "I want to behave the way I want to", wrapped in some bogus justification that it's allegedly your "nature" and implying it's normal.

"healthy competition"

It always looks like healthy competition when you feel like you're winning.

"healthy competition" between colleagues

If the word "competition" comes to mind before "cooperation" when thinking of your coworkers, then you are a troublesome coworker.

Is there a way to effectively debate technical ideas, in an assertive way, without being perceived as arrogant?

"To assert" means to state something as a fact, forcefully. It is the exact behavior that is causing you to receive this negative feedback from both your coworkers and your superiors.

Asking how to keep doing the thing you're being told not to do, based on your self-perceived notion of superiority, is the pinnacle of arrogance. What you're asking is no different from asking how you can punch someone without being perceived as violent. The exact thing you're trying to do is the thing you're being accused of.

The opposite of arrogance is humility. It entails not always thinking (or arguing) that you're right, instead being open to what you observe / are being told, instead of what you think about yourself. Second-guess yourself. Listen to others' input. Don't try to persist your ideas above all else. Assume you are not a perfect being.

Your boss' feedback was spot on. Mellow out (i.e. don't see your coworkers as competitors), listen to others, stop trying to claim the spotlight or leadership position.

---

Here's another way of looking at it.

You are being a bad communicator. This is clear both from the feedback you are getting and the way you yourself think you should be interacting with your coworkers.
Cooperation and communication are key skills for any employee, most certainly a developer. So if you're a bad communicator, that makes you both a bad employee and a bad developer.

Since you're so competitive (one might even say it's in your nature), shouldn't you then be trying to be a better communicator? So why are you resisting?

If you want to argue your own worth based on adhering to your manager's metric, a manager who you claim to be smart and capable; then you should also be listening to your manager's feedback on how you are behaving and how you should change how you treat your coworkers.

Competitive people want to be better. So work at being a better coworker, instead of arguing why you shouldn't need to be or trying to persist the same behavior you're being told to stop.

Answer 2

Over the years I have learned that the phrase "walking on eggshells" is a fantastic tell, a way to know that someone actually is arrogant, as you have been told you are. Let me explain why. You're being careful, right? You don't want to upset your coworkers. That's great. But you are not even noticing what it is you're being careful about. You're being careful and thoughtful and mellow and "politically correct" about telling them they're wrong. Because they are, right? Pretty much always? After all, you're specialized, and there's no middle ground solution. They're wrong and your problem is you're not allowed to be blunt and straightforward when you tell them that. Right?

Wrong.

They might be right.

Sure, A might always be faster than B and with your specialized knowledge you know this fact. But that is not the same as "we should do A." A might only be a fraction of a percent faster in this case, and might be twice as much work. Or A might make it harder for another team to connect to your system. Or something.

Your peers aren't idiots. They do know some things. They have a reason for wanting to do it some other way. You need to listen to that reason. You need to ask questions about the way they are thinking of doing it. You need to open yourself to the possibility that even though you are right on some technical point, like A being faster than B, your colleagues may be right on the decision point, that in fact the team should do B even though A would be a little faster. Don't be passive. Don't choose careful and polite words to tell them they are wrong. Listen to what they're telling you and ask questions until you understand.

When you understand, then you might be able to say something like "ok, so we all agree that A is faster than B. Where we disagree is whether that is worth [whatever the other tradeoff is] for this project? Is that right?" Now you can stop endlessly firmly beating on the "but A is faster" drum and work with your colleagues to make the best decision for the team. It's quite likely that things will end up getting done the way you want most of the time, because you know your stuff and can come up with good solutions. The trick is to get things done your way most of the time while having people think well of you, think of you as someone who comes up with good solutions that consider all the aspects of the project. Not as someone who just picks a solution and insists on it because you know the others are wrong.

Answer 3

As a fellow "smartest guy in the room," who also struggled for years with this, I would suggest that you follow a few simple rules.

1. When someone suggests something that you think is wrong, never immediately stop them and disagree. Always, instead, take some amount of time to think about the situation. Do you have all of the information? Are you sure there is only one way to see this? Is this important?

2. Then, if the answer is yes-yes-yes, you can either:

   • Using the information you have, ask if the way you see it might be correct:
     "You mentioned that the flug function returns a character value. Based on our discussion yesterday, is it possible it might return an array of character values? I use this in the melt method, and I wrote that expecting it can pass, and receive back, an array."
     You show the information you have (the discussion), you show why it's important (you are using it), and you ask if it might return an array. This allows the other person to explain to you why it's not possible, if it isn't, which is important - it doesn't tell the other person they must be wrong. Or:
   • Using the information you have, explain that you see it differently:
     "You mentioned that the flug function returns a character value. I had thought it returned a character array, based on my recollection of the conversation yesterday, so I used it in the melt method that way. Is that possible to change?"
     Similar to the earlier option, you can tell why it's important (you used it that way), you leave yourself open to being wrong ("I had thought"), and you explain why you think you're right ("based on my recollection of the conversation...").

The key here is to slow yourself down, and to be considerate when having a discussion. You probably think very quickly, and understand things intuitively. But guess what - now you're in a room with people who have been doing this for years if not decades, successfully.

You're also now in a situation where you cannot know all of the information all of the time - it's just not available in a corporate environment; you know some of the information, but not all of it. So allow for that. Resist the urge to immediately disagree - let things percolate in your head for a bit, make sure that it's important and make sure you're actually right. Sometimes waiting that time lets the other person add some more details that will explain why you're actually wrong (because you don't have the full set of information).

Answer 4

It can really be both.

On the one hand, the nail that sticks out gets hammered down. If you're the best one, this can provoke a lot of bad blood among your peers, no matter how inclusive you are.

On the other hand, if you know you're competitive, maybe you're showing too much of it for the culture you're now working in.

Some tips:

1. Ask people what they think about something, instead of going on about your vision.
2. If you don't agree with something/ somebody, ask the person why they think that's a good idea first. Try to understand, then criticize.
3. Compliment people when they say/ do something well. Give them the feeling you can learn something from them.
4. Treat people like humans, not results. Talk to them about something apart from bugs and who had a better idea.
5. Use "sh*t hamburger": You start by saying something positive ("Your idea has a chance to eliminate the problem of ..."), go on to criticize ("Unfortunately, it would take us months to implement. A less time-consuming alternative is ..."), and then finish on a positive note ("but your idea is great as an approach to another problem on this second project we are currently running").
6. Tell people "you're right" whenever you can. If someone had a good idea tell them so. Show them you're listening - and not only to the sound of your voice. Defend their ideas, not just yours.
7. Use "I've had this problem myself a lot" ("...and look, what I've found out") a lot

Criticizing is an art. I've been working on learning how to be less harsh when criticizing myself. To be honest, it's a hit-and-miss, but the above helps a lot.

Answer 5

Last week, my boss had a talk with my saying that some of my coworkers feel that I'm arrogant, he said that probably was because of the large difference in performance, and because I'm too assertive in technical debates. He told me to "mellow down" my attitude, and to always look for solutions that include all opinions in technical discussions.

I think you should read into this carefully because it is a statement from your boss. He is really telling you to stop doing that. He's not telling you because others told him. This is his own opinion and not from your co-workers.

It could be they have a way to do things and now you're just going in there trying to change everything. Nobody likes that because they've been doing something one way and just because a new guy comes in they're not going to suddenly switch things up for no reason.

My thought: try to work there for a little while. If you notice something wrong, perhaps you can get a change over time. By showing them that their process is ineffective, you can show them an alternative. However keep in mind that just because there's a better way to do something doesn't mean they're going to be open to the idea.

Answer 6

You're not always right

No one is right all the time. Of course you think you're right; your co-workers think they're right, too. But as others have pointed out, there are very few objective "truths" in technical matters. Sure, if something simply doesn't work at all, then it doesn't work. But most of the time, there are trade-offs in terms of schedule, budget, performance, maintainability, and other constraints - even for things that are considered dogma in your technical domain (e.g. the DRY principle).

You won't improve with that attitude

Thinking you're right all the time means you won't learn from your coworkers or see your shortcomings as opportunities to improve. That means you'll be stuck at your current technical level. And worse, you'll be blind to your actual performance. Clearly you're doing well in terms of your boss's performance metric - but it's probably a bad metric. So it doesn't mean you're currently a "great engineer" (whatever that means; we all need to grow). Humility, realizing you have strengths and weaknesses, and realizing that you're often wrong and your co-workers are often right are all important to developing professional self-awareness and growing in your skills.

Bosses want team players

Your boss has made it clear to you that technical skills (at least as measured by the boss' metric) aren't enough; you also need to work well with your team. If they don't like you because you're rubbing them the wrong way, you're not a team player. If you don't change that, you're probably not going to stick around long. The bad news for you is this is the case at many (most?) employers. The good news is you can learn to actually work with your co-workers. This starts with humbling yourself and viewing your co-workers with respect, as equals, and treating them that way. And when you do, you'll learn that you can learn from them too.

Learn humility

Humility is the key. Learn that you're not #1. Learn that that's ok. Value others. Work together. Learn. Grow.

Answer 7

Two details stand out to me:

1. Regarding "healthy competition", software development has long been plagued with unproductive hyper-competitive work environments. Places where rewriting a co-worker's perfectly good code using an obscure trick to be slightly shorter was considered a valuable way to determine who was the top dog. The book Showstopper about how Windows-NT was written is a nice example. The Code Golf StackExchange is a reminder of those days.

   That hasn't been stamped out yet, and any hint of artificial competition or jockeying for who's the best is going to remind people of that toxic, easy-to-slip-into work environment they want to avoid.

2. I'm assuming you have some Com Sci training, but web developers may not. Say you see them use A.remove(fn1).map(w=>w.toUpper). Pretty advanced stuff, right? In a Com Sci program, this is proof you've thoroughly learned the dozen concepts and features involved. But a boot-camp might start with that and cover only how to write things of that form (which can solve 97% of day-to-day problems, after all).

   You may be proposing things assuming they're a bit rusty on them, or are stubbornly refusing to do it that way. But they may never have done anything close, have no way of judging good or bad, and wouldn't be able to maintain it without you. The best you may be able to do is learn what they know and don't know, figure out how to express some new ideas using their language, and make sure whatever "black magic" parts you write interface nicely with their system.

Answer 8

Always talk to people like they know more than you.

I'm very much like you, and this simple rule has served me well. If they're wrong, they still feel respected, but hey, sometimes they actually might be right, and you get to learn something new.

Many great answers have already been posted, but I think this single sentence still adds some value because it's simple and general enough to keep in the back of your mind 24/7.

Answer 9

As this is also an ongoing issue I struggle with (I grew up the eldest of 6 very competitive siblings, and picked up more than a few bad habits as a result), here are some techniques that I've found to be extremely helpful.

Everything is more complicated than you think

I cannot stress how important it is to remember this, and to remind yourself of it frequently. If you let this guide your communications, it'll really help avoid some of the 'tells' that are causing trouble.

Most importantly, speak in absolutes as little as possible, because absolutes are a really good way to both come off as arrogant, and end up with a design that misses important corner cases.

Additionally, when you remember that whatever you're designing is more complicated than you think, it makes it easier to take the time to consider suggestions you might not otherwise entertain if you're in the debate mindset.

Assert less, ask more

This can be derived from, "Everything is more complicated than you think," but I think it's probably worth calling out specifically.

Nothing can tank a design's utility faster than Unknown Unknowns, so it's worth approaching technical discussions with that in mind. If one of your peers asks something that doesn't make sense to you, you need to understand why that is. Generally speaking, one of three things is happening and none of them are good:

1. Your coworker does not understand something about the design, and you do.

   This is actually the least bad option, because as long as you understand the design well enough to explain it effectively, this is generally easy to clear up.

   If this isn't cleared up early, it can lead to a bunch of wasted time and rework when incorrect understanding leads to incorrect implementation that isn't flagged until it's time for Code Review.

2. You do not understand something about the design, and your coworker does.

   This is a little worse than if your coworker is the one with the misunderstanding, because it means you need to reevaluate anything else in the design that this additional information may have invalidated. It's also going to mean you need to be humble and listen, which can be hard.

3. Neither you nor your coworker actually understand the design.

   This often happens if you're working on an older system and you both understand some fraction of the system in ways that lead you both to incorrect assumptions about how it should behave.

   In the worst case scenario, this can mean starting from scratch. If you're really lucky, you're early enough in the discussion that you haven't sunk much time into the design yet, and can pivot quickly.

Get out of the trap of ineffective communication styles

Depending on where and when you were raised, and assuming some things about your gender from your name, it's very likely you were taught a communication style that isn't doing you any favors. Combative and overly clever communication only works on TV and in books because the dialog is created by writers who know everything relevant going on, and can control the reactions of the characters.

Instead, recognize that you probably don't know everything relevant to the current discussion, and the people listening are free to react to what you're saying in the ways that make sense to them.

Part of this means liberally annotating your assertions with indicators that, while you are confident this is the best way forward, you understand you may be missing something. "I think", "from what I can tell", "if I understand correctly", and similar modifiers are your friend.

Do not be afraid to briefly summarize the technical complexities at hand, and a level appropriate to the audience. A reputation for being willing to spend the extra two minutes to clearly explain the constraints you're working under will serve you well, and it only costs a few minutes at a time. Additionally, it helps set realistic expectations, which is priceless. As a warning, you will screw this up at first and that's Ok, explaining things at the correct technical level for your audience is a really hard won skill, and I still get it wrong from time to time.

Emojis are also helpful when you need to convey emotional context in text-based communication, particularly if you tend towards being more terse than verbose, and can absolutely help avoid coming across as sarcastic when that's not intended. Just don't overdo it and stick to the more common ones, so your communications stay professional.

You are not your design

When you notice that you're getting heated and feeling defensive, you need to take a step back and distance yourself from the design. If there are flaws in the design, they are not indicators that you are lacking. Arrogance isn't always a defense mechanism, but it certainly can be, and that's a trap you absolutely have to avoid, particularly if you have already established a reputation for being arrogant.

If you feel like your coworkers just aren't "getting it" and are getting frustrated, this is another time when you can really easily slip into really arrogant behavior without noticing. Take a bit to cool off and think it over, and try to figure out where the disconnect is occurring. Occasionally it turns out they don't have the background to understand the concept I'm trying to explain without additional ground work. Most of the time it's usually that I don't understand a portion of the design as well as I thought I did.

Improve your environment

I don't know if this is possible, but it might be worth talking to your boss about ditching the "gain points to 'win' a day off" thing they're doing at your work.

Intra group competition can help everyone sharpen their skills, but it can also worsen fractures within the group and provide perverse incentives to undermine cooperation. It sounds like this particular policy may be doing the latter more than the former.

Fake it until you make it

This one's sort of meta. All my advice is geared towards things you can do to modify your behavior, not directly work on attitude. As pointed out in other answers, even in the question there are a bunch of red flags which indicate you have some serious issues with arrogance. If you can afford one, I understand that a therapist can be helpful untangling these issues (they're apparently a bit like a debugger for your head).

If that's not an option, as it isn't for me, I can attest that the longer you are intentional about modifying your behavior, the easier it becomes. You don't just act less arrogant, you start to become less arrogant in noticeable ways.

Answer 10

"Discussion", not "debate"

A good first step might be to think of an exchange of technical ideas not as a "debate", but rather as a "discussion".

Debates often involve different parties debating opposing sides of an issue, and there are often winners and losers.

Trying to "win" against the coworkers you should be working with is counterproductive.

With a discussion you more often have everyone sharing their ideas and trying to work together to improve their understanding and ultimately reach a consensus on the topic.

When someone proposes an idea you consider to be bad, you should put aside the urge to explain why they're wrong and instead focus on why they're suggesting that as if they're right (even if they're clearly not, but they may actually be right more often than you'd like to think). This would involve asking lots of questions, which may in itself make the problem with their suggestion clear to them.

If this doesn't happen, you've hopefully narrowed the problem down to a specific fact they're mistaken about. Addressing only this would allow for a much more focused (and thus effective) argument than trying to broadly address the problem with a suggestion. To gracefully do this, I would suggest saying something like:

Actually I've read that ...

"I've read" or "I think" helps to avoid the implication that they should believe you because you are the expert and you don't need anyone or anything to back up what you say (that would be quite arrogant). This implication may be fine (and potentially preferred) if you actually are the expert and others see you as such, but it doesn't work so well when talking to someone who knows (or think they know) a reasonable amount about the topic at hand (even if they still know much less than you).

Of course you can also send them some resources later that backs up what you say (and that also explains it in more detail).

You don't need to (and shouldn't) explicitly say "you're wrong" (or similar), as this is implied by simply pointing out a fact which contradicts what they said.

Some things are subjective

In many cases you can come with objective pros and cons of different approaches, but often how you weigh these can be quite subjective.

This means that someone else can prefer a different approach to you even if they already know all the pros and cons, but they just feel some are more or less important than you think they are. This doesn't mean they're wrong.

On a related note, experience with something (and personal preference) is also a pro (or con). Don't discount the fact that they may have experience with what they're suggesting, and not with what you're suggesting, which would affect how much time it would take for them to start being productive (and also just how comfortable they would be) if you go with your suggestion.

In some cases they may be wrong, but it may also not be easy to convince them of that if it's something you learn through years of experience. This leads quite nicely into both of the following points.

Refer back to your past experience

You could try saying something like:

Actually we tried that when I was working for Acme and we ran into quite a few problems like ...

This may be sufficient in itself, although it's usually best to back it up with reasons as well.

If you're struggling to articulate the reasons why something is not a good idea, this may be a sign that you don't have good reasons for disapproving of it. Anecdotes are useful, and can help to sway decisions, but they aren't conclusive proof that something never or always works.

Consensus is better than perfection

Some decisions just aren't that important and often it's more productive to just accept some less-than-ideal solution than to spend a bunch of time discussing it. Time is money.

Even for some of the more important decisions, it can be useful to accept an imperfect decision for the sake of agreement.

You may be delivering a product or service, but you're also part of a team.

Don't underestimate the value of having everyone feel like they're actually making valuable contributions (even when they're wrong).

Answer 11

"Note that I'm very assertive and competitive by nature...", and that's probably your problem right there. Perhaps you don't really understand that for a lot of us, being "assertive and competitive" is pretty well impossible to distinguish from being arrogant, or indeed, just being a jerk.

You need to do a major personality transformation. Bury the assertiveness, and let the facts speak for themselves. If your solutions are better, then they can be shown to be better. People will adopt them because they are good, not because you assertively talk down anyone else's suggestions.

Answer 12

I want to address the question from a different direction than the many good answers already written, one that addresses specifically your apparent need to debate technical choices.

Many answers already addressed how debating ia probably not the right way to go about making decisions if you want to foster a cooperative work environment, but that doesn't mean that there ia no value in vigorous technical debate, as long as it's framed properly. Don't make the debate the way to make project decisions, but make it an "extracurricular" team activity to hone both technical skills and communication skills for all involved.

Designate a (monthly/biweekly/whatever) team meeting titled "Technical Deep Dive", where engineers take turns presenting a proposed architecture or solution, expound on their value, and get feedback and review. This shouldn't be part of the official design review process for all the reasons listed by others, but can provide you and others a venue for productive debate without making the actual development process too hostile or antagonistic.

Of course, these debate sessions should also have guidelines on style and attitude. They should be productive and constructive, not trying to win. But when there aren't points on the line, the discussion can remain professional.

Answer 13

You write that you score above average in those developer performance assessments. If you score better than your colleagues, they're not gonna be your biggest fan. If the "above average" developers get a day off, and you raise that average, they get fewer days off. Great colleague you are!

Instead, I suggest you use your skills for the good: Help your colleagues to improve. If you see something that can improve, help them improve with by providing constructive feedback. The goal is not to show how good you are, but to help the team as a whole grow. Take a full moment to explain something in a way that doesn't make them feel inferior, but in a way that they learn something new. In the long run, that benefits everyone.

Answer 14

Always Assume You Could Possibly Be Wrong.

See, arrogance has nothing to do with whether you're smart or dumb, skilled or clueless, productive or inefficient. The fact that you spent so much of your post touting your skills makes me think you've overlooked this.

Arrogance is assuming you're right, and that everyone else is wrong.

In my current group of 4, I'm the most technically capable and knowledgeable. Yet when I go into a discussion about how to do something and one of them says, "We should do X?" I don't immediately argue against them. I ask them why. Because I don't assume that I must be right and they must be wrong. Maybe they'll list a reason that I know isn't compelling... or maybe they'll give a point that I hadn't thought of, or present a fact that I didn't know! I don't assume that if they come up with a different answer that they must be wrong.

That's what your boss is trying to get you to change. Not to be passive, not to forgo contributing... but to simply stop acting like you're infallible and to treat your coworkers as valuable partners on the job. If you disagree with a coworker, don't assume they're wrong. And if you disagree with the design choice that's decided upon, don't assume it's necessarily wrong either! That's another facet of arrogance (I don't agree with this design choice; therefore, it is wrong.)

Answer 15

I'm too assertive in technical debates

You could discuss it in details with your manager how do you think you could improve. But it may be a catch which you cannot escape: whatever you do after the accusation has been said would only reinforce it. Just remember to keep it constructive, don't forget to thank everybody for their contributions, even wrong ones, and surely good ones. Maybe it gets better in time.

But I am worried about this:

..my boss ... has a system for measuring developer performance, in which I constantly get much more points than the second best developer.

Note that I'm trying my best to win these points ..

To my knowledge, in the software development, all formal metric with points have not been reasonable about does it really ensure high quality of the output, and are very easy to be tricked, even unintentionally. Maybe you should try a bit less harder to earn the points, and pay more attention to the overall performance of the team? It is hard to give detailed advice how to do it without knowing the details of the metric.