How to deal with team member who is picking argument always instead of understanding the point? [closed]

Clash Royale CLAN TAG#URR8PPP

.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty margin-bottom:0;

up vote
4
down vote

favorite

1

I am working for on IT organization as Team Leader. I have a team member who works as developer. In age he is elder than me. He is very prone is picking argument and making offensive personal comments.

Here is the latest incidents

One fine morning I received a mail saying that

" Babu, I found there is an issue in x.cs file, I found the root cause is due to line no 10. I have removed and going to check in. I think similar changes needs to be done in our frame work."

Then my reply is

"Hi Dev, Thanks for you findings. Appreciate it. Please report such issues to me and architecture team. Architecture team is the one who really owns the frame work. Any issues with the framework we have to report that team and ask them to fix instead we making the changes and taking that accountability"

Then his Reply was

"I don’t think it’s an architecture change. I feel it’s a simple code change in a common file"

Then I stop sending mails and then pinged him

Babu:"I didn't say this is architecture change or not commenting about your change. Frame work is some thing used by multiple teams, if some thing goes wrong there are chances that we will get blame. What ever I am suggesting is guideline to avoid such situations. Architecture team really have look and fix the issue. I feel we should handover them instead we are making the change and take accountability and let them fix the issue. Do you agree?"

Dev: No

Babu:Why?

Dev: I have already mailed you the reason. First you should know the meaning of architecture

I was surprised and feeling offended.

Babu: You are taking my words negatively

Dev: No you are making every thing prestige issue and doesn't aggree with anyone

In the above scenario, I feel, he is taking things negatively. Instead of discussion actual his concerns of concepts he is making personal comments. This is what happens every time I suggest something and sit together to discuss some thing. And it leads to heated arguments. I really don't want these things happen further

How to handle this team member?

team

share|improve this question

asked Sep 4 '14 at 22:01

Babu

3,28332059

closed as off-topic by gnat, IDrinkandIKnowThings, jcmeloni, ChrisF, Joe Strazzere Sep 5 '14 at 17:03

This question appears to be off-topic. The users who voted to close gave this specific reason:

• "Real questions have answers. Rather than explaining why your situation is terrible, or why your boss/coworker makes you unhappy, explain what you want to do to make it better. For more information, click here." – gnat, jcmeloni, ChrisF, Joe Strazzere

If this question can be reworded to fit the rules in the help center, please edit the question.

• 
  
  
  

  
  2
  

  
  
  
  
  
  

  
  Surely the distinction of whether some code belongs to the Architecture Team or not should be determined by its location in the codebase, not some philosophical argument as to what is "architecture" and what is "a common file"?
  – Carson63000
  Sep 5 '14 at 1:53
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  possible duplicate of How can I deal with a difficult developer that is holding back the project?
  – IDrinkandIKnowThings
  Sep 5 '14 at 14:29
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  Why don't you take it to the architecture team? He is probably resisting extra work and meetings
  – Kate Gregory
  Sep 5 '14 at 17:01
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  @KateGregory, I am fine with that. But my main concern is every meeting with him is ending up with personal comments on me instead of ending up with constructive discussion.
  – Babu
  Sep 6 '14 at 0:31
  

  
  
  
  


• 
  
  
  

  
  1
  

  
  
  
  
  
  

  
  *comments removed* Remember what comments are for. For extended discussions, Get a Room (a chat room).
  – Elysian Fields♦
  Sep 6 '14 at 15:50
  

  
  
  
  

 | 
show 1 more comment

up vote
4
down vote

favorite

1

I am working for on IT organization as Team Leader. I have a team member who works as developer. In age he is elder than me. He is very prone is picking argument and making offensive personal comments.

Here is the latest incidents

One fine morning I received a mail saying that

" Babu, I found there is an issue in x.cs file, I found the root cause is due to line no 10. I have removed and going to check in. I think similar changes needs to be done in our frame work."

Then my reply is

"Hi Dev, Thanks for you findings. Appreciate it. Please report such issues to me and architecture team. Architecture team is the one who really owns the frame work. Any issues with the framework we have to report that team and ask them to fix instead we making the changes and taking that accountability"

Then his Reply was

"I don’t think it’s an architecture change. I feel it’s a simple code change in a common file"

Then I stop sending mails and then pinged him

Babu:"I didn't say this is architecture change or not commenting about your change. Frame work is some thing used by multiple teams, if some thing goes wrong there are chances that we will get blame. What ever I am suggesting is guideline to avoid such situations. Architecture team really have look and fix the issue. I feel we should handover them instead we are making the change and take accountability and let them fix the issue. Do you agree?"

Dev: No

Babu:Why?

Dev: I have already mailed you the reason. First you should know the meaning of architecture

I was surprised and feeling offended.

Babu: You are taking my words negatively

Dev: No you are making every thing prestige issue and doesn't aggree with anyone

In the above scenario, I feel, he is taking things negatively. Instead of discussion actual his concerns of concepts he is making personal comments. This is what happens every time I suggest something and sit together to discuss some thing. And it leads to heated arguments. I really don't want these things happen further

How to handle this team member?

team

share|improve this question

asked Sep 4 '14 at 22:01

Babu

3,28332059

closed as off-topic by gnat, IDrinkandIKnowThings, jcmeloni, ChrisF, Joe Strazzere Sep 5 '14 at 17:03

This question appears to be off-topic. The users who voted to close gave this specific reason:

• "Real questions have answers. Rather than explaining why your situation is terrible, or why your boss/coworker makes you unhappy, explain what you want to do to make it better. For more information, click here." – gnat, jcmeloni, ChrisF, Joe Strazzere

If this question can be reworded to fit the rules in the help center, please edit the question.

• 
  
  
  

  
  2
  

  
  
  
  
  
  

  
  Surely the distinction of whether some code belongs to the Architecture Team or not should be determined by its location in the codebase, not some philosophical argument as to what is "architecture" and what is "a common file"?
  – Carson63000
  Sep 5 '14 at 1:53
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  possible duplicate of How can I deal with a difficult developer that is holding back the project?
  – IDrinkandIKnowThings
  Sep 5 '14 at 14:29
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  Why don't you take it to the architecture team? He is probably resisting extra work and meetings
  – Kate Gregory
  Sep 5 '14 at 17:01
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  @KateGregory, I am fine with that. But my main concern is every meeting with him is ending up with personal comments on me instead of ending up with constructive discussion.
  – Babu
  Sep 6 '14 at 0:31
  

  
  
  
  


• 
  
  
  

  
  1
  

  
  
  
  
  
  

  
  *comments removed* Remember what comments are for. For extended discussions, Get a Room (a chat room).
  – Elysian Fields♦
  Sep 6 '14 at 15:50
  

  
  
  
  

 | 
show 1 more comment

up vote
4
down vote

favorite

1

up vote
4
down vote

favorite

1

1

I am working for on IT organization as Team Leader. I have a team member who works as developer. In age he is elder than me. He is very prone is picking argument and making offensive personal comments.

Here is the latest incidents

One fine morning I received a mail saying that

" Babu, I found there is an issue in x.cs file, I found the root cause is due to line no 10. I have removed and going to check in. I think similar changes needs to be done in our frame work."

Then my reply is

"Hi Dev, Thanks for you findings. Appreciate it. Please report such issues to me and architecture team. Architecture team is the one who really owns the frame work. Any issues with the framework we have to report that team and ask them to fix instead we making the changes and taking that accountability"

Then his Reply was

"I don’t think it’s an architecture change. I feel it’s a simple code change in a common file"

Then I stop sending mails and then pinged him

Babu:"I didn't say this is architecture change or not commenting about your change. Frame work is some thing used by multiple teams, if some thing goes wrong there are chances that we will get blame. What ever I am suggesting is guideline to avoid such situations. Architecture team really have look and fix the issue. I feel we should handover them instead we are making the change and take accountability and let them fix the issue. Do you agree?"

Dev: No

Babu:Why?

Dev: I have already mailed you the reason. First you should know the meaning of architecture

I was surprised and feeling offended.

Babu: You are taking my words negatively

Dev: No you are making every thing prestige issue and doesn't aggree with anyone

In the above scenario, I feel, he is taking things negatively. Instead of discussion actual his concerns of concepts he is making personal comments. This is what happens every time I suggest something and sit together to discuss some thing. And it leads to heated arguments. I really don't want these things happen further

How to handle this team member?

team

share|improve this question

asked Sep 4 '14 at 22:01

Babu

3,28332059

I am working for on IT organization as Team Leader. I have a team member who works as developer. In age he is elder than me. He is very prone is picking argument and making offensive personal comments.

Here is the latest incidents

One fine morning I received a mail saying that

" Babu, I found there is an issue in x.cs file, I found the root cause is due to line no 10. I have removed and going to check in. I think similar changes needs to be done in our frame work."

Then my reply is

"Hi Dev, Thanks for you findings. Appreciate it. Please report such issues to me and architecture team. Architecture team is the one who really owns the frame work. Any issues with the framework we have to report that team and ask them to fix instead we making the changes and taking that accountability"

Then his Reply was

"I don’t think it’s an architecture change. I feel it’s a simple code change in a common file"

Then I stop sending mails and then pinged him

Babu:"I didn't say this is architecture change or not commenting about your change. Frame work is some thing used by multiple teams, if some thing goes wrong there are chances that we will get blame. What ever I am suggesting is guideline to avoid such situations. Architecture team really have look and fix the issue. I feel we should handover them instead we are making the change and take accountability and let them fix the issue. Do you agree?"

Dev: No

Babu:Why?

Dev: I have already mailed you the reason. First you should know the meaning of architecture

I was surprised and feeling offended.

Babu: You are taking my words negatively

Dev: No you are making every thing prestige issue and doesn't aggree with anyone

In the above scenario, I feel, he is taking things negatively. Instead of discussion actual his concerns of concepts he is making personal comments. This is what happens every time I suggest something and sit together to discuss some thing. And it leads to heated arguments. I really don't want these things happen further

How to handle this team member?

team

share|improve this question

asked Sep 4 '14 at 22:01

Babu

3,28332059

share|improve this question

share|improve this question

asked Sep 4 '14 at 22:01

Babu

3,28332059

asked Sep 4 '14 at 22:01

Babu

3,28332059

asked Sep 4 '14 at 22:01

Babu

3,28332059

3,28332059

closed as off-topic by gnat, IDrinkandIKnowThings, jcmeloni, ChrisF, Joe Strazzere Sep 5 '14 at 17:03

This question appears to be off-topic. The users who voted to close gave this specific reason:

• "Real questions have answers. Rather than explaining why your situation is terrible, or why your boss/coworker makes you unhappy, explain what you want to do to make it better. For more information, click here." – gnat, jcmeloni, ChrisF, Joe Strazzere

If this question can be reworded to fit the rules in the help center, please edit the question.

closed as off-topic by gnat, IDrinkandIKnowThings, jcmeloni, ChrisF, Joe Strazzere Sep 5 '14 at 17:03

This question appears to be off-topic. The users who voted to close gave this specific reason:

• "Real questions have answers. Rather than explaining why your situation is terrible, or why your boss/coworker makes you unhappy, explain what you want to do to make it better. For more information, click here." – gnat, jcmeloni, ChrisF, Joe Strazzere

If this question can be reworded to fit the rules in the help center, please edit the question.

• 
  
  
  

  
  2
  

  
  
  
  
  
  

  
  Surely the distinction of whether some code belongs to the Architecture Team or not should be determined by its location in the codebase, not some philosophical argument as to what is "architecture" and what is "a common file"?
  – Carson63000
  Sep 5 '14 at 1:53
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  possible duplicate of How can I deal with a difficult developer that is holding back the project?
  – IDrinkandIKnowThings
  Sep 5 '14 at 14:29
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  Why don't you take it to the architecture team? He is probably resisting extra work and meetings
  – Kate Gregory
  Sep 5 '14 at 17:01
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  @KateGregory, I am fine with that. But my main concern is every meeting with him is ending up with personal comments on me instead of ending up with constructive discussion.
  – Babu
  Sep 6 '14 at 0:31
  

  
  
  
  


• 
  
  
  

  
  1
  

  
  
  
  
  
  

  
  *comments removed* Remember what comments are for. For extended discussions, Get a Room (a chat room).
  – Elysian Fields♦
  Sep 6 '14 at 15:50
  

  
  
  
  

 | 
show 1 more comment

• 
  
  
  

  
  2
  

  
  
  
  
  
  

  
  Surely the distinction of whether some code belongs to the Architecture Team or not should be determined by its location in the codebase, not some philosophical argument as to what is "architecture" and what is "a common file"?
  – Carson63000
  Sep 5 '14 at 1:53
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  possible duplicate of How can I deal with a difficult developer that is holding back the project?
  – IDrinkandIKnowThings
  Sep 5 '14 at 14:29
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  Why don't you take it to the architecture team? He is probably resisting extra work and meetings
  – Kate Gregory
  Sep 5 '14 at 17:01
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  @KateGregory, I am fine with that. But my main concern is every meeting with him is ending up with personal comments on me instead of ending up with constructive discussion.
  – Babu
  Sep 6 '14 at 0:31
  

  
  
  
  


• 
  
  
  

  
  1
  

  
  
  
  
  
  

  
  *comments removed* Remember what comments are for. For extended discussions, Get a Room (a chat room).
  – Elysian Fields♦
  Sep 6 '14 at 15:50
  

  
  
  
  

2

2

Surely the distinction of whether some code belongs to the Architecture Team or not should be determined by its location in the codebase, not some philosophical argument as to what is "architecture" and what is "a common file"?
– Carson63000
Sep 5 '14 at 1:53

Surely the distinction of whether some code belongs to the Architecture Team or not should be determined by its location in the codebase, not some philosophical argument as to what is "architecture" and what is "a common file"?
– Carson63000
Sep 5 '14 at 1:53

possible duplicate of How can I deal with a difficult developer that is holding back the project?
– IDrinkandIKnowThings
Sep 5 '14 at 14:29

possible duplicate of How can I deal with a difficult developer that is holding back the project?
– IDrinkandIKnowThings
Sep 5 '14 at 14:29

Why don't you take it to the architecture team? He is probably resisting extra work and meetings
– Kate Gregory
Sep 5 '14 at 17:01

Why don't you take it to the architecture team? He is probably resisting extra work and meetings
– Kate Gregory
Sep 5 '14 at 17:01

@KateGregory, I am fine with that. But my main concern is every meeting with him is ending up with personal comments on me instead of ending up with constructive discussion.
– Babu
Sep 6 '14 at 0:31

@KateGregory, I am fine with that. But my main concern is every meeting with him is ending up with personal comments on me instead of ending up with constructive discussion.
– Babu
Sep 6 '14 at 0:31

1

1

*comments removed* Remember what comments are for. For extended discussions, Get a Room (a chat room).
– Elysian Fields♦
Sep 6 '14 at 15:50

*comments removed* Remember what comments are for. For extended discussions, Get a Room (a chat room).
– Elysian Fields♦
Sep 6 '14 at 15:50

 | 
show 1 more comment

3 Answers
3

active

oldest

votes

up vote
17
down vote

If "team lead" is a supervisor or managerial position, and therefore grants you any actual authority over him, you tell him that the discussion's over, you made your decision, and he needs to deal with it.

If "team lead" isn't a position that grants you extra authority, but rather makes you just the most senior person in the group, then you take the issue to your manager and let him deal with it. And whatever the manager decides is what you do.

Either way, if a discussion isn't going to be productive and simply turn into arguing, simply don't have one, because nothing but bad feelings are coming out of it.

And, as it may apply to the general dynamic, I'll relate an old political trick or axiom that may come in handy. Always concede on principle. If you tell someone they're right, in principle, you'd be surprised how often you can to them to agree to the exact opposite in practice.

Sometimes if you tell someone they're right, you can get them to concede on the more important tangible issues. Reagan launched a campaign for an MX weapon that got rejected by congress. But, when he told congress he agreed that the weapon was bad and wanted to do the best he could and improve upon it they agreed and he got what he wanted. The principle is negligible next to your real objectives. Reagan repeated the trick when lobbying for military aid to the rebels fighting the communist government of Nicaragua. No one liked it, but when he admitted and agreed with them that the rebels they were helping were killing innocents he got them to support him and he got to help the rebels anyway. "Yield to a man's tastes, and he will yield to your interests."-Edward Bulwer Lytton, 1835.

(Incidentally, the above quote is from some wiki summaries page for the book Hardball: How Politics Is Played Told By One Who Knows The Game, by Chris Matthews, which is a really excellent read for anyone who wants some insight into politics... or office politics, or people in general, but I digress.)

In your case, I imagine it would go something like "you're right that the cs.x file isn't really architecture, and your solution is the right way to fix it. Let's go through the process anyway and get the architecture team to sign off on the change just to protect ourselves, in case some other team screws something up and is looking for someone to blame."

share|improve this answer

edited Sep 5 '14 at 3:00

answered Sep 4 '14 at 22:23

HopelessN00b

9,78041753

• 
  
  
  

  
  

  
  
  
  
  
  

  
  +1 for the "Concede on principle". This is a key to success which is often ignored, while everyone fights his "I am right, you are wrong" game all day.
  – TheBlastOne
  Nov 28 '14 at 8:29
  

  
  
  
  

suggest improvements | 

up vote
10
down vote

I've been in this position as the developer quite a few times, and hopefully by explaining it from their perspective, you can understand better. My quotes are what I understand the dev is saying/hearing.

" Babu, I found there is an issue in x.cs file, I found the root cause is due to line no 10. I have removed and going to check in. I think similar changes needs to be done in our frame work."

"Hey boss, I ran into a tiny issue. Because I'm a productive employee, I even went so far as to fix it. I wanted you let you know so you can help deal with all the stupid political crap that is going to come out of this and so you can prioritize the new work."

"Hi Dev, Thanks for you findings. Appreciate it. Please report such issues to me and architecture team. Architecture team is the one who really owns the frame work. Any issues with the framework we have to report that team and ask them to fix instead we making the changes and taking that accountability"

"I don't have the balls to do what you need, and/or I don't trust you to do your job."

"I don’t think it’s an architecture change. I feel it’s a simple code change in a common file"

"Come on, this is a trivial change, my lead should be helping me to do my job, not throwing more bureaucracy in the way of getting things done."

...and things go slightly downhill from there.

While your team member could have handled things better, I'm not sure he's taking things negatively. You basically insinuated that you don't trust him/her to do their job well enough to take accountability for their fix on a trivial change. You ignore his request for help, and actively prevented him from doing what most developers prize over all: getting things done.

By setting yourself up as someone who impedes getting things done, you become the enemy.

And from my own experience, you should be very concerned if your developer is at this point. If they will openly argue with you, it's because they think it is their only recourse to make their (work) lives better. Very quickly, they will find out that even that isn't working and look for different work.

This article is a great foundation for learning how nerds think, and how to manage them. The blog itself is an invaluable resource for insights into how to successfully manage software developers.

share|improve this answer

answered Sep 5 '14 at 13:54

Telastyn

33.9k977120

suggest improvements | 

up vote
-2
down vote

Nail him to the wall.

Here is one reason why you are the TL and he is not: you clearly see that the Architecture team owns the responsibility and that they should be the one making the change in the way that they see fit, and he doesn't see anything. He is older, but older doesn't automatically mean wiser. Or smarter. Anymore than being experienced automatically means having learned from the experience.

If you implement the change in the way that your subordinate insists, you are going behind the back of the Architecture team. I'd say that the Architecture team has enough to get done without having to worry about who is tinkering with codebase while they're not looking. And you are probably quite aware that changes that seem trivial may have consequences that are anything but trivial.

Your team member is acting like a rogue violonist in an orchestra that is playing a symphony. This cannot stand.

The sooner you layeth the smack down and assert your authority - hopefully,in a not so gentle way with him - the quicker and the more thoroughly there will be peace in the land.

Personal remarks are a clear indicator that he doesn't like you. That's fine. All you want out of him is respect, and circumspection.

share|improve this answer

edited Sep 5 '14 at 13:44

answered Sep 4 '14 at 22:14

Vietnhi Phuvan

68.9k7118254

suggest improvements | 

3 Answers
3

active

oldest

votes

3 Answers
3

active

oldest

votes

active

oldest

votes

active

oldest

votes

up vote
17
down vote

If "team lead" is a supervisor or managerial position, and therefore grants you any actual authority over him, you tell him that the discussion's over, you made your decision, and he needs to deal with it.

If "team lead" isn't a position that grants you extra authority, but rather makes you just the most senior person in the group, then you take the issue to your manager and let him deal with it. And whatever the manager decides is what you do.

Either way, if a discussion isn't going to be productive and simply turn into arguing, simply don't have one, because nothing but bad feelings are coming out of it.

And, as it may apply to the general dynamic, I'll relate an old political trick or axiom that may come in handy. Always concede on principle. If you tell someone they're right, in principle, you'd be surprised how often you can to them to agree to the exact opposite in practice.

Sometimes if you tell someone they're right, you can get them to concede on the more important tangible issues. Reagan launched a campaign for an MX weapon that got rejected by congress. But, when he told congress he agreed that the weapon was bad and wanted to do the best he could and improve upon it they agreed and he got what he wanted. The principle is negligible next to your real objectives. Reagan repeated the trick when lobbying for military aid to the rebels fighting the communist government of Nicaragua. No one liked it, but when he admitted and agreed with them that the rebels they were helping were killing innocents he got them to support him and he got to help the rebels anyway. "Yield to a man's tastes, and he will yield to your interests."-Edward Bulwer Lytton, 1835.

(Incidentally, the above quote is from some wiki summaries page for the book Hardball: How Politics Is Played Told By One Who Knows The Game, by Chris Matthews, which is a really excellent read for anyone who wants some insight into politics... or office politics, or people in general, but I digress.)

In your case, I imagine it would go something like "you're right that the cs.x file isn't really architecture, and your solution is the right way to fix it. Let's go through the process anyway and get the architecture team to sign off on the change just to protect ourselves, in case some other team screws something up and is looking for someone to blame."

share|improve this answer

edited Sep 5 '14 at 3:00

answered Sep 4 '14 at 22:23

HopelessN00b

9,78041753

• 
  
  
  

  
  

  
  
  
  
  
  

  
  +1 for the "Concede on principle". This is a key to success which is often ignored, while everyone fights his "I am right, you are wrong" game all day.
  – TheBlastOne
  Nov 28 '14 at 8:29
  

  
  
  
  

suggest improvements | 

up vote
17
down vote

If "team lead" is a supervisor or managerial position, and therefore grants you any actual authority over him, you tell him that the discussion's over, you made your decision, and he needs to deal with it.

If "team lead" isn't a position that grants you extra authority, but rather makes you just the most senior person in the group, then you take the issue to your manager and let him deal with it. And whatever the manager decides is what you do.

Either way, if a discussion isn't going to be productive and simply turn into arguing, simply don't have one, because nothing but bad feelings are coming out of it.

And, as it may apply to the general dynamic, I'll relate an old political trick or axiom that may come in handy. Always concede on principle. If you tell someone they're right, in principle, you'd be surprised how often you can to them to agree to the exact opposite in practice.

Sometimes if you tell someone they're right, you can get them to concede on the more important tangible issues. Reagan launched a campaign for an MX weapon that got rejected by congress. But, when he told congress he agreed that the weapon was bad and wanted to do the best he could and improve upon it they agreed and he got what he wanted. The principle is negligible next to your real objectives. Reagan repeated the trick when lobbying for military aid to the rebels fighting the communist government of Nicaragua. No one liked it, but when he admitted and agreed with them that the rebels they were helping were killing innocents he got them to support him and he got to help the rebels anyway. "Yield to a man's tastes, and he will yield to your interests."-Edward Bulwer Lytton, 1835.

(Incidentally, the above quote is from some wiki summaries page for the book Hardball: How Politics Is Played Told By One Who Knows The Game, by Chris Matthews, which is a really excellent read for anyone who wants some insight into politics... or office politics, or people in general, but I digress.)

In your case, I imagine it would go something like "you're right that the cs.x file isn't really architecture, and your solution is the right way to fix it. Let's go through the process anyway and get the architecture team to sign off on the change just to protect ourselves, in case some other team screws something up and is looking for someone to blame."

share|improve this answer

edited Sep 5 '14 at 3:00

answered Sep 4 '14 at 22:23

HopelessN00b

9,78041753

• 
  
  
  

  
  

  
  
  
  
  
  

  
  +1 for the "Concede on principle". This is a key to success which is often ignored, while everyone fights his "I am right, you are wrong" game all day.
  – TheBlastOne
  Nov 28 '14 at 8:29
  

  
  
  
  

suggest improvements | 

up vote
17
down vote

up vote
17
down vote

If "team lead" is a supervisor or managerial position, and therefore grants you any actual authority over him, you tell him that the discussion's over, you made your decision, and he needs to deal with it.

If "team lead" isn't a position that grants you extra authority, but rather makes you just the most senior person in the group, then you take the issue to your manager and let him deal with it. And whatever the manager decides is what you do.

Either way, if a discussion isn't going to be productive and simply turn into arguing, simply don't have one, because nothing but bad feelings are coming out of it.

And, as it may apply to the general dynamic, I'll relate an old political trick or axiom that may come in handy. Always concede on principle. If you tell someone they're right, in principle, you'd be surprised how often you can to them to agree to the exact opposite in practice.

Sometimes if you tell someone they're right, you can get them to concede on the more important tangible issues. Reagan launched a campaign for an MX weapon that got rejected by congress. But, when he told congress he agreed that the weapon was bad and wanted to do the best he could and improve upon it they agreed and he got what he wanted. The principle is negligible next to your real objectives. Reagan repeated the trick when lobbying for military aid to the rebels fighting the communist government of Nicaragua. No one liked it, but when he admitted and agreed with them that the rebels they were helping were killing innocents he got them to support him and he got to help the rebels anyway. "Yield to a man's tastes, and he will yield to your interests."-Edward Bulwer Lytton, 1835.

(Incidentally, the above quote is from some wiki summaries page for the book Hardball: How Politics Is Played Told By One Who Knows The Game, by Chris Matthews, which is a really excellent read for anyone who wants some insight into politics... or office politics, or people in general, but I digress.)

In your case, I imagine it would go something like "you're right that the cs.x file isn't really architecture, and your solution is the right way to fix it. Let's go through the process anyway and get the architecture team to sign off on the change just to protect ourselves, in case some other team screws something up and is looking for someone to blame."

share|improve this answer

edited Sep 5 '14 at 3:00

answered Sep 4 '14 at 22:23

HopelessN00b

9,78041753

If "team lead" is a supervisor or managerial position, and therefore grants you any actual authority over him, you tell him that the discussion's over, you made your decision, and he needs to deal with it.

If "team lead" isn't a position that grants you extra authority, but rather makes you just the most senior person in the group, then you take the issue to your manager and let him deal with it. And whatever the manager decides is what you do.

Either way, if a discussion isn't going to be productive and simply turn into arguing, simply don't have one, because nothing but bad feelings are coming out of it.

And, as it may apply to the general dynamic, I'll relate an old political trick or axiom that may come in handy. Always concede on principle. If you tell someone they're right, in principle, you'd be surprised how often you can to them to agree to the exact opposite in practice.

Sometimes if you tell someone they're right, you can get them to concede on the more important tangible issues. Reagan launched a campaign for an MX weapon that got rejected by congress. But, when he told congress he agreed that the weapon was bad and wanted to do the best he could and improve upon it they agreed and he got what he wanted. The principle is negligible next to your real objectives. Reagan repeated the trick when lobbying for military aid to the rebels fighting the communist government of Nicaragua. No one liked it, but when he admitted and agreed with them that the rebels they were helping were killing innocents he got them to support him and he got to help the rebels anyway. "Yield to a man's tastes, and he will yield to your interests."-Edward Bulwer Lytton, 1835.

(Incidentally, the above quote is from some wiki summaries page for the book Hardball: How Politics Is Played Told By One Who Knows The Game, by Chris Matthews, which is a really excellent read for anyone who wants some insight into politics... or office politics, or people in general, but I digress.)

In your case, I imagine it would go something like "you're right that the cs.x file isn't really architecture, and your solution is the right way to fix it. Let's go through the process anyway and get the architecture team to sign off on the change just to protect ourselves, in case some other team screws something up and is looking for someone to blame."

share|improve this answer

edited Sep 5 '14 at 3:00

answered Sep 4 '14 at 22:23

HopelessN00b

9,78041753

share|improve this answer

share|improve this answer

edited Sep 5 '14 at 3:00

edited Sep 5 '14 at 3:00

edited Sep 5 '14 at 3:00

answered Sep 4 '14 at 22:23

HopelessN00b

9,78041753

answered Sep 4 '14 at 22:23

HopelessN00b

9,78041753

answered Sep 4 '14 at 22:23

HopelessN00b

9,78041753

9,78041753

• 
  
  
  

  
  

  
  
  
  
  
  

  
  +1 for the "Concede on principle". This is a key to success which is often ignored, while everyone fights his "I am right, you are wrong" game all day.
  – TheBlastOne
  Nov 28 '14 at 8:29
  

  
  
  
  

suggest improvements | 

• 
  
  
  

  
  

  
  
  
  
  
  

  
  +1 for the "Concede on principle". This is a key to success which is often ignored, while everyone fights his "I am right, you are wrong" game all day.
  – TheBlastOne
  Nov 28 '14 at 8:29
  

  
  
  
  

+1 for the "Concede on principle". This is a key to success which is often ignored, while everyone fights his "I am right, you are wrong" game all day.
– TheBlastOne
Nov 28 '14 at 8:29

+1 for the "Concede on principle". This is a key to success which is often ignored, while everyone fights his "I am right, you are wrong" game all day.
– TheBlastOne
Nov 28 '14 at 8:29

suggest improvements | 

up vote
10
down vote

I've been in this position as the developer quite a few times, and hopefully by explaining it from their perspective, you can understand better. My quotes are what I understand the dev is saying/hearing.

" Babu, I found there is an issue in x.cs file, I found the root cause is due to line no 10. I have removed and going to check in. I think similar changes needs to be done in our frame work."

"Hey boss, I ran into a tiny issue. Because I'm a productive employee, I even went so far as to fix it. I wanted you let you know so you can help deal with all the stupid political crap that is going to come out of this and so you can prioritize the new work."

"Hi Dev, Thanks for you findings. Appreciate it. Please report such issues to me and architecture team. Architecture team is the one who really owns the frame work. Any issues with the framework we have to report that team and ask them to fix instead we making the changes and taking that accountability"

"I don't have the balls to do what you need, and/or I don't trust you to do your job."

"I don’t think it’s an architecture change. I feel it’s a simple code change in a common file"

"Come on, this is a trivial change, my lead should be helping me to do my job, not throwing more bureaucracy in the way of getting things done."

...and things go slightly downhill from there.

While your team member could have handled things better, I'm not sure he's taking things negatively. You basically insinuated that you don't trust him/her to do their job well enough to take accountability for their fix on a trivial change. You ignore his request for help, and actively prevented him from doing what most developers prize over all: getting things done.

By setting yourself up as someone who impedes getting things done, you become the enemy.

And from my own experience, you should be very concerned if your developer is at this point. If they will openly argue with you, it's because they think it is their only recourse to make their (work) lives better. Very quickly, they will find out that even that isn't working and look for different work.

This article is a great foundation for learning how nerds think, and how to manage them. The blog itself is an invaluable resource for insights into how to successfully manage software developers.

share|improve this answer

answered Sep 5 '14 at 13:54

Telastyn

33.9k977120

suggest improvements | 

up vote
10
down vote

I've been in this position as the developer quite a few times, and hopefully by explaining it from their perspective, you can understand better. My quotes are what I understand the dev is saying/hearing.

" Babu, I found there is an issue in x.cs file, I found the root cause is due to line no 10. I have removed and going to check in. I think similar changes needs to be done in our frame work."

"Hey boss, I ran into a tiny issue. Because I'm a productive employee, I even went so far as to fix it. I wanted you let you know so you can help deal with all the stupid political crap that is going to come out of this and so you can prioritize the new work."

"Hi Dev, Thanks for you findings. Appreciate it. Please report such issues to me and architecture team. Architecture team is the one who really owns the frame work. Any issues with the framework we have to report that team and ask them to fix instead we making the changes and taking that accountability"

"I don't have the balls to do what you need, and/or I don't trust you to do your job."

"I don’t think it’s an architecture change. I feel it’s a simple code change in a common file"

"Come on, this is a trivial change, my lead should be helping me to do my job, not throwing more bureaucracy in the way of getting things done."

...and things go slightly downhill from there.

While your team member could have handled things better, I'm not sure he's taking things negatively. You basically insinuated that you don't trust him/her to do their job well enough to take accountability for their fix on a trivial change. You ignore his request for help, and actively prevented him from doing what most developers prize over all: getting things done.

By setting yourself up as someone who impedes getting things done, you become the enemy.

And from my own experience, you should be very concerned if your developer is at this point. If they will openly argue with you, it's because they think it is their only recourse to make their (work) lives better. Very quickly, they will find out that even that isn't working and look for different work.

This article is a great foundation for learning how nerds think, and how to manage them. The blog itself is an invaluable resource for insights into how to successfully manage software developers.

share|improve this answer

answered Sep 5 '14 at 13:54

Telastyn

33.9k977120

suggest improvements | 

up vote
10
down vote

up vote
10
down vote

I've been in this position as the developer quite a few times, and hopefully by explaining it from their perspective, you can understand better. My quotes are what I understand the dev is saying/hearing.

" Babu, I found there is an issue in x.cs file, I found the root cause is due to line no 10. I have removed and going to check in. I think similar changes needs to be done in our frame work."

"Hey boss, I ran into a tiny issue. Because I'm a productive employee, I even went so far as to fix it. I wanted you let you know so you can help deal with all the stupid political crap that is going to come out of this and so you can prioritize the new work."

"Hi Dev, Thanks for you findings. Appreciate it. Please report such issues to me and architecture team. Architecture team is the one who really owns the frame work. Any issues with the framework we have to report that team and ask them to fix instead we making the changes and taking that accountability"

"I don't have the balls to do what you need, and/or I don't trust you to do your job."

"I don’t think it’s an architecture change. I feel it’s a simple code change in a common file"

"Come on, this is a trivial change, my lead should be helping me to do my job, not throwing more bureaucracy in the way of getting things done."

...and things go slightly downhill from there.

While your team member could have handled things better, I'm not sure he's taking things negatively. You basically insinuated that you don't trust him/her to do their job well enough to take accountability for their fix on a trivial change. You ignore his request for help, and actively prevented him from doing what most developers prize over all: getting things done.

By setting yourself up as someone who impedes getting things done, you become the enemy.

And from my own experience, you should be very concerned if your developer is at this point. If they will openly argue with you, it's because they think it is their only recourse to make their (work) lives better. Very quickly, they will find out that even that isn't working and look for different work.

This article is a great foundation for learning how nerds think, and how to manage them. The blog itself is an invaluable resource for insights into how to successfully manage software developers.

share|improve this answer

answered Sep 5 '14 at 13:54

Telastyn

33.9k977120

I've been in this position as the developer quite a few times, and hopefully by explaining it from their perspective, you can understand better. My quotes are what I understand the dev is saying/hearing.

" Babu, I found there is an issue in x.cs file, I found the root cause is due to line no 10. I have removed and going to check in. I think similar changes needs to be done in our frame work."

"Hey boss, I ran into a tiny issue. Because I'm a productive employee, I even went so far as to fix it. I wanted you let you know so you can help deal with all the stupid political crap that is going to come out of this and so you can prioritize the new work."

"Hi Dev, Thanks for you findings. Appreciate it. Please report such issues to me and architecture team. Architecture team is the one who really owns the frame work. Any issues with the framework we have to report that team and ask them to fix instead we making the changes and taking that accountability"

"I don't have the balls to do what you need, and/or I don't trust you to do your job."

"I don’t think it’s an architecture change. I feel it’s a simple code change in a common file"

"Come on, this is a trivial change, my lead should be helping me to do my job, not throwing more bureaucracy in the way of getting things done."

...and things go slightly downhill from there.

While your team member could have handled things better, I'm not sure he's taking things negatively. You basically insinuated that you don't trust him/her to do their job well enough to take accountability for their fix on a trivial change. You ignore his request for help, and actively prevented him from doing what most developers prize over all: getting things done.

By setting yourself up as someone who impedes getting things done, you become the enemy.

And from my own experience, you should be very concerned if your developer is at this point. If they will openly argue with you, it's because they think it is their only recourse to make their (work) lives better. Very quickly, they will find out that even that isn't working and look for different work.

This article is a great foundation for learning how nerds think, and how to manage them. The blog itself is an invaluable resource for insights into how to successfully manage software developers.

share|improve this answer

answered Sep 5 '14 at 13:54

Telastyn

33.9k977120

share|improve this answer

share|improve this answer

answered Sep 5 '14 at 13:54

Telastyn

33.9k977120

answered Sep 5 '14 at 13:54

Telastyn

33.9k977120

answered Sep 5 '14 at 13:54

Telastyn

33.9k977120

33.9k977120

suggest improvements | 

suggest improvements | 

up vote
-2
down vote

Nail him to the wall.

Here is one reason why you are the TL and he is not: you clearly see that the Architecture team owns the responsibility and that they should be the one making the change in the way that they see fit, and he doesn't see anything. He is older, but older doesn't automatically mean wiser. Or smarter. Anymore than being experienced automatically means having learned from the experience.

If you implement the change in the way that your subordinate insists, you are going behind the back of the Architecture team. I'd say that the Architecture team has enough to get done without having to worry about who is tinkering with codebase while they're not looking. And you are probably quite aware that changes that seem trivial may have consequences that are anything but trivial.

Your team member is acting like a rogue violonist in an orchestra that is playing a symphony. This cannot stand.

The sooner you layeth the smack down and assert your authority - hopefully,in a not so gentle way with him - the quicker and the more thoroughly there will be peace in the land.

Personal remarks are a clear indicator that he doesn't like you. That's fine. All you want out of him is respect, and circumspection.

share|improve this answer

edited Sep 5 '14 at 13:44

answered Sep 4 '14 at 22:14

Vietnhi Phuvan

68.9k7118254

suggest improvements | 

up vote
-2
down vote

Nail him to the wall.

Here is one reason why you are the TL and he is not: you clearly see that the Architecture team owns the responsibility and that they should be the one making the change in the way that they see fit, and he doesn't see anything. He is older, but older doesn't automatically mean wiser. Or smarter. Anymore than being experienced automatically means having learned from the experience.

If you implement the change in the way that your subordinate insists, you are going behind the back of the Architecture team. I'd say that the Architecture team has enough to get done without having to worry about who is tinkering with codebase while they're not looking. And you are probably quite aware that changes that seem trivial may have consequences that are anything but trivial.

Your team member is acting like a rogue violonist in an orchestra that is playing a symphony. This cannot stand.

The sooner you layeth the smack down and assert your authority - hopefully,in a not so gentle way with him - the quicker and the more thoroughly there will be peace in the land.

Personal remarks are a clear indicator that he doesn't like you. That's fine. All you want out of him is respect, and circumspection.

share|improve this answer

edited Sep 5 '14 at 13:44

answered Sep 4 '14 at 22:14

Vietnhi Phuvan

68.9k7118254

suggest improvements | 

up vote
-2
down vote

up vote
-2
down vote

Nail him to the wall.

Here is one reason why you are the TL and he is not: you clearly see that the Architecture team owns the responsibility and that they should be the one making the change in the way that they see fit, and he doesn't see anything. He is older, but older doesn't automatically mean wiser. Or smarter. Anymore than being experienced automatically means having learned from the experience.

If you implement the change in the way that your subordinate insists, you are going behind the back of the Architecture team. I'd say that the Architecture team has enough to get done without having to worry about who is tinkering with codebase while they're not looking. And you are probably quite aware that changes that seem trivial may have consequences that are anything but trivial.

Your team member is acting like a rogue violonist in an orchestra that is playing a symphony. This cannot stand.

The sooner you layeth the smack down and assert your authority - hopefully,in a not so gentle way with him - the quicker and the more thoroughly there will be peace in the land.

Personal remarks are a clear indicator that he doesn't like you. That's fine. All you want out of him is respect, and circumspection.

share|improve this answer

edited Sep 5 '14 at 13:44

answered Sep 4 '14 at 22:14

Vietnhi Phuvan

68.9k7118254

Nail him to the wall.

Here is one reason why you are the TL and he is not: you clearly see that the Architecture team owns the responsibility and that they should be the one making the change in the way that they see fit, and he doesn't see anything. He is older, but older doesn't automatically mean wiser. Or smarter. Anymore than being experienced automatically means having learned from the experience.

If you implement the change in the way that your subordinate insists, you are going behind the back of the Architecture team. I'd say that the Architecture team has enough to get done without having to worry about who is tinkering with codebase while they're not looking. And you are probably quite aware that changes that seem trivial may have consequences that are anything but trivial.

Your team member is acting like a rogue violonist in an orchestra that is playing a symphony. This cannot stand.

The sooner you layeth the smack down and assert your authority - hopefully,in a not so gentle way with him - the quicker and the more thoroughly there will be peace in the land.

Personal remarks are a clear indicator that he doesn't like you. That's fine. All you want out of him is respect, and circumspection.

share|improve this answer

edited Sep 5 '14 at 13:44

answered Sep 4 '14 at 22:14

Vietnhi Phuvan

68.9k7118254

share|improve this answer

share|improve this answer

edited Sep 5 '14 at 13:44

edited Sep 5 '14 at 13:44

edited Sep 5 '14 at 13:44

answered Sep 4 '14 at 22:14

Vietnhi Phuvan

68.9k7118254

answered Sep 4 '14 at 22:14

Vietnhi Phuvan

68.9k7118254

answered Sep 4 '14 at 22:14

Vietnhi Phuvan

68.9k7118254

68.9k7118254

suggest improvements | 

suggest improvements |