This is an issue I come into at work sometimes which is awkward. I have a habit of having strong opinions that I feel are from years of expertise in the field or in the product. I also know that I have a very myopic view of all parts involved -- so sometimes compromises need to be made in order to satisfy all parties -- compromises that from my view are unacceptable. To pull a hypothetical example, maybe some team members are saying "We should do X because it's the only way to complete the feature within the release window", where I say "We cannot do that because it will lead to bad user experiences A, B and C, we'll lose significant customer confidence, more so than if we had pushed back the release by two weeks" (the issue could be around any points, the above are just an example).

Sometimes I will be able to convince other team members to see my viewpoint and sometimes I will not. I understand this is the nature of working on a team -- different viewpoints happen and unless I get to a point where I can say "I'm the boss do it" I will not win every debate (and probably don't want to do that anyway).

Where I struggle is other team members expect me to say "this is a good plan and we don't have to worry about points A, B and C I brought up earlier" which I simply can't do. In the example above I have a reasonable grasp of customer expectations and have a strong belief that the alternative shorter-turnaround-time path will lead to customer calls and confusion. The very best I can say in most instances is "We'll see what happens" (with an implied "I'm expecting this to go awry for reasons previously stated"), but that almost always comes off as feeling like I was petty and petulant. If I could navigate that better it might help out my work relationships.

  • 1
    Comments have been moved to chat; please do not continue the discussion here. Before posting a comment below this one, please review the purposes of comments. Comments that do not request clarification or suggest improvements usually belong as an answer, on The Workplace Meta, or in The Workplace Chat. Comments continuing discussion may be removed.
    – Kilisi
    Commented Nov 29, 2023 at 22:11
  • How are decisions made in your team? Is it the team leads or engineering manager choice? Is it the PM calling the shots? Is it by unanimous consensus? Or is less defined as "team decision"?
    – Helena
    Commented Nov 30, 2023 at 8:54
  • Is it just me or is the sentence provided in the question confusing. It sounds like you are saying they won't be convinced it's a good idea either. But what you mean to say is the opposite - that they do in fact think it's a good idea. Maybe make it more explicit? e.g. "I am not going to be convinced this is a good idea, but I can also see you won't be convinced it's a bad idea. Go ahead without my blessing." Commented Nov 30, 2023 at 18:48
  • @CaveJohnson: I think the issue is that the title is almost at the character limit. But my TL;DR of the quote in the title is "We'll have to agree to disagree." Or alternatively: "I don't think this is a good idea; you do. Neither of us will convince the other, so go ahead without my support." (That's not my attempt to answer the question of how to say this politely – just my summation of the idea being expressed.)
    – V2Blast
    Commented Dec 5, 2023 at 18:40

13 Answers 13


The concept that you are looking for is called "disagree and commit".

Somehow, through whatever processes are in place, the team or organization makes a decision. At this point, individuals may disagree with the outcome, but are expected to commit to that decision and take the appropriate actions to implement it.

I also find that actions speak louder than words. So once the decision has been made, proceeding quickly and efficiently to implement the decision, regardless of how you feel about it, would be more effective. Finding an appropriate way to communicate that you will be doing your part and when your part will be done or what the next milestone is varies based on your circumstances.

  • 56
    I would use a phrase such as: "I still have concerns, however I understand the need to move forward" - After that it is really about the commitment part, that you should act as if you had agreed to the decision (technically you did - you agreed to move forward), supporting other teams members to the best of your ability. If there is a retrospective after the project is complete/fails you may then bring up your concerns again as part of "what to do differently next time".
    – DavidT
    Commented Nov 28, 2023 at 1:56
  • 3
    Another formulation that fits with this is "I disagree, for the reasons outlined, but it's not a red line." This shows you are willing to muck in, but also implies that there is some nonsense that you wouldn't put up with.
    – Adam Burke
    Commented Nov 28, 2023 at 2:12
  • 5
    @AdamBurke That doesn't work though. There isn't an option to stay at work and not do your job, so if there's a "red line" then you have to quit. You've now created the perception in your team that there are things you'll rage-quit your job over on the spot. This isn't a good thing.
    – Graham
    Commented Nov 28, 2023 at 4:10
  • 13
    @Graham Red line does not necessarily means quitting. It may mean escalating. Been there.
    – user58697
    Commented Nov 28, 2023 at 5:43
  • 11
    "I see issues A, B & C here, but I see I'm in the minority on this. I agree to move forward, as the work needs to be completed, but for the record, I've noted my concerns."
    – FreeMan
    Commented Nov 28, 2023 at 13:42

There's no magic polite statement for this that will solve all your problems.. I do definitely agree that what you're saying comes off the wrong way. The most important thing will be your attitude - make sure that it's clear to your coworkers that you aren't stubborn on the exact plan or implementation, you only care about a specific A, B, C where there can be issues. That said, it's also worth making sure that they are even on board about that - it may be that they don't agree with you that A, B, and C are even concerns to begin with.

Otherwise, just stick to "trust, but verify". If your coworkers have agreed upon a plan, trust that they know what they're doing and help however possible under that assumption. Once it's done, verify that it did fix the problems you were concerned about. If it didn't, don't go back with an "I told you so", instead bring them up, confirm that they are a concern for the team/product, and then discuss fixes.

Though, if you're 100% certain that serious bugs or bad user experiences are making it into the product and you're being regularly ignored or disregarded, it may be time to find a workplace where you feel you can be heard.


The best way to say two things, is to say them one at a time. But in this case, you only need to say one of them.

The people you are talking to are under no illusion that you've suddenly come around to their opinion. They know you're not happy, and any way you say "...but I still think it's a bad idea" will come off as getting in one last jab. Instead, just tell them the part that they need to know, i.e. you don't intend to hold up the consensus any further. Some options:

  • "I won't stand in your way."
  • "I'll defer to the group."

Note the "I" statements, the descriptive and non-judgmental tone, and the utter lack of a "but". Concentrate on practical, factual matters: You're about to shut up while they do what they want to do. The rest would be redundant and nonconstructive.

Oh, and it should go without saying, but when you say these things: mean them, generously. Convey that you want them to prove you wrong, that you think it’s possible you are, that your willingness to stand aside was at least partially motivated by your esteem for them as developers and your humility in the face of their pushback. Otherwise it’s a lose-lose situation.


Is this your decision to make?

If you truly believe that all the arguments have been considered and there is no point for further discussion, then the key aspect becomes the organizational question of who is (or should be) in charge of that decision.

If that person is you, then obviously the outcome should not ever be something like "Go ahead without my blessing" - if you think that the compromises are unacceptable, then say just that and refuse the permission to go ahead, and if the compromises are painful but acceptable, then do explicitly "give your blessing".

On the other hand, if the final decision is not yours to make but up to someone else (who may still want your input), then that should be the key emphasis of the answer, explicitly deferring any choice to that someone else.

Reasonable ways to say that might be "After considering your arguments I still advise against doing so for reasons X and Y, but of course the decision is yours to make." or "If you decide to do this, it would be helpful to mitigate the risks of X and Y."

The key issue is that whoever gets to decide should accept responsibility. If that is someone else, let them make the decision (and don't imply that they need your blessing or consent unless they truly do, that only dilutes the responsibility for the decision with which you disagree), and if you do have the decision-making power (or veto authority) then don't shy away from clearly using it.


Experiments Vs. Debates

I think the key is to phrase the conversation from a team approach rather than a you vs. them perspective. The reason the current phrasing you're using is coming across as a tad hostile is because the framing of the conversation is pitting two ideas (yours vs. theirs) against one another.

Try using some of the phrasings below:

"Let's test things your way this time and see what we find."

"Go ahead with your plan and then we can reassess once we see the results."

Even though you've most likely run this experiment before due to your level of experience, gaining insight from the attempt from a team perspective will keep you in people's good books.

Something to also consider, if you've already gone through this exact experiment, displaying the results and matching them up with what you stated would occur is then the goal. Change won't occur unless you show that change is in fact needed after doing things the wrong way.


This is like raising children. As a parent, you want to see the best outcomes, but there's no way you can control what they do 100% of the time. They lack your vision and experience, and there's no easy way that you can transfuse that from yourself to them.

It's possible to burn yourself out and make yourself the bad guy for repeatedly telling them to clean their room, don't jump up and down on the mattress, and countless other things. And this is the point where you have to do some allowing to keep your sanity.

You have to allow the kid to have a messy room until they can't find something they need and it causes a huge inconvenience for them. They have to feel the consequences.

Likewise, you sometimes have to allow (within reason) that kid to keep on jumping up and down on the bed, and gravity can teach a lesson that you can't ever teach as well. Luckily, nature designed children to take a few bumps and bruises!

You have to treat your team members in the same fashion. Practice more allowing.

Take the least obvious deep breath that you can muster, and say:

I'll leave this in your hands.


I release it!

Cover your own behind, of course. Go home and laugh about it with someone you trust. It's a training exercise where the consequences are the only way they'll learn. It won't always happen at your speed, and it might take a few iterations!!!

If everyone showed up knowing everything, there wouldn't all these distinctions between leaders and followers. Sometimes as a leader (or a parent), you have to nudge and encourage from behind, and that's as much as you can do.

Good luck!

  • 1
    I currently have a similar situation where some younger devs make the same errors i did 10 years ago. I explained my reasons. they didn't think they were valid. So i let them do it their way. I hope that they are still around to fix any issues which might occur. My personal take away is that i won't ever be able to do The Perfect Project using my full hard earned experience. Because there will always be someone new or with different experience who might repeat the errors of the past. So everybody will learn from this but nobody will ever be able to use the learned lessons.like in a endles loop
    – some_coder
    Commented Nov 28, 2023 at 9:40
  • 1
    Colleagues are not children. They're grown adults. Children sometimes have to learn from their own mistakes, whilst adults typically have the capacity to learn from the mistakes of others without having to make the same mistakes themselves. It sounds like OP is struggling to form consensus due to disagreement on priorities, and that is a legitimate discussion for adults to have and one where they may have to agree to disagree. If the real problem was "my colleagues don't have the emotional maturity to accept the validity of my experience on this topic", that's a very different question.
    – James_pic
    Commented Nov 29, 2023 at 10:33
  • 1
    @James_pic "Capacity" to learn from others' mistakes? Absolutely. Wisdom to actually recognize the value in doing so? Not necessarily. There are plenty of motivators to ignore sound advice!
    – Xavier J
    Commented Nov 29, 2023 at 21:34

"agree to disagree"

If you've already had the conversation where you make your points, listened to their points, come to an impasse, and decided that it's time to end the conversation, that's a reasonably polite way to do it.

  • 2
    This has the serious practical advantage that it's essentially a collectively understood trope for claiming "no-fault disagreement". That is, there is no space to take this phrase as an offense, no space for the listener to insert a misinterpretation or a value judgement. The phrase is the sign that says, "Through no fault and without a covert claim of victory or defeat, I'm declaring, for the good of the whole, we're deadlocked and can move on." It's like the nature videos where the rams clash horns for five minutes and then walk off like nothing happened. 😉
    – ruffin
    Commented Nov 30, 2023 at 14:02

"On your head be it"
"Approved, against advice"
"Sink or swim, this is your pool party"
"You do you"

Whilst there are many idioms in the English language for this exact type of situation, all of them sound like you are being an AH.

My personal favourite example was a story from ages ago in the NZRAF - whereby a Crew Chief for an Aircraft would sign it as ready or refuse to sign it if they had concerns. The document also had an area where if a commanding Officer pulled rank and over-ruled the Crew Chief, they could sign - which meant that if anything went wrong, it was the Officer on the hook, not the Chief.

All you can really do, from a professional standpoint, in these situations is make sure everything is documented - that if the team is going along with a solution you've advised them against - make sure that it's in writing, the why is in writing and the reason they've gone against the advice.

  • 10
    "On your head be it" is very much not polite Commented Nov 28, 2023 at 8:09
  • 23
    To add to Richard's comment, I personally think all 4 examples here are impolite.
    – justhalf
    Commented Nov 28, 2023 at 9:00
  • 6
    These examples are not only impolite, but almost rude and certainly unprofessional. They are at least confrontational in nature and will not improve work climate.
    – Polygnome
    Commented Nov 28, 2023 at 10:10
  • 9
    @justhalf I think that was TheDemonLord's point.
    – Sneftel
    Commented Nov 28, 2023 at 14:24
  • 5
    @Sneftel - I'm glad that someone read the full answer and understood what I was saying... Commented Nov 28, 2023 at 18:32

As an upper-level programmer, I deal with this daily: In a well-organized business situation, there should be a designated decision-maker. That is the person who will ultimately bear responsibility for the final decision. I will assume that person is not you. In that case, your job is to make sure the decision-maker has all the information they need to make a good and informed decision. That includes warnings that deadlines will be pushed back, budgets will be overrun, and customers will be angry. Put those (as neutrally as possible) in writing, and then let go of the final decision. There may be other reasons (politics?) that the decision-maker needs to go a different direction, but you have done your job by keeping them informed.

In terms of how to phrase or express it, it helps greatly to reframe it as informational rather than didactic. In other words, instead of "We should do A because B is stupid, and if you insist on B, I despair of you," say "If we do A, these are the pros and cons. If we do B, these are the pros and cons." Just stay neutral and informative, and leave the value judgements to the person hired to make them. (After ignoring you a couple of times and getting burnt, any smart and competent decision maker will start taking your recommendations more seriously, especially if there's a written record of your predictions.)

If you ARE the decision maker, gather as much information as possible, including opposing points of view, and then make the decision you feel is best AND own it.


In British English, the phrase you are looking for is "That is a very brave decision, but of course you have my support." You can find some other useful expressions here: Anglo-EU Translation Guide

  • 3
    For those not in Britain, this meaning of "brave" is likely to go right over their heads. The phrase I would insert is something like "Are you sure you want to burn your bridges" or explicitly, "commit us to a change that will be effectively irreversible". If this isn't the case, just let them go ahead and learn from the mistake, if mistake it proves to be.
    – nigel222
    Commented Nov 29, 2023 at 12:11
  • 2
    As I said, "In British English". The OP gives no clue as to his place of work. Burning bridges means something different and your second alternative is wordy and likely to raise hackles.
    – AlDante
    Commented Nov 29, 2023 at 20:06

I know very well where you are coming from. The issue can be even exacerbated when you are, indeed, an expert with lots of experience in the matter, and if you feel that if you do "it" (whatever it is) yourself, you will indeed be much faster than "the team". This can easily lead to very beautifully engineered solution, but sometimes much over-designed, and costing much more than required. Not talk of the time spent achieving them. Been there, done that.

What helped me a lot was to embrace the idea of the Minimum Viable Product (MVP). It may be far-fetched for some of the issues, but it does fit more often than not. The idea is that whatever it is you do, you restrict the outcome you try to reach to the bares minimum amount of features or capabilities that makes the result at least very slightly more useful than not having it at all.

A very important point about this is that a MVP is not a prototype or a proof-of-concept. I.e., it is not something that gets thrown away later and completely replaced by the real implementation. A good MVP is relatively quick and easy to create, but then can be refactored or extended in a way that includes what is already in there; i.e., you do not double the effort by having to scratch it and completely replace it.

The reasoning behind that is the experience that this kind of scratching of a solution that is already in place seldomly happens in the real world. Normally these kinds of things become technical debt or just arcane systems that linger around much longer than anticipated. By making MVPs that will, by design, later be improved on, it is easier to avoid that.

Once you accept that an MVP is nothing bad, but in itself a thing of beauty, because it leaves everything off that is optional in any form or fashion, it becomes much easier, psychologically, to accept the quick(er) solution that is maybe preferred by your colleagues. Then you can focus on avoiding glaring errors in the initial implementation (i.e., making sure that it is not, in fact, just a prototype or proof-of-concept). MVPs are usually often more readily accepted by stakeholders outside of the team, as they provide at least a modicum of value and are not on the short-list to be thrown away soon.

To give you two concrete ways of how to say this politely, depending on circumstances:

  • "I see what you are intending to do - while the best final solution would be XYZ in my opinion, it makes sense to proceed with your approach as a Minimum Viable Product, for now, and expand on it later."
  • "I see that we do not have enough capacity right now to create the best possible solution; the solution you are suggesting seems to be hard to extend later because of ABC. Let's instead reduce our requirements for now as a kind of Minimum Viable Product, and at least make sure that the effort we invest now can be re-used later without any hindrances."

I'm going to push back on the premise of the question a little bit here: have you considered the possibility that you're wrong? If not, that's probably part of the problem here. Regardless of how much knowledge or experience you have, it's always possible that you're wrong. Everyone has blind spots, and by your own admission you can sometimes have a myopic view of what's going on. That being said, it's very important to consider other people's perspectives - you may well be missing very important details that would change your perspective on what's needed.

Also, is it really not possible to come up with any acceptable compromise in these cases? Don't take this the wrong way, but this seems like a bit of a "my way or the highway" attitude. There are always trade-offs in any process, and it's rarely possible to get everything we want in the product development (at least right away). Keep in mind that shipping is a feature too.

You may be seeing conflict as a win/lose process. I'd encourage you to read Getting to Yes by William Ury and Roger Fischer to get a clearer understanding of how to resolve conflict in a way that's satisfying to everyone involved.

Keep in mind too that you're not the only person who has knowledge of the product or field, and that you're not the only person who cares about releasing a quality product. If you think that (or even give the impression that you do), it'll likely generate a lot of resentment in other team members.

  • 1
    The OP mentions in comments that the other team often fails to respond to their specific points, even after repeated prompting. To me, that suggests that even if the other team is correct in this scenario, it's by happenstance rather than a strong grasp and principled rejection of the OP's concerns.
    – Milo P
    Commented Nov 29, 2023 at 19:46
  • While this may be good advice on the attitude the question author should have, it doesn't really address their concerns of how to phrase/express that they still have concerns but agree to move forward. (If you think they shouldn't express that idea in the first place, that's a valid answer as well, but you may want to state that explicitly.)
    – V2Blast
    Commented Dec 5, 2023 at 18:52

"Not what I would do, but if you can make it fit the requirements, go for it." Some things can only be determined by trying them, and who knows-- they may have a solution you didn't see. If it doesn't work, all that's lost is some time and some(one else's) effort.

Sometimes stepping away from the specifics and making sure everyone understands the real requirements helps one or all of the folks involved. Things that are assumed to matter may not, and vice versa; sometimes you discover that simply rephrasing the question opens up unexpected solutions; sometimes the answer is that what doesn't matter really doesn't matter

(I've been finding myself in a lead position again...)

You must log in to answer this question.

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