I'm the Tech Lead, my boss is the PM. In case of disagreement, how much should I push my point of view?

Question

I'm the tech lead of a project and my boss is the Project Manager. He is formally in charge to decide what to put inside the project and I'm in charge of deciding how things will be implemented.

In the last few months we realized we need to rethink how the application manages some edge cases and relevant changes to get this result. In this development our roles and responsibilities got pretty mixed up.

In theory, I think we should collaborate to get the best possible results by converging our (potentially different) points of view. In practice, he adopted a hard stance and wants to see some changes made without taking any input from me.

I fear that his ideas will be detrimental to the application, in that by fixing the edge cases a new series of bugs will be caused and the quality of the code base will suffer. Due to that, I've tried to change his mind a few times but his stance became progressively more aggressive to the point of being almost verbally abusing.

While I understand that he is the boss and he should have the final word, at the same time I feel responsible for the overall quality of the application and I don't want to be blamed (something I'm sure will happen in a few weeks/months if the changes are implemented and problems arise^*) for a product in which I had no say at the end.

^* _{This has already happened before, when I advised my manager that some of his decision could results in issues later on and similarly my objections were dismissed. Surely, after a while we found the issues I predicted plus more unexpected ones due to these, and I was blamed for letting it happen.}

Answer 1

We all encounter this kind of conflict.

The only thing you can do is DOCUMENT EVERYTHING

There's nothing wrong with the boss being the boss until he tries to push his mistakes off on others. The most effective way to push back is to do the following.

• Document the flaws you see in his approach
• Document the consequences you foresee in taking his approach
• Present an alternative approach
• Demonstrate how your approach will mitigate the concerns you raised
• Analyze the benefits and drawbacks of each approach
• Strongly assert that due to your analysis, that your approach be taken.
• Save all of this documentation
• Follow orders.

Then, when it blows up and you're asked why you let it happen, you can reply that you did not. You documented your recommended approach, that you were overridden and successfully predicted the consequences of not following your approach.

This is a case of where you need to let the ball drop in order to prove your point, but make a paper trail so that the blame can not be placed back on you.

Answer 2

Setting aside the roles the two of you have as Tech Lead and Project Manager respectively there is the trump card that he is your boss.

So really you need to bear that dynamic in mind - I'm not saying don't ever put your case forward when the two of you disagree but once you feel that you have made your case then if your boss still insists on their preferred choice then you just have to go along with it. You need to be as unemotional about the matter being discussed as much as possible - from your post it sounds like your boss has form for getting aggressive in these discussions and as tempting/natural as it may feel you can't rise to that because that will only escalate his emotional response and dig him in further. If their goal is basically good but their proposed method is where you have the problem the make sure to repeatedly stress that you agree with what they are trying to achieve, seriously actually use the words "I agree with you" where you can because this can defuse the confrontational tone that these sorts of discussions can develop.

If you feel that going the their way would have serious negative consequences on the quality of the output I would make sure you document your concerns (and the associated consequences) over e-mail as a CYA move, this doesn't have to be a confrontational thing or anything like that - just put them down in an e-mail while the issue is still being "discussed" e.g:

Hi [boss/PM], I was thinking about feature X on the Widgetron 3000 we were discussing, I see where you were coming from and I agree it would be great if we can get that feature working but I'm just concerned that if use the Unobtanium as you suggest that it could result in the flux capacitor becoming unstable? And we risk causing bigger problems down the line. If we used the Handwavium instead wouldn't that let us still do feature X without the same risk?

They may well not listen to these and if their mind is made up then they almost certainly won't but they will probably respond back to you overruling them at the least and the important thing is that you've got these concerns and consequences and their subsequent dismissal of them in writing and should there be any attempt to blame you in the future you can point at that e-mail chain and show that you raised them and were overruled.

Answer 3

If there's confusion in the discussions you're having, this might well lead to the confusion and the tangled code that you're implying is already in there. It sounds as though you're piling spaghetti on top of spaghetti and complaining that the dish is overflowing.

Depending on project timelines, this might be a good opportunity to take a step back and for both of you to reassess the large picture.

Get back to the core requirements and see if the problems can be solved by wrapping up all of those little ad-hoc requests and bugs and look at getting them reanalysed and re-written, and get it done right.

If timescales don't allow for a fundamental reassessment, then compromise with the latest requests and put them in the best you can in the time. Then let the bugs come out in the testing.

After that, take your step back and see whether larger changes are more appropriate than iterative bolt-on fixes.

Answer 4

It sounds like you're trying to flat out tell him no on some things. What works a lot better is to tell him what it will take in order to do what he wants safely, with the proper level of quality.

That code is really difficult to change without breaking. In order to handle those edge cases, we're going to need to spend a few weeks adding some tests around that area and doing some refactoring and cleanup first. Otherwise the time to fix the bugs afterward is going to be completely unpredictable. Then we should be able to implement the edge cases in a week or so, with a lot more confidence.

Don't lie or pad your estimate. Be as accurate as you can. Be a sincere and supportive team player. You're not saying no. You're saying, "Yes, definitely, I'm on board. This is how we do it." He then knows the true cost including technical debt, and he can decide whether it's still worth it, and how it truly fits in compared to other priorities.

This technique can be really effective. I first learned it in the context of parenting, and it works in all sorts of seemingly stalemate situations. In summary, ask yourself what it would take for you to say yes. The answer is almost never nothing, and you'd be surprised what the other side is willing to concede too.

Answer 5

As I see it from your description your PM is in charge of requirements, and you are in charge of implementation. Requirements should always be documented, even in a fast paced process such as agile/scrum. If your PM is asking for less documentation, not more, that is a serious red flag. The PM should be getting requirements from the customer, slinging requirements at you, and demanding documented fulfillment of those requirements (Unit tests, system tests, demos, etc.) Talk this over with your functional manager, their job is to facilitate you doing your job. If your PM is your Functional, this is now an HR problem, and you should talk to your HR representative. Don't represent it as a complaint, but as an issue you'd like to resolve so everyone can get back to work.

That said, from your post, and comments, it looks like you have multiple red flags present, and you should review the following policies of your company, and let them guide you: Ethics/Code of Conduct, Threat-free workplace, Violence-free workplace, and Harassment-free workplace.

Answer 6

The PM is in charge of what, you are in charge of how. The key is to make it clear that your changes are part of how not what.

For example PM wants feature X. You want to make changes A, B and C. You simply say:

In order to deliver X we need A, B and C to be in place. We cannot deliver X without first delivering A, B and C.

Make it clear that A, B and C are required by X. If PM wants X then PM gets A, B and C too. Don't go into too many details. PM is not technical and is not expected to understand why X depends on A, B and C.

If X really doesn't depend on A, B and C then don't use this approach.

Remember no-one wants broken software, not even the PM.

Answer 7

"I fear that his ideas will be detrimental to the application, in that by fixing the edge cases a new series of bugs will be caused and the quality of the code base will suffer. Due to that, I've tried to change his mind a few times but his stance became progressively more aggressive to the point of being almost verbally abusing."

You haven't made it clear that the PM is stepping into technical areas. Deciding that the program needs to handle edge cases correctly absolutely is in the purview of the PM. Making sure that a new series of bugs does not result from this is literally your job.

Answer 8

I think you are right in wanting to stay in your area of expertise. There will be times when there is some overlap like in this case. You can still make sure your concerns from the technical side are still addressed. Although you may not make the final decision, it is important that you still identify and emphasis if necessary, the risks the PM is taking by accepting or ignoring certain trade-offs. In this case, you can have these features, but there is a risk of making future changes more difficult, they'll take longer, and could have more bugs.

In the end, you're making suggestions and the PM is making decisions. Hopefully, your level of responsibility is proportionate to your level of authority.

Answer 9

I am a senior developer and I am essentially filling both the roles of a technical project manager and team lead. My perspective to your question is more from the PM side:

In my situation, it was a junior developer who was constantly questioning and challenging the decisions I was making regarding the project.

There were times where we would have heated discussions about features and scope, and ultimately I reached a point where I couldn't handle it anymore. Instead of encouraging him to contribute his ideas, and I began to shut him down before he even started. It became more exhausting and time consuming trying to deal with his desire for me to see things his way that I started questioning whether he was a good fit for the team.

The resolution still hasn't happened, but my junior dev has improved his attitude considerably in the last few weeks.

What I had done was to clearly define his roles and responsibilities, and started treating him less like a buddy and more like the PM to Dev. When he starts to challenge me on something now, I only allow him to go so far and then I say something like, "Its not your responsibility to decide that."

While your situation is quite different, my answer for you is this:

You cannot address any of the technical issues while there are unresolved personal problems.

Sit down and talk with him. Apologize for things that you have said or done that could have been handled better. I know this is hard, but by you breaking the ice it gives your coworker a path to apologize too. (He might not, but at minimum a few bricks in the virtual wall between you will be torn down). Emphasis that you want to work as a team, and you really want the project to succeed just as much as he does.

Once you get that out of the way, you can start to deal with the technical. Here are a few pointers:

1. Me AND You, not Me VS You: There should be no losers for the argument, there should only be 2 winners. If you start with the attitude and goal that you both should win, there really is no argument and the project/task will be a success.
2. Deal with one issue at a time: say "I would like to meet with you to discuss ____", and then stick to it... don't bring up other issues. If he asks you about other problem areas, just say something like: "I am not prepared to discuss that yet"
3. Go for a win: Don't go for the big elephant in the room. Work on the smaller issues and build a pattern that you can work together before you tackle any of the major issues.
4. Be prepared: "You asked me to implement the feature this way, and I just want to show you that I came up with costing estimates and it will probably take XXX hours to implement. Now I do have a few other ideas that could achieve the goal, but might be easier and less costly to implement."
5. Listen to him: If you are only focusing on what you are going to say next, or playing with your phone... it will be obvious to him that you are not listening. Imagine that both of you are standing on opposite banks of a river, and there is an object which you have never seen before floating in the air between you. You can never see his side because you cannot cross the river, so you have your perspective and he has his. But you can listen to him describe what he sees; and you can also study the object by walking up and down stream to get a different view from your side. There is nothing wrong with having a difference of opinion, but by listening you can start to appreciate his point of view.
6. Take Breaks: in your meetings, if something hasn't been resolved and things are getting heated... ask to take a break. Pressing on when one of you is upset will only make things worse.
7. Don't focus on the negative: If you focus on the million reasons why his idea will not work, he will feel undermined and worthless. If you start out by praising the things you like about his idea, he will be more receptive to compromise. Instead of saying things like "I will not work because...", change it into a question... "Yeah, I think that might be able to work, but what about ____?"
8. Accept that you may not have all of the information: There may be things that the PM knows that cannot explain to you. Reasons could range from confidentiality to a lack of understanding on his part (and that gets into shame). At some point, you do have to accept his decision.
9. Forgiveness: There is a saying: Unforgiveness is a poison that YOU swallow and hope the other person dies from it. My wife used to bring up stuff from 15 years ago; but a marriage seminar we went to said to let past hurts expire. If something happened that hurt you more than 30 days ago, try to let it go.

Answer 10

My suggestion is very simple:

1) Express your concern over the implementation of the edge cases and make sure that they are recorded in a clear and concise fashion.

2) Listen to the project manager's response. If you feel he has mis-understood a point clarify it.

3) Add the edge cases into the implementation if the project manager still wants them in the application.

4) Drop the discussion on the point unless new or pertinent information comes to light.

5) Continue work with the new edge cases with as much concern about the quality of the code as you had before the discussion.

I don't know about the application you are producing but I do know that developers in general like clean easy to manage code. I get from your question that dealing with the edge cases will add significant complexity to the code base that will make code maintenance more difficult and add to the risk of the project.

The other perspective is that the edge cases might be important to the final user of the application and though the handling of them would make the code base more difficult to follow and maintain the handling of the edge cases may be truly a requirement. Many people forget when the software works correctly but they can tell you the number of times it doesn't do what they want it to do.

In the end the Project Manager has the final responsibility from your perspective. If he makes a decision for the edge cases that's his responsibility. It is your responsibility to implement the edge cases and the application as best you can.

Answer 11

Must read, think your boss is one of them: https://en.wikipedia.org/wiki/Psychopathy_in_the_workplace

It means you should run as fast as you can or start a fight that will cost you a lot and even if you win and he leaves it will give you little benefit.

If you can't get higher-ups to see the situation and correct it, you should correct it for yourself by finding a new job.