last day (16 days later) » 

22:11
52
Q: 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"?

SidneyThis 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 t...

"We cannot do that because it will lead to bad user experiences A, B and C" What was their reply when you tell them this?
@sf02 For the sake of this question assume they double down and don't really respond to the points raised. In the real world sometimes they agree and see things my way, sometimes they point out why A, B and C will not happen. Sometimes in the real world they fail to address point A B and C even when prompted multiple times.
In past situations like these, where you expose your concerns about doing X, what percentage of these instances "you were right" and bad outcomes A, B, and/or C happen? If a significant portion of those turn out true, then this would suggest stubbornness from your colleagues. If a significant portion were only false worries and didn't end up happening then this would perhaps suggest that your may want to "tune down" a bit your trouble radar.
@DarkCygnus Fortunately in the past I've had scenarios come to light from QA or other integrating teams before we go to prod, but the company could still benefit from shifting those concerns left to the planning/architecture/development stages.
...and do those instances where QA or someone else caught it get fed back to the original decision makers? Do you raise those next time?
22:11
@SolarMike from the q it sounds like we're (as so often on Workplace...) in the world of business software development. If by contrast we're in a safety-critical world I'd say the answers would be very different...
@AakashM in a safety critical world the correct answer would be "I will not sign this." For engineers it doesn't need to be polite, the facts will do. But you do have to be right and have the facts to back you up.
Are you the manager of these people? Why does your blessing matter? If you are their manager and tell them to proceed without your blessing, that is a bad thing (it is your blessing anyway)
@AakashM Even in the software domain it may be a full-stop scenario. Ex: C Level says "I want full backend access to the system that is 100% pii and credit card data"; that's something in the software domain that is also in the safety domain.
@cdkMoose I am not the manager of these people, but the product is collaboratively owned software products. I am responsible in part for the customer satisfaction -- most often the people who I have disagreements with are on equal footing as me under the same management chain.
@Sidney I know you said "the issue could be around any points, the above are just an example", but the actual example you gave (of the negative consequence being 'a bad UX') means you are getting answers tailored to that. If it's actually a safety, legal, or compliance thing you're disagreeing with the rest of the team about, then your question should say so!
For what it's worth, the way you've phrased it in your title is already much better than the ways you've phrased it in the body of the post.
22:11
Could you explain the discussion context in which the team members are expecting you to retract your concerns? Is part of your role to be directly involved in the work after that, or are they just unhappy that they consulted you on their plans and didn't get the answer they wanted?
What question are they actually asking you when they "expect [you] to say 'this is a good plan'"? The appropriate response depends on whether they're saying "are you sure this isn't a good idea," or "we need your approval in order to continue," or repeatedly asking the same question in the hopes of getting a different answer, or something else.
If I understand correctly what you expect is for your team members to address your concerns raised by their suggestion (as per your example, about user experiences A, B and C) either by offering a solution or by them accepting that they're serious enough to "take back" their suggestion; in these cases, how do YOU address THEIR concerns that made them make their suggestion in the first place (again, in your example, that would be what you propose to release the feature with A, B and C solved AND within the expected time window)?
So what do you do when you have same problems in your everyday life? Something you usually can't accept, but is pressed to by some other circumstances.
My go to phrase for this is "this isn't a hill I'm going to die on". Signals that I disagree, but softened a bit by folksiness. Of course that assumes it's a hill you can afford to not die on. If it'll blow up on you when or if it goes bad, that's a different question.

  last day (16 days later) »