Is there a polite way to say "I am not going to be convinced this is a good idea, but I can also see you won't either. Go ahead without my blessing"?

Question

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.

Answer 1

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.

Answer 2

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.

Answer 3

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.

Answer 4

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.

Answer 5

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.

Answer 6

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.

or

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!

Answer 7

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

Answer 8

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

Answer 9

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

Answer 10

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.

Answer 11

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

Answer 12

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.

Answer 13

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