Working with an incompatible project leader
Clash Royale CLAN TAG#URR8PPP
.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty margin-bottom:0;
up vote
6
down vote
favorite
I am working in IT industry as a Sr developer. Recently there has been a change in my project and my project lead has been changed and now I am to report and work with this new lead. During last few weeks I have found that my view points are not compatible with his. For example, if working on a new design he propose changes which I do not agree with.
Also I have tried to cross verify my views with another experienced person on project who not working on my module and found that I was correct at most of the places. Now the problem is I am the only one to work with this new lead, and rest of Sr leadership is not directly involved in the project and are onsite. I am not sure how do I deal with situation.
relationships
migrated from productivity.stackexchange.com Feb 23 '13 at 16:14
This question came from our site for people wanting to improve their personal productivity.
add a comment |Â
up vote
6
down vote
favorite
I am working in IT industry as a Sr developer. Recently there has been a change in my project and my project lead has been changed and now I am to report and work with this new lead. During last few weeks I have found that my view points are not compatible with his. For example, if working on a new design he propose changes which I do not agree with.
Also I have tried to cross verify my views with another experienced person on project who not working on my module and found that I was correct at most of the places. Now the problem is I am the only one to work with this new lead, and rest of Sr leadership is not directly involved in the project and are onsite. I am not sure how do I deal with situation.
relationships
migrated from productivity.stackexchange.com Feb 23 '13 at 16:14
This question came from our site for people wanting to improve their personal productivity.
Sorry @elssar, I wasn't aware of that SE. can it be moved now?
– mehta
Feb 22 '13 at 11:57
Yes, flag your question for moderator attention and they can migrate it.
– Joe Baker
Feb 22 '13 at 13:23
There is a project leader and one sr dev on the project? What kind of team is that?
– user8365
Feb 25 '13 at 1:43
3
The one responsible for the project gets to make the final decisions. Even senior developers need to respect this - it is part of being a professional.
– Thorbjørn Ravn Andersen
Feb 25 '13 at 7:24
add a comment |Â
up vote
6
down vote
favorite
up vote
6
down vote
favorite
I am working in IT industry as a Sr developer. Recently there has been a change in my project and my project lead has been changed and now I am to report and work with this new lead. During last few weeks I have found that my view points are not compatible with his. For example, if working on a new design he propose changes which I do not agree with.
Also I have tried to cross verify my views with another experienced person on project who not working on my module and found that I was correct at most of the places. Now the problem is I am the only one to work with this new lead, and rest of Sr leadership is not directly involved in the project and are onsite. I am not sure how do I deal with situation.
relationships
I am working in IT industry as a Sr developer. Recently there has been a change in my project and my project lead has been changed and now I am to report and work with this new lead. During last few weeks I have found that my view points are not compatible with his. For example, if working on a new design he propose changes which I do not agree with.
Also I have tried to cross verify my views with another experienced person on project who not working on my module and found that I was correct at most of the places. Now the problem is I am the only one to work with this new lead, and rest of Sr leadership is not directly involved in the project and are onsite. I am not sure how do I deal with situation.
relationships
asked Feb 22 '13 at 8:56
mehta
21226
21226
migrated from productivity.stackexchange.com Feb 23 '13 at 16:14
This question came from our site for people wanting to improve their personal productivity.
migrated from productivity.stackexchange.com Feb 23 '13 at 16:14
This question came from our site for people wanting to improve their personal productivity.
Sorry @elssar, I wasn't aware of that SE. can it be moved now?
– mehta
Feb 22 '13 at 11:57
Yes, flag your question for moderator attention and they can migrate it.
– Joe Baker
Feb 22 '13 at 13:23
There is a project leader and one sr dev on the project? What kind of team is that?
– user8365
Feb 25 '13 at 1:43
3
The one responsible for the project gets to make the final decisions. Even senior developers need to respect this - it is part of being a professional.
– Thorbjørn Ravn Andersen
Feb 25 '13 at 7:24
add a comment |Â
Sorry @elssar, I wasn't aware of that SE. can it be moved now?
– mehta
Feb 22 '13 at 11:57
Yes, flag your question for moderator attention and they can migrate it.
– Joe Baker
Feb 22 '13 at 13:23
There is a project leader and one sr dev on the project? What kind of team is that?
– user8365
Feb 25 '13 at 1:43
3
The one responsible for the project gets to make the final decisions. Even senior developers need to respect this - it is part of being a professional.
– Thorbjørn Ravn Andersen
Feb 25 '13 at 7:24
Sorry @elssar, I wasn't aware of that SE. can it be moved now?
– mehta
Feb 22 '13 at 11:57
Sorry @elssar, I wasn't aware of that SE. can it be moved now?
– mehta
Feb 22 '13 at 11:57
Yes, flag your question for moderator attention and they can migrate it.
– Joe Baker
Feb 22 '13 at 13:23
Yes, flag your question for moderator attention and they can migrate it.
– Joe Baker
Feb 22 '13 at 13:23
There is a project leader and one sr dev on the project? What kind of team is that?
– user8365
Feb 25 '13 at 1:43
There is a project leader and one sr dev on the project? What kind of team is that?
– user8365
Feb 25 '13 at 1:43
3
3
The one responsible for the project gets to make the final decisions. Even senior developers need to respect this - it is part of being a professional.
– Thorbjørn Ravn Andersen
Feb 25 '13 at 7:24
The one responsible for the project gets to make the final decisions. Even senior developers need to respect this - it is part of being a professional.
– Thorbjørn Ravn Andersen
Feb 25 '13 at 7:24
add a comment |Â
6 Answers
6
active
oldest
votes
up vote
8
down vote
Decisions aren't always right and wrong. Which means another person agreeing with you doesn't mean you are "correct", it merely means you have a viewpoint that someone else has.
If you think your project lead is wrong and his decisions will harm the project/company, you need to talk about it. List pros/cons. Or the possible side effects of his decision. Sometimes new people to a team don't have all the necessary information and don't realize they are making a "bad" decision.
On the other hand, it's also possible that you both have legitimate opinions. Or your project lead is prioritizing things differently. Or has more information than you do. Or has other experiences that lead to a different conclusion. All of these are fine and you'll need to respect his decision.
1
Excellent points. Protesting too much is just counter-productive and a sign of someone not being a team player.
– user8365
Feb 25 '13 at 1:44
add a comment |Â
up vote
6
down vote
For example, if working on a new design he propose changes which I do not agree with.
That will happen in software development (and I would expect, any design work). Now you need to actually collaborate with your teammate in order to figure out what design actually will be best for the company. Due to unknowns, you won't be sure. Since they are the lead, they are responsible for making that decision.
Also I have tried to cross verify my views with another experienced person on project who not working on my module and found that I was correct at most of the places.
There are many "correct" designs. Each have a variety of trade-offs that are made to emphasize some trait while decreasing others. Your lead may simply value those traits differently than you do. That does not make them wrong.
That you view design as simply being 'correct' or not makes me inclined to think that you are the problem more than your lead. Take a step back, argue for why your design is better, and be open to the idea that your team lead actually knows what they're doing.
Above all, communicate.
add a comment |Â
up vote
4
down vote
Get over it. You've made your objections and suggestions, so now it's time to get things done. That means you have to accept the leader or go find another job. You could ask to work on a prototype to make your point, but eventually, it's time to stop with the planning discussions and get the thing built.
I know as an engineer you feel there is an absolute right way, but as many have point ed out, it's not always black and white.
Your company has no mechanism for someone leaping over their leader when there are technical disagreements on projects. You can try and start something, but I doubt that will help this specific project.
If you implement the leader's ideas to the best of your ability and they fail, maybe they'll make you the leader and some jr. dev will want to implement some framework barely out of beta and accuse you of a bad design.
add a comment |Â
up vote
2
down vote
Don't fall into the trap of assuming you're correct simply because you've talked to another experienced person. Working in the software field, you need to change often to stay competitive. Some people simply don't like it when other people try to impose a paradigm shift: "We have always programmed this way and it has worked; why change it?"
I suggest you honestly try your best to work with this new person for a period of time, with an open mind. If it later turns out that it doesn't work for some reason, you need to raise the situation with upper management, because your cooperation difficulties may significantly damage your company. They'll need to be aware of the situation.
add a comment |Â
up vote
2
down vote
I struggled for years with this same thing and finally came upon a solution...which is going to sound a little hokey I think. But what I literally try and do every time I start finding myself in conflict with someone at work is:
a. Think about (or write down) the positive attributes of that person
b. Try and think about where they are coming from, why they think the way they do, why they won't listen, etc,
c. Think about how my messaging to them may be interpreted (do they see debate as a threat? am I too aggressive?, etc.)
d. Remind myself that they are probably a good person, with a family, who are doing the best they can each day.
e. Then just do my work and discuss professionally - consider all interactions with this person as learning experiences where I can get better. It would be nice if everyone agreed with me, though. :-)
There's this equation I picked up somewhere along the line: E + R = O, which stands for:
Event + Reaction = Outcome
I can't control the event necessarily, I can 100% control my reaction to the event --- and in so doing have some influence over the outcome. I've learned that getting mad, shutting up and/or quitting never gets me the "O" I'm after.
Good reply Paul. I agree that every situation makes you learn something. Thanks :)
– mehta
Feb 28 '13 at 6:02
add a comment |Â
up vote
1
down vote
Your question doesn't state whether you present alternatives and get shot down. If you're asking based solely on the fact that you're simply presented with an option you don't like, I'd suggest you either suck it in and do what's best for the team or constructively lay out options in a non-threatening manner.
If however you're being forced to implement design choices you don't agree with(for good, cogent reasons!) and your suggestions are being shot down, I'll suggest you provide documented communication (emails, design docs etc) that clearly state your own design . Such docs shouldn't be a comparison but neutrally presented. Make this design available to your lead preferably before he comes up with his, so he's more likely to give yours a fair look while doing his thing. It also has the benefit of making sure your views are on record in case the project goes to pieces due to poor design.
A question you should ask is : Does the alternate application design have a desirable outcome? Because at the end of the day, that is what matters: the project. If you're making a stand on a design choice , you need to be sure why you think yours is better or what the other guy's suggestion is doing to hurt the project.
It takes strength and maturity to take the high road in a clash of wills. It doesn't make you weak. You need to be able to put the project before opinion. Being the lead, ultimately the responsibility of the failure or success of the project rests on him.
add a comment |Â
StackExchange.ready(function ()
$("#show-editor-button input, #show-editor-button button").click(function ()
var showEditor = function()
$("#show-editor-button").hide();
$("#post-form").removeClass("dno");
StackExchange.editor.finallyInit();
;
var useFancy = $(this).data('confirm-use-fancy');
if(useFancy == 'True')
var popupTitle = $(this).data('confirm-fancy-title');
var popupBody = $(this).data('confirm-fancy-body');
var popupAccept = $(this).data('confirm-fancy-accept-button');
$(this).loadPopup(
url: '/post/self-answer-popup',
loaded: function(popup)
var pTitle = $(popup).find('h2');
var pBody = $(popup).find('.popup-body');
var pSubmit = $(popup).find('.popup-submit');
pTitle.text(popupTitle);
pBody.html(popupBody);
pSubmit.val(popupAccept).click(showEditor);
)
else
var confirmText = $(this).data('confirm-text');
if (confirmText ? confirm(confirmText) : true)
showEditor();
);
);
6 Answers
6
active
oldest
votes
6 Answers
6
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
8
down vote
Decisions aren't always right and wrong. Which means another person agreeing with you doesn't mean you are "correct", it merely means you have a viewpoint that someone else has.
If you think your project lead is wrong and his decisions will harm the project/company, you need to talk about it. List pros/cons. Or the possible side effects of his decision. Sometimes new people to a team don't have all the necessary information and don't realize they are making a "bad" decision.
On the other hand, it's also possible that you both have legitimate opinions. Or your project lead is prioritizing things differently. Or has more information than you do. Or has other experiences that lead to a different conclusion. All of these are fine and you'll need to respect his decision.
1
Excellent points. Protesting too much is just counter-productive and a sign of someone not being a team player.
– user8365
Feb 25 '13 at 1:44
add a comment |Â
up vote
8
down vote
Decisions aren't always right and wrong. Which means another person agreeing with you doesn't mean you are "correct", it merely means you have a viewpoint that someone else has.
If you think your project lead is wrong and his decisions will harm the project/company, you need to talk about it. List pros/cons. Or the possible side effects of his decision. Sometimes new people to a team don't have all the necessary information and don't realize they are making a "bad" decision.
On the other hand, it's also possible that you both have legitimate opinions. Or your project lead is prioritizing things differently. Or has more information than you do. Or has other experiences that lead to a different conclusion. All of these are fine and you'll need to respect his decision.
1
Excellent points. Protesting too much is just counter-productive and a sign of someone not being a team player.
– user8365
Feb 25 '13 at 1:44
add a comment |Â
up vote
8
down vote
up vote
8
down vote
Decisions aren't always right and wrong. Which means another person agreeing with you doesn't mean you are "correct", it merely means you have a viewpoint that someone else has.
If you think your project lead is wrong and his decisions will harm the project/company, you need to talk about it. List pros/cons. Or the possible side effects of his decision. Sometimes new people to a team don't have all the necessary information and don't realize they are making a "bad" decision.
On the other hand, it's also possible that you both have legitimate opinions. Or your project lead is prioritizing things differently. Or has more information than you do. Or has other experiences that lead to a different conclusion. All of these are fine and you'll need to respect his decision.
Decisions aren't always right and wrong. Which means another person agreeing with you doesn't mean you are "correct", it merely means you have a viewpoint that someone else has.
If you think your project lead is wrong and his decisions will harm the project/company, you need to talk about it. List pros/cons. Or the possible side effects of his decision. Sometimes new people to a team don't have all the necessary information and don't realize they are making a "bad" decision.
On the other hand, it's also possible that you both have legitimate opinions. Or your project lead is prioritizing things differently. Or has more information than you do. Or has other experiences that lead to a different conclusion. All of these are fine and you'll need to respect his decision.
answered Feb 23 '13 at 16:19
Jeanne Boyarsky
4,7741934
4,7741934
1
Excellent points. Protesting too much is just counter-productive and a sign of someone not being a team player.
– user8365
Feb 25 '13 at 1:44
add a comment |Â
1
Excellent points. Protesting too much is just counter-productive and a sign of someone not being a team player.
– user8365
Feb 25 '13 at 1:44
1
1
Excellent points. Protesting too much is just counter-productive and a sign of someone not being a team player.
– user8365
Feb 25 '13 at 1:44
Excellent points. Protesting too much is just counter-productive and a sign of someone not being a team player.
– user8365
Feb 25 '13 at 1:44
add a comment |Â
up vote
6
down vote
For example, if working on a new design he propose changes which I do not agree with.
That will happen in software development (and I would expect, any design work). Now you need to actually collaborate with your teammate in order to figure out what design actually will be best for the company. Due to unknowns, you won't be sure. Since they are the lead, they are responsible for making that decision.
Also I have tried to cross verify my views with another experienced person on project who not working on my module and found that I was correct at most of the places.
There are many "correct" designs. Each have a variety of trade-offs that are made to emphasize some trait while decreasing others. Your lead may simply value those traits differently than you do. That does not make them wrong.
That you view design as simply being 'correct' or not makes me inclined to think that you are the problem more than your lead. Take a step back, argue for why your design is better, and be open to the idea that your team lead actually knows what they're doing.
Above all, communicate.
add a comment |Â
up vote
6
down vote
For example, if working on a new design he propose changes which I do not agree with.
That will happen in software development (and I would expect, any design work). Now you need to actually collaborate with your teammate in order to figure out what design actually will be best for the company. Due to unknowns, you won't be sure. Since they are the lead, they are responsible for making that decision.
Also I have tried to cross verify my views with another experienced person on project who not working on my module and found that I was correct at most of the places.
There are many "correct" designs. Each have a variety of trade-offs that are made to emphasize some trait while decreasing others. Your lead may simply value those traits differently than you do. That does not make them wrong.
That you view design as simply being 'correct' or not makes me inclined to think that you are the problem more than your lead. Take a step back, argue for why your design is better, and be open to the idea that your team lead actually knows what they're doing.
Above all, communicate.
add a comment |Â
up vote
6
down vote
up vote
6
down vote
For example, if working on a new design he propose changes which I do not agree with.
That will happen in software development (and I would expect, any design work). Now you need to actually collaborate with your teammate in order to figure out what design actually will be best for the company. Due to unknowns, you won't be sure. Since they are the lead, they are responsible for making that decision.
Also I have tried to cross verify my views with another experienced person on project who not working on my module and found that I was correct at most of the places.
There are many "correct" designs. Each have a variety of trade-offs that are made to emphasize some trait while decreasing others. Your lead may simply value those traits differently than you do. That does not make them wrong.
That you view design as simply being 'correct' or not makes me inclined to think that you are the problem more than your lead. Take a step back, argue for why your design is better, and be open to the idea that your team lead actually knows what they're doing.
Above all, communicate.
For example, if working on a new design he propose changes which I do not agree with.
That will happen in software development (and I would expect, any design work). Now you need to actually collaborate with your teammate in order to figure out what design actually will be best for the company. Due to unknowns, you won't be sure. Since they are the lead, they are responsible for making that decision.
Also I have tried to cross verify my views with another experienced person on project who not working on my module and found that I was correct at most of the places.
There are many "correct" designs. Each have a variety of trade-offs that are made to emphasize some trait while decreasing others. Your lead may simply value those traits differently than you do. That does not make them wrong.
That you view design as simply being 'correct' or not makes me inclined to think that you are the problem more than your lead. Take a step back, argue for why your design is better, and be open to the idea that your team lead actually knows what they're doing.
Above all, communicate.
answered Feb 23 '13 at 17:47


Telastyn
33.9k977120
33.9k977120
add a comment |Â
add a comment |Â
up vote
4
down vote
Get over it. You've made your objections and suggestions, so now it's time to get things done. That means you have to accept the leader or go find another job. You could ask to work on a prototype to make your point, but eventually, it's time to stop with the planning discussions and get the thing built.
I know as an engineer you feel there is an absolute right way, but as many have point ed out, it's not always black and white.
Your company has no mechanism for someone leaping over their leader when there are technical disagreements on projects. You can try and start something, but I doubt that will help this specific project.
If you implement the leader's ideas to the best of your ability and they fail, maybe they'll make you the leader and some jr. dev will want to implement some framework barely out of beta and accuse you of a bad design.
add a comment |Â
up vote
4
down vote
Get over it. You've made your objections and suggestions, so now it's time to get things done. That means you have to accept the leader or go find another job. You could ask to work on a prototype to make your point, but eventually, it's time to stop with the planning discussions and get the thing built.
I know as an engineer you feel there is an absolute right way, but as many have point ed out, it's not always black and white.
Your company has no mechanism for someone leaping over their leader when there are technical disagreements on projects. You can try and start something, but I doubt that will help this specific project.
If you implement the leader's ideas to the best of your ability and they fail, maybe they'll make you the leader and some jr. dev will want to implement some framework barely out of beta and accuse you of a bad design.
add a comment |Â
up vote
4
down vote
up vote
4
down vote
Get over it. You've made your objections and suggestions, so now it's time to get things done. That means you have to accept the leader or go find another job. You could ask to work on a prototype to make your point, but eventually, it's time to stop with the planning discussions and get the thing built.
I know as an engineer you feel there is an absolute right way, but as many have point ed out, it's not always black and white.
Your company has no mechanism for someone leaping over their leader when there are technical disagreements on projects. You can try and start something, but I doubt that will help this specific project.
If you implement the leader's ideas to the best of your ability and they fail, maybe they'll make you the leader and some jr. dev will want to implement some framework barely out of beta and accuse you of a bad design.
Get over it. You've made your objections and suggestions, so now it's time to get things done. That means you have to accept the leader or go find another job. You could ask to work on a prototype to make your point, but eventually, it's time to stop with the planning discussions and get the thing built.
I know as an engineer you feel there is an absolute right way, but as many have point ed out, it's not always black and white.
Your company has no mechanism for someone leaping over their leader when there are technical disagreements on projects. You can try and start something, but I doubt that will help this specific project.
If you implement the leader's ideas to the best of your ability and they fail, maybe they'll make you the leader and some jr. dev will want to implement some framework barely out of beta and accuse you of a bad design.
answered Feb 25 '13 at 1:50
user8365
add a comment |Â
add a comment |Â
up vote
2
down vote
Don't fall into the trap of assuming you're correct simply because you've talked to another experienced person. Working in the software field, you need to change often to stay competitive. Some people simply don't like it when other people try to impose a paradigm shift: "We have always programmed this way and it has worked; why change it?"
I suggest you honestly try your best to work with this new person for a period of time, with an open mind. If it later turns out that it doesn't work for some reason, you need to raise the situation with upper management, because your cooperation difficulties may significantly damage your company. They'll need to be aware of the situation.
add a comment |Â
up vote
2
down vote
Don't fall into the trap of assuming you're correct simply because you've talked to another experienced person. Working in the software field, you need to change often to stay competitive. Some people simply don't like it when other people try to impose a paradigm shift: "We have always programmed this way and it has worked; why change it?"
I suggest you honestly try your best to work with this new person for a period of time, with an open mind. If it later turns out that it doesn't work for some reason, you need to raise the situation with upper management, because your cooperation difficulties may significantly damage your company. They'll need to be aware of the situation.
add a comment |Â
up vote
2
down vote
up vote
2
down vote
Don't fall into the trap of assuming you're correct simply because you've talked to another experienced person. Working in the software field, you need to change often to stay competitive. Some people simply don't like it when other people try to impose a paradigm shift: "We have always programmed this way and it has worked; why change it?"
I suggest you honestly try your best to work with this new person for a period of time, with an open mind. If it later turns out that it doesn't work for some reason, you need to raise the situation with upper management, because your cooperation difficulties may significantly damage your company. They'll need to be aware of the situation.
Don't fall into the trap of assuming you're correct simply because you've talked to another experienced person. Working in the software field, you need to change often to stay competitive. Some people simply don't like it when other people try to impose a paradigm shift: "We have always programmed this way and it has worked; why change it?"
I suggest you honestly try your best to work with this new person for a period of time, with an open mind. If it later turns out that it doesn't work for some reason, you need to raise the situation with upper management, because your cooperation difficulties may significantly damage your company. They'll need to be aware of the situation.
answered Feb 22 '13 at 9:08


Gruber
18915
18915
add a comment |Â
add a comment |Â
up vote
2
down vote
I struggled for years with this same thing and finally came upon a solution...which is going to sound a little hokey I think. But what I literally try and do every time I start finding myself in conflict with someone at work is:
a. Think about (or write down) the positive attributes of that person
b. Try and think about where they are coming from, why they think the way they do, why they won't listen, etc,
c. Think about how my messaging to them may be interpreted (do they see debate as a threat? am I too aggressive?, etc.)
d. Remind myself that they are probably a good person, with a family, who are doing the best they can each day.
e. Then just do my work and discuss professionally - consider all interactions with this person as learning experiences where I can get better. It would be nice if everyone agreed with me, though. :-)
There's this equation I picked up somewhere along the line: E + R = O, which stands for:
Event + Reaction = Outcome
I can't control the event necessarily, I can 100% control my reaction to the event --- and in so doing have some influence over the outcome. I've learned that getting mad, shutting up and/or quitting never gets me the "O" I'm after.
Good reply Paul. I agree that every situation makes you learn something. Thanks :)
– mehta
Feb 28 '13 at 6:02
add a comment |Â
up vote
2
down vote
I struggled for years with this same thing and finally came upon a solution...which is going to sound a little hokey I think. But what I literally try and do every time I start finding myself in conflict with someone at work is:
a. Think about (or write down) the positive attributes of that person
b. Try and think about where they are coming from, why they think the way they do, why they won't listen, etc,
c. Think about how my messaging to them may be interpreted (do they see debate as a threat? am I too aggressive?, etc.)
d. Remind myself that they are probably a good person, with a family, who are doing the best they can each day.
e. Then just do my work and discuss professionally - consider all interactions with this person as learning experiences where I can get better. It would be nice if everyone agreed with me, though. :-)
There's this equation I picked up somewhere along the line: E + R = O, which stands for:
Event + Reaction = Outcome
I can't control the event necessarily, I can 100% control my reaction to the event --- and in so doing have some influence over the outcome. I've learned that getting mad, shutting up and/or quitting never gets me the "O" I'm after.
Good reply Paul. I agree that every situation makes you learn something. Thanks :)
– mehta
Feb 28 '13 at 6:02
add a comment |Â
up vote
2
down vote
up vote
2
down vote
I struggled for years with this same thing and finally came upon a solution...which is going to sound a little hokey I think. But what I literally try and do every time I start finding myself in conflict with someone at work is:
a. Think about (or write down) the positive attributes of that person
b. Try and think about where they are coming from, why they think the way they do, why they won't listen, etc,
c. Think about how my messaging to them may be interpreted (do they see debate as a threat? am I too aggressive?, etc.)
d. Remind myself that they are probably a good person, with a family, who are doing the best they can each day.
e. Then just do my work and discuss professionally - consider all interactions with this person as learning experiences where I can get better. It would be nice if everyone agreed with me, though. :-)
There's this equation I picked up somewhere along the line: E + R = O, which stands for:
Event + Reaction = Outcome
I can't control the event necessarily, I can 100% control my reaction to the event --- and in so doing have some influence over the outcome. I've learned that getting mad, shutting up and/or quitting never gets me the "O" I'm after.
I struggled for years with this same thing and finally came upon a solution...which is going to sound a little hokey I think. But what I literally try and do every time I start finding myself in conflict with someone at work is:
a. Think about (or write down) the positive attributes of that person
b. Try and think about where they are coming from, why they think the way they do, why they won't listen, etc,
c. Think about how my messaging to them may be interpreted (do they see debate as a threat? am I too aggressive?, etc.)
d. Remind myself that they are probably a good person, with a family, who are doing the best they can each day.
e. Then just do my work and discuss professionally - consider all interactions with this person as learning experiences where I can get better. It would be nice if everyone agreed with me, though. :-)
There's this equation I picked up somewhere along the line: E + R = O, which stands for:
Event + Reaction = Outcome
I can't control the event necessarily, I can 100% control my reaction to the event --- and in so doing have some influence over the outcome. I've learned that getting mad, shutting up and/or quitting never gets me the "O" I'm after.
edited Feb 27 '13 at 20:23
CincinnatiProgrammer
2,75792862
2,75792862
answered Feb 27 '13 at 19:20
matthewp
1211
1211
Good reply Paul. I agree that every situation makes you learn something. Thanks :)
– mehta
Feb 28 '13 at 6:02
add a comment |Â
Good reply Paul. I agree that every situation makes you learn something. Thanks :)
– mehta
Feb 28 '13 at 6:02
Good reply Paul. I agree that every situation makes you learn something. Thanks :)
– mehta
Feb 28 '13 at 6:02
Good reply Paul. I agree that every situation makes you learn something. Thanks :)
– mehta
Feb 28 '13 at 6:02
add a comment |Â
up vote
1
down vote
Your question doesn't state whether you present alternatives and get shot down. If you're asking based solely on the fact that you're simply presented with an option you don't like, I'd suggest you either suck it in and do what's best for the team or constructively lay out options in a non-threatening manner.
If however you're being forced to implement design choices you don't agree with(for good, cogent reasons!) and your suggestions are being shot down, I'll suggest you provide documented communication (emails, design docs etc) that clearly state your own design . Such docs shouldn't be a comparison but neutrally presented. Make this design available to your lead preferably before he comes up with his, so he's more likely to give yours a fair look while doing his thing. It also has the benefit of making sure your views are on record in case the project goes to pieces due to poor design.
A question you should ask is : Does the alternate application design have a desirable outcome? Because at the end of the day, that is what matters: the project. If you're making a stand on a design choice , you need to be sure why you think yours is better or what the other guy's suggestion is doing to hurt the project.
It takes strength and maturity to take the high road in a clash of wills. It doesn't make you weak. You need to be able to put the project before opinion. Being the lead, ultimately the responsibility of the failure or success of the project rests on him.
add a comment |Â
up vote
1
down vote
Your question doesn't state whether you present alternatives and get shot down. If you're asking based solely on the fact that you're simply presented with an option you don't like, I'd suggest you either suck it in and do what's best for the team or constructively lay out options in a non-threatening manner.
If however you're being forced to implement design choices you don't agree with(for good, cogent reasons!) and your suggestions are being shot down, I'll suggest you provide documented communication (emails, design docs etc) that clearly state your own design . Such docs shouldn't be a comparison but neutrally presented. Make this design available to your lead preferably before he comes up with his, so he's more likely to give yours a fair look while doing his thing. It also has the benefit of making sure your views are on record in case the project goes to pieces due to poor design.
A question you should ask is : Does the alternate application design have a desirable outcome? Because at the end of the day, that is what matters: the project. If you're making a stand on a design choice , you need to be sure why you think yours is better or what the other guy's suggestion is doing to hurt the project.
It takes strength and maturity to take the high road in a clash of wills. It doesn't make you weak. You need to be able to put the project before opinion. Being the lead, ultimately the responsibility of the failure or success of the project rests on him.
add a comment |Â
up vote
1
down vote
up vote
1
down vote
Your question doesn't state whether you present alternatives and get shot down. If you're asking based solely on the fact that you're simply presented with an option you don't like, I'd suggest you either suck it in and do what's best for the team or constructively lay out options in a non-threatening manner.
If however you're being forced to implement design choices you don't agree with(for good, cogent reasons!) and your suggestions are being shot down, I'll suggest you provide documented communication (emails, design docs etc) that clearly state your own design . Such docs shouldn't be a comparison but neutrally presented. Make this design available to your lead preferably before he comes up with his, so he's more likely to give yours a fair look while doing his thing. It also has the benefit of making sure your views are on record in case the project goes to pieces due to poor design.
A question you should ask is : Does the alternate application design have a desirable outcome? Because at the end of the day, that is what matters: the project. If you're making a stand on a design choice , you need to be sure why you think yours is better or what the other guy's suggestion is doing to hurt the project.
It takes strength and maturity to take the high road in a clash of wills. It doesn't make you weak. You need to be able to put the project before opinion. Being the lead, ultimately the responsibility of the failure or success of the project rests on him.
Your question doesn't state whether you present alternatives and get shot down. If you're asking based solely on the fact that you're simply presented with an option you don't like, I'd suggest you either suck it in and do what's best for the team or constructively lay out options in a non-threatening manner.
If however you're being forced to implement design choices you don't agree with(for good, cogent reasons!) and your suggestions are being shot down, I'll suggest you provide documented communication (emails, design docs etc) that clearly state your own design . Such docs shouldn't be a comparison but neutrally presented. Make this design available to your lead preferably before he comes up with his, so he's more likely to give yours a fair look while doing his thing. It also has the benefit of making sure your views are on record in case the project goes to pieces due to poor design.
A question you should ask is : Does the alternate application design have a desirable outcome? Because at the end of the day, that is what matters: the project. If you're making a stand on a design choice , you need to be sure why you think yours is better or what the other guy's suggestion is doing to hurt the project.
It takes strength and maturity to take the high road in a clash of wills. It doesn't make you weak. You need to be able to put the project before opinion. Being the lead, ultimately the responsibility of the failure or success of the project rests on him.
answered Feb 25 '13 at 2:11
kolossus
4,2211440
4,2211440
add a comment |Â
add a comment |Â
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fworkplace.stackexchange.com%2fquestions%2f9858%2fworking-with-an-incompatible-project-leader%23new-answer', 'question_page');
);
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sorry @elssar, I wasn't aware of that SE. can it be moved now?
– mehta
Feb 22 '13 at 11:57
Yes, flag your question for moderator attention and they can migrate it.
– Joe Baker
Feb 22 '13 at 13:23
There is a project leader and one sr dev on the project? What kind of team is that?
– user8365
Feb 25 '13 at 1:43
3
The one responsible for the project gets to make the final decisions. Even senior developers need to respect this - it is part of being a professional.
– Thorbjørn Ravn Andersen
Feb 25 '13 at 7:24