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.

  • 5
    Possible duplicate of How to better provide technical pushback without appearing defiant?
    – gnat
    Commented Nov 8, 2017 at 21:29
  • Comments are not for extended discussion; this conversation has been moved to chat. Commented Nov 9, 2017 at 19:12
  • 11
    The true essence of engineering is: the appropriate trade-off of technical considerations due to business requirements. It is never the case the technical always trumps business, and never the case that business always trumps technical. Rather, on a case by case basis, trade-offs must be made of each against the other. It seems that both you and your boss need to learn this. Commented Nov 9, 2017 at 21:28
  • How big is the company? In a sizeable company, any important decisions usually involve an architect or a whole board of senior-ranking technical specialists.
    – Alexander
    Commented Nov 9, 2017 at 22:05
  • 1
    @Alexander The company is quite large (over 1000 persons) but software development is a minor part and my team is quite small (<5 persons) Commented Nov 11, 2017 at 18:07

11 Answers 11


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.

  • 31
    I have a special tag for this which I've been using for more than a decade to mark my notes, emails... it is #iToldYouSo. This pairs with the #wtf and the exact time (for credibility). It makes a great work journal because later I can review flawed opinions from my younger self too. Commented Nov 8, 2017 at 20:04
  • 2
    @SystematicFrank: Email, bah. I stuff that stuff into comments in the code. If it's longer than a line or two it disappears into a #region.
    – Joshua
    Commented Nov 9, 2017 at 2:16
  • I'd been adding to my "Big Book of I Told You So" for what feels like a lifetime and that evidence has only been useful... just about never. Especially not when someone who isnt open to criticism is on the other side. Its been more effective to train or teach someone (even meself) into better critical thinking and decision making.
    – StingyJack
    Commented Nov 11, 2017 at 12:47
  • This is indeed all you can/should do. Getting promoted to Product Manager will then be satisfying because you know it won't happen again ;) Also, the Product Manager may be right. Commented Nov 11, 2017 at 20:47

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.

  • 19
    @heapOverflow Wait...your boss is resistant to written requirements? I think you may have bigger fish to fry here. Commented Nov 8, 2017 at 16:42
  • 3
    @called2voyage Not explicitly maybe. But every time I mention putting something on paper the answer is that it's not a priority and this is not the right time. I cannot really say if it's done on purpose (you know like a lot of politician who don't want to be quoted later on..) or for real concerns about the potentially wasted time. Commented Nov 8, 2017 at 16:55
  • 8
    All of these reasons just reinforce my opinion that you must get it in writing, even if it's just sending your e-mail... It doesn't matter if it comes across as aggressive or not, after it happens a couple more times they will be the one in the crosshairs, not you. The only reason why somebody wouldn't want your concerns to be in writing is because they know they're doing the wrong thing and want you to be the scapegoat while they get away clean
    – Taegost
    Commented Nov 8, 2017 at 18:20
  • 4
    @Taegost that might be a bit cynical. He's not necessarily being malicious, he might just be naive. That being said, regardless of his motive, I agree the result is the same: you're likely to be on the hook for his mistake if you don't document. Commented Nov 8, 2017 at 18:33
  • 3
    @TemporalWolf - I do tend to take a bit more cynical view of things, but i've worked in the corporate world for 20+ years, and (almost) every single time I've seen the behavior that OP is describing, it always turns malicious even if that's not the persons intent. At some point, everybody has to look out for their own survival, and when things go south and there's no paper trail, the only "winner" is the person who can provide the most "evidence" it wasn't their fault... If there's a paper trail, you'll find out real quick what type of person the boss is.
    – Taegost
    Commented Nov 8, 2017 at 19:48

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.


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.


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.


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.


"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.


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.


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.

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.

  • "If you feel he has mis-understood a point clarify it." This is probably the most tricky part. I feel I was misunderstood quite often and try to better express my opinion. He doesn't want to get things told more than one and gets angry. Commented Nov 16, 2017 at 14:23

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.

  • 4
    This should not be an answer; it does not address the question in any meaningful or useful way.
    – TylerH
    Commented Nov 8, 2017 at 21:09
  • edited, better? think it's a no win situation Commented Nov 8, 2017 at 21:22
  • come on - this is just plain silly Commented Nov 9, 2017 at 19:43

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .