Working with an incompatible project leader

Question

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.

Answer 1

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.

Answer 2

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.

Answer 3

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.

Answer 4

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.

Answer 5

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.

Answer 6

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.