How to better provide technical pushback without appearing defiant?

Question

My project manager directed me to do something that I know (and later found out he already knew) was not supported by our underlying architecture. His thinking was an edge case would fail for people running with the current underlying architecture but by the time the product was released the framework would support this feature.

Since I knew it wasn't (currently) supported I pushed back and gave him my reason (not supported). I think (perhaps stupidly) I used the word "No" when I probably meant something like "No, it's not that simple".

The project manager read this as insubordination and without explaining his thinking took the issue up with the VP (who incidentally ended up graciously directing me to proceed as my project manager directed).

My general question is: how can I provide technical reservations without antagonizing people or coming across too hostile?

Answer 1

Don't lead with "No." That's the PM's decision to make and if you appear to be making it, as you've seen it's pretty simple to arrange for you to be directed to follow instructions. What you want is for the PM to decide "No" after hearing your technical input.

With that in mind, you need to develop some conversational quirks that are not saying "no" but are leading the PM to understand all the issues before deciding yes or no. In this case, there is nothing wrong with "but" (which carries an implied no) if you feel like using it.

But isn't that unsupported?

But won't that fail for users in [edge case]?

I can do that, but it would be a lot less work if we waited until the new framework was released

I'm concerned about doing that with our current technology. I'm not sure it will work for all our users.

I am not suggesting you be all tricky and manipulative, saying yes when you mean no, or even pretending that you think it's great but there's just this one little detail... Go ahead and say you have problems with the idea, but don't be the one to make the decision even if it's just an accident of wording that makes you appear to do that. Leave the decision to the decider. As you've seen, when you lead with the decision you sometimes never get to say the reasons.

When you lead with the reasons, you might get responses like

that's on my head, you just implement what I've asked for and I'll worry about the [edge case] users.

by the time you're done, the infrastructure will be updated and there will be no issue.

These people know it's an early adopter program and if it doesn't work for them they can always use the old stuff

Or you might get

Oh. I didn't think of that. Thanks. Do you have 30 minutes to kick around some alternatives that can still give us what we need?

Any of those are a lot better than a VP calling you insubordinate and telling you to "do as you're told" like a child. Right?

Answer 2

1. Know what you are doing. People are taken more seriously when they are knowledgeable and have a reputation for getting things done.

2. Ask questions. If you genuinely don't understand why something is being asked of you, say so. Good managers understand that they get better work from their people when they know why they are doing it, and value the feedback of their subordinates when it is relevant to the issue at hand.

3. Listen. Make sure that you understand what is being asked for, and what the considerations are.

4. Offer Respect. He's the manager, so ultimately what he says goes, but if your relationship with him is respectful, your opinion will carry more weight.

5. Allow for the fact that Everyone has bad days.

Answer 3

Start as One Team

First and foremost - assume that everyone has the same end goal - make a great product that meets the needs of the users/customers, and do it as efficiently as possible. The challenge is that different points of view will interpret the current state and the next steps towards that goal differently. One person's "must have" may be another person's "impossible" when the knowledge of each is wildly different. A good team will bring different points of view and different subject matter expertise together, the challenge will be getting the views aligned to the point where good decisions can be made.

Don't Give a Blanket Negation in the Other Guy's Domain

He is saying "we need this". As a PM, that's his job - know what the customer may need. Saying "no we don't need this" without basically doing MORE research that he has done will be a loosing battle. And if (as an engineer) you've done more research than he has, then you've probably misallocated your own time.

Argue from Your Domain

The safe zone for engineering is usually "the solution you propose is unacceptably difficult", and "the actions you propose will not produce the outcomes you want". The PM owns the problem domain (what is the problem your product solves?), engineering owns the solution domain (how are we solving it?). Because you own the solution domain, it's easier to argue from the point of view of: - time required to make the solution described - reaction of potential changes to solution across the system

The trick is, you can't say "this problem isn't worth solving". The safer way is "this problem will take an unacceptably long time to solve - namely X years". With that on the table, however, if you say "15 man years" and the PM goes to the VP, the VP is well within his authority to say "yes, I'll make the investment - please spend 15 man years of my money making this solution as quickly as you can..."

The even better strategy is to have a plan in mind that accomplishes the goal but in a more efficient way. For example, if you are concerned about an edge case, what if you lock out the GUI from allowing the case? Or you provide an alternate path? Often, I've been able to get a 90% solution that was acceptable and remarkably cheaper than the original proposition.

Know your Listener

Each person is different - different people will deal with a flat out negation differently. Different people will require varying levels of proof or detail before they will agree. Some people need to hear the idea, think a while, and get back to you later. Some people to have a picture or hear a hard idea in writing, rather than try to catch it while a speaker is speaking.

Know who you are talking to and build a model for how they typically respond in these situations. Structure the communication so that they are in the best possible state for being accepting, particularly when you have a really difficult idea to sell. This is partly the active work of building up trust, and partly the work of trial and error.

Know the whole audience

Be aware of power dynamics. Disagreeing in a meeting with a key stakeholder who outranks the PM is not a good place to hash out a problem. Preferably the smallest audience of affected individuals. Although with a particularly difficult case, you may want to follow up on your new found agreement with an email to a wider audience saying "I'm so glad we agree on X, just wanted to shoot a mail letting everyone know! Thanks for helping with this!"

That way it's nice and clear and documented. :)

Answer 4

Background

My general question is: how can I provide technical reservations without antagonizing people or coming across too hostile?

First step is recognizing people have different perceptions of you than you do. This is critical, for you answering "does this make sense" is a trivial question and worth a trivial answer. But people's perceptions of everything may be dramatically different

Second, for the person asking the question, they have no where near the background you do nor the technical understanding and in many cases may lack the technical experience to even relate.

---

What you need to do is the following in the future:

• Assume the person you are "declining" has no idea why you are declining something or pushing back. Always provide some "ask for clarification" when denying things and always provide at very minimum some reason.
• For more complicated requests if you have to say "no" include something like, "let me know if you'd like to discuss this in more detail, the explanation is relatively complicated"

People do not like "no" answers at all when they come from a black box. These will go over poorly in general and in the workplace.

Answer 5

One option would be to avoid saying "No" altogether, even if you are saying "No, because..."

Instead say "Yes, but..."

Whatever your manager asks for, say "Yes, this can be done, I can definitely do this... BUT it will require [more time, more resources, etc.] and will have the following consequences: [con list]." The benefit of this method is that it leaves the Do/Don't decision to your manager who can remain in control.

One possible advantage is that you may be able to start by saying "Yes, I can do this but I'll need to do a little research first", and then can come back later with a more detailed explanation of the consequences.

Answer 6

I'm surprised that almost all of the other answers, while generally providing good advice on "how to say no", seem to be ignoring the bigger picture of "what is the problem?".

Your PM has a problem to solve. Somebody - perhaps his manager, or another team, or a customer or group of customers - is relying on him for a solution, and he is in turn relying on you for a solution. Of course a "no" answer is going to put him on the defensive, because instead of solving his problem, it's simply creating an additional problem (how to explain this to the boss/customer/etc. without getting yelled at, losing his job, or just looking like an idiot).

Maybe he has already made some kind of commitment around this, which, yes, is a poor decision for a manager to make without first asking people in the know, but it happens, sometimes unintentionally.

It doesn't matter how you dress up the "no". It doesn't matter if you phrase it in the form of a question, and it doesn't matter how calm and diplomatic you are about it. Those things help grease the wheels of your ongoing relationship, but they don't help solve his problem!

As the "maker" it is your job, if you must object, to suggest alternatives. Find a way to actually solve the problem, even if it's not in the way that he originally expected. In my experience, only the most stubborn and incompetent managers will insist on a specific solution without justification even when they have been presented with reasonable alternatives.

By far the most common example of this that we probably all experience almost every day is time management. We are told that we have X days to do Y. It will invariably get you nowhere to simply say "Sorry, but I can't do Y in X days, that's just not enough time." You will likely get told to "make it happen" or "find a way to get it done."

So you don't say that. You say:

I am not sure if we can do all of Y in X days, but I have a suggestion: If we assume A, B, and C, then we might be able to take a few shortcuts in Q, and defer part Z until a little later, and I think we could manage that in X days. Would that work?

If your problem isn't time-based, but rather based on some technical constraints, you only need to change a few words. For example, in your case, there seems to be a dependency on some other work or component being completed, so change "in X days" to "without component/feature X being completed first", and instead of phrasing it as an inability, phrase it as a risk.

If you just had this sprung on you and haven't had time to think of any alternatives, then just say so:

I'd like a little bit of time to investigate this request/requirement. I think there might be some complications, but if you can explain to me a little about why you need this right now, I'm confident that I can have a solution mapped out for you by the end of the day.

It's still possible you won't get your way and be "forced" to go ahead despite your objections, but if you've discussed alternatives then presumably he has already explained to you why they won't work, which means that he is actually right, or at least that his rationale is as valid as yours. Also, it's important to time-box this investigation and actually make a commitment to get back to him, otherwise it will just appear (and rightly so) that you're stonewalling.

---

Incidentally, this works in pretty much any negotiation, and you really should look at this as a kind of negotiation. It's a lot harder to negotiate if you're only willing to put one issue on the table (like, say, an amount of money); that makes the negotiation adversarial rather than constructive, two people fighting over who gets a bigger piece of the pie.

You want to make the pie bigger, by offering other options or concessions that are preferably cheap for you but valuable to them. In a financial negotiation it might be payment plans, interest rates, free gifts, testimonials, that sort of thing. In the workplace, the major currency is usually effort, but you can also negotiate scope, time, quality, and a handful of other domain-specific modifiers (e.g. performance and availability in IT work).

Maybe there is something really simple you could do in a short amount of time that will produce almost the same result or at least eliminate most of the risks that you're concerned about. Maybe not, but at least give yourself the opportunity to think about it before just saying "no" (in any form).

Answer 7

If you're inclined to say "no", you must have good reasons. Present those reasons (price, risk, time, etc) in such a way that any reasonable person would come to the same conclusion as you.

You're the technical expert; if the proposed solution looks good to the PM but bad to you, you should be able to articulate the relevant points that the PM may not be aware of.

Answer 8

Present your protest as politely as possible...then do what your manager says afterwards, regardless of the outcome.

I do echo the sentiment that you should always lead with the explanation, rather than a refusal, since hearing "no" can immediately set an edge to your tone. But if you've already explained why the idea is bad, and your boss still insists it go through...then you've done all you can.

Sometimes the push isn't coming from your boss, but from higher-up or an outside source - I've dealt with this before. Users can sometimes make unreasonable demands that they cannot be swayed from, and unfortunately it's up to your boss to make it happen, and therefore up to you to help him make it happen.

However...

Now, if it truly IS impossible, then you're really in a hard spot, and may need to sit down with your boss and his boss to explain that you literally cannot do what they are asking. And you will need to make it clear that it is impossible, because they may be under the impression that you are just saying it to get out of work. Write your reasoning, make it as clear as possible without taking a confrontational tone, and above all express regret that it cannot be done, because hopefully you would be willing to do it if it were possible.

Answer 9

You ask, "how can I provide technical reservations without antagonizing people or coming across too hostile?". There are two parts to this:

1. Assuming that you are not antagonizing or being hostile, how do you make sure you reflect this in your approach and how you phrase things. I think you've gotten excellent answers from this angle.

2. Is there some basis in your attitude, in your approach to your work and your work interactions, that can come across as antagonistic or hostile regardless of how you phrase things?

(Obviously, it's better in either case to phrase things well rather than poorly. But if there is something to #2, simply phrasing things well is not the long-term solution.)

I've written and rewritten this answer and it's really hard to communicate it well. I'm thinking mainly of myself early in my career and some of the problems I had -- some of which I vaguely perceived at the time but which I can now see more clearly in hindsight.

For example, I had (and still have to a great extent) a rather scientific view of how you come up with the best implementation: the vigorous clash of various proposals and the best idea wins. Sincere as my belief was, and as willing as I was to admit that someone else's idea was the best idea, that's not how it comes across to most people. And I can see now that this approach is narrow and doesn't look at the Big Picture of a team, a project, and what success is.

So my question for you is: what was your attitude? Did you view the PM as a bit out of touch with the technical aspects, and thus a less-valid voice in the implementation? Were you exploring the options, or wanting to persuade the PM that his idea was a bad idea? Did you remain aware that the PM has to wrestle with a range of questions and pressures that you don't, and ultimately the success and usefulness of a project is not measured solely on its technical merits or power? Were you viewing this, almost subconsciously, as a quick "fight" moment where you muster your argument, he musters his and the best idea wins? Were you subconsciously viewing the PM as technically inferior and thus as the one who has to come to you (the technically superior one) for approval or validation of their feature suggestions?

I can see all of these issue in my career. Nothing cynical: I was sincere and felt like I was contributing the best I could as a team member. The bottom line is that the attitude leads to the approach, which leads to the phrasing, and even then the attitude leaks through in emotion and body language.

Perhaps that part of it can only be learned "the hard way" through experience. Though some people seem to have learned it at a much younger age than I did.

Answer 10

I find in these situations that getting really concrete about the outcomes helps. If you're speculating that bad things will happen, then their speculation (that they'll make more money) will win.

BTW it works the other way, too, when you see an opportunity but all they see is the risk.

Taking it out of the speculative realm and into the concrete really grounds the conversation. If you can say, "20% of our active clients won't be able to log in to the product", then all of a sudden it's contingent on them to solve that reality, and a lot of times the reality is just too daunting.

But you have to be prepared for the possibility that they are right. Sometimes the difference comes down to Optimism vs. Pessimism, and in that case flexibility is important.