How to Drive Meaningful Change - Handling objections to your proposal
Be prepared to handle the various responses you will receive when you propose a change.
Everyone can benefit from understanding and knowing how to build influence, implement change, and shape the organization and culture.
Much of it relies on learning and understanding the soft skill of navigating organizational politics.
This article is part of my series How to Drive Meaningful Change.
Handling objections to your proposal
Objections
When you deliver your proposal, you will get a response of some kind from the stakeholders and decision-makers.
While we all hope it is full-throated acceptance and a round of applause, it is extremely unlikely that will happen all the time.
Instead, you must be prepared to handle objections and the various responses you will receive. Handling might mean redirecting, debating, incorporating, or even ignoring, depending on the context.
Having a strategy helps you navigate the response in the heat of the moment improving the odds of successfully driving forward your change.
Categorizing responses
If we use a categorization model, you can expect 3 different kinds of responses when you propose something:
A disagreement on outcome. There is a fundamental disagreement between you and the other person on the end desire or goal that you want to achieve.
A disagreement on mechanism. While your goal may be shared by the other person, there is disagreement on the proposed solution to reach that goal.
An agreement and alignment. There is both agreement on outcome as well as the mechanism to achieve that outcome.
Each of these requires a different approach to address objections or challenges.
Dealing with disagreements on outcome
There’s several ways that disagreements on outcome manifest:
Rejecting
Denying
Diminishing
Nitpicking
Obstructing
Rejecting
aka. “Nope.”
“I’m gonna have to say no.”
“We have rejected your proposal.“
“I disagree.“
A rejection is exactly what it sounds like. Your proposal is rejected, with no explanation why.
In this case - ask for specific reasons why. One you know the reason, you can address it.
Denying
aka. “This isn’t a problem”
“The user activation rate isn’t a problem - our rates are fine.”
“The team is happy, why do we need to increase the party budget?“
“Leaders take time to onboard - it’s too soon to determine his performance.“
Denial occurs when people don’t agree there is a problem. Since they don’t agree the problem exists in the first place, they are unlikely to want to invest their energy or resources in resolving the problem you propose to solve.
There’s a few techniques you can use to address these:
Paint a picture of the problem. If you can illustrate the problem truly exists in terms they understand, you can convince them to move beyond this objection. Consider your narrative and what is important to that stakeholder.
Get feedback from those suffering from the problem. Sometimes, the denial comes because you lack credibility in representing the problem. Getting direct feedback from those suffering the problem may be enough to move past denial. Anecdotal but personal evidence can craft compelling reason from an empathy and sympathy standpoint to recognize the problem exists.
Reduce their cost and energy. If the person doesn’t actually have to invest any resources or energy of their own, you could theoretically minimize their concern or involvement to bypass their denial. Emphasize how it won’t impact them or their organization at all, or even how negligble the cost is. They may move on to bigger and more important subjects and leave you to your devices.
Diminishing
aka. “This isn’t that big of a problem”
“Retention rate is down, but only a few percent - it matches expected seasonality.”
“Team churn isn’t a huge deal - we can replace them pretty quickly.“
“We’ll just pay the daily fine - it’s the cost of doing business.“
Diminishing is a form of denial. Instead of denying the problem exists, the stakeholder agrees the problem exists, but disagrees on the magnitude or importance.
Techniques to resolve:
Illustrate the magnitude. This is where your research is important. Get data, quantify costs and impacts in a way the stakeholder cares about.
Paint the long-term picture. A lot of diminishment comes from problems that are minor embers now, but can turn into massive fires later. If you’re doing your job right, you’re trying to avoid a fire before it starts. Paint a picture of what this catastrophic end state likely might be if the problem is left untreated.
Compare it to other addressed problems. If you can show that the organization has approved or otherwise taken action on solving lower-magnitude or less important problems, you can make an argument that a higher-magnitude issue should certainly get traction. Otherwise, the other addressed problems should also be ignored.
Ask the threshold at which they would start to consider it a problem. Sometimes the person just has a different level of pain tolerance or a different set of tradeoffs they are optimizing for. Understanding what that problem threshold would be is extremely useful for calibrating when it would start to be considered a problem for that person.
I once worked with a team member that alway shot down ideas to improve the product, saying that “most users didn’t experience it”. After a bit of this, I asked her “how many users would need to experience this for it to be a problem?”
Her response: “90% of users”
This immediately started a discussion regarding our user segments and the fact that no problem we worked on ever had more than 20% of users experiencing issues, making 90% an unrealistic bar for most changes. After some back and forth, she had it gently pointed out to her that she didn’t even follow it on her own ideas and proposals, she realized the error of her heuristic and backed down.
Nitpicking
aka. “Have we considered this, or this, or this?”
“We haven’t done the research on React v14.2.1 vs. v14.2.2, so I can’t approve moving off of EmberJS.”
“This is terrible - you used the secondary brand color here instead of the primary!“
“Before I approve this $10,000,000 spend, why in the world is there a $500 line item for team snacks?“
Nitpicking is about resistance to the proposed solution, but the resistance is specifically not relevant to the actual outcome or success. Also known as “bike-shedding”, it’s over-discussion about details that are implementation related or don’t matter to actually proceeding or not with a proposal.
The classic example is when a committee is discussing whether to build a nuclear reactor or not, and the decision is being blocked on agreement. as to whether the bike-shed should be painted blue or green - a non-consequential detail to making the decision.
There’s typically a root cause for nitpicks you can address.
Disagreement on outcome. The root cause of the nitpicks is sometimes related to the fact that the outcome doesn’t actually have buy-in. At which point, you can treat it as a denial or diminishment and act accordingly.
Lack of perspective on problem or solution. Re-orient people back on the primary problem, and highlight the relative unimportance of whatever is being stuck on.
Lack of other ability to contribute. Some people just want a path to contribute. Because there’s no other way, they instead contribute to minutiae, delaying. a decision. You can either provide other ways for them to contribute that don’t block the decision, or challenge their involvement in the decision-making process at all.
Personal relationship issues. You may have just made someone mad. Perhaps they don’t like you, or they are just that kind of person who over-focuses on irrelevant details.
Obstructing
aka. “I’m gonna need you to do this and this and this. Why? Dunno.”
“Sorry, you have to fill out Form 173 before I can even look at your Form 184.”
“Can you get agreement from these 9 random people with no stake in this decision?“
“Your team needs to do their daily log before I approve this new project.“
Obstructing is when a decision-maker or stakeholder introduces various hoops you must jump through to gain approval that are disproportionately difficult relative to the value they provide, or do not have any reasonable purpose relate to the proposal.
There’s a couple ways to deal with this:
Do them. If the hoops are done, you can get approval. Yes, it means extra work, but it might be the fastest way. If later on even more hoops are added, you can point out the discrepancy and have a direct conversation about that. This is a useful method to deal with organizations that have layers of bureaucracies.
Point out the hoops’ lack of purpose. You can directly address the fact that the hoops have no purpose or value. Depending on the organization, you may be able. to get the hoops removed.
There can be a deeper reason why someone might be obstructing your proposal:
Lack of trust. If you lack credibility, or there’s some element of your performance that has caused deceased trust, this can cause opposition. Gently ask about ways you can build up or restore trust.
Personal relationship issues. Once again, your personal relationship can plan in here. The best way to avoid this is to have good personal relationships with everyone.
Horse trading. Stakeholders have their own needs. Perhaps they see this as the opportunity to get their item done.
One you understand why the hoops are being put up, you can work to go through them or remove them.
Dealing with disagreements on mechanism
When there’s a disagreement on mechanism, it means that the disagreement surrounds the specific context and constraints of your approach. While your goal may be shared by the other person, there is disagreement on the proposed solution to reach that goal.
There’s several ways that disagreements on mechanism manifest:
Rejecting
Criticizing
Optioning
Compromising
Rejecting
aka. “Nope.”
“I’m gonna have to say no.”
“We have rejected your proposal.“
“I disagree.“
Same story - a rejection is exactly what it sounds like. Your proposal’s solution is rejected outright with no explanation why.
Same as before - ask for specific reasons why. One you know the reason, you can address it.
Criticizing
aka. “There’s quite a few challenges and issues here.”
“Users are unlikely to even look at that page given the analytics information we have.”
“This proposal relies on a key team member that’s going to be OOO for 3 months.”
“The system doesn’t actually do what you’re saying it does.“
Criticizing is when stakeholders start to bring up relevant reasons why a proposed solution or change won’t work, discussion obstacles, challenges to execution, or even changes to the ROI, etc.
If you’re hearing about many of these things the first time - you probably should have done more research.
If you are addressing the challenges in your risk management, mitigating them, etc. then criticisms are generally overcome-able by talking through your plan to address each one.
Criticisms are extremely valuable as they tell you whether your idea has considered important factors or not.
Some criticisms have their root in a disagreement of outcome. Keep an eye out for when the criticisms start to talk about the why or the problem instead of the approach.
Generally, criticism can be addressed if you are prepared:
You can accept it. A plan doesn’t need to be perfect to be effective. Having a weakness in the proposal can be accepted explicitly as a risk.
You can reject it. If a criticism is unwarranted or doesn’t entirely apply due to some mitigating factor, you can reject it. You can explain why it shouldn’t be considered in the decision.
You can address it. You can take that criticism, and modify your proposal to factor it in. Alternatively, you can explain how you’ve already addressed it in your plan.
Optioning
aka. “How about doing this instead?”
“A much faster approach might be to send an email blast instead of calling everyone.”
“We should move the budget from Product instead of Engineering to support Sales.“
“What about implementing an unlimited leave policy instead of giving 30 days?”
When stakeholders agree with your outcome, but disagree with your mechanism, they may propose alternate approaches that help meet the same outcome.
If your solution is inherently unimportant, be open to the options they propose - if all roads lead to Rome, then does it matter what road you take?
If the specific form of the solution is important, then you can address the pros and cons of each approach and make a recommendation. You should be willing to walk away from your proposal if your solution is not approved.
I once raised a capacity issue to the leadership team. I needed them to recognize that the amount of work they expected to get done was far beyond the amount of people available. Worse yet - there had been no guidance on the relative importance of any of these projects, which came from various executive leaders across the company without coordination.
There’s a lot of ways to resolve capacity issues - hiring more, doing less, reducing scope, delaying projects, re-prioritizing, enabling the team, etc. I didn’t particularly care what solutions were implemented - only that the problem was acknowledged and addressed. While I had my own thoughts we should hire more, I decided to let the discussion play out.
By the end of it, the leadership team had prioritized amongst themselves the top projects, cut unimportant ones, pushed back some non-urgent ones, and opened up hiring for a few of the teams to make up expected shortfall - significantly better options than my initial singular approach of hiring more.
Compromising
aka. “We can both get some of what we want.”
“We’ll move Alice and Bob to the new team, but we’ll need to move Charlie off.”
“We can move Project A to Q1, but we’ll need to stop work immediately on Project B.“
“You can hire a new person, but you’ll need to terminate two under-performers by Q2.”
Compromising is when stakeholder ideas get merged together to water down the overall solution. It results in implementation of parts of the solution but not others that decrease overall effectiveness but still allows of the goal to be met.
Compromises are often unavoidable. Don’t be a ideologue, but keep the goal in mind and horse-trade as appropriate.
Agreement and Alignment
If you get agreement and alignment, you’re in generally good shape for getting your desired outcome and solution approved.
Responses you might get are:
Accepting
Reinforcing
Testing
De-risking
Accepting
aka. “Look good to me.”
“Your approach is sound. Let me know what you need.”
“Looks good.“
“Good to go. -full steam ahead.”
Stakeholders fully agree with the outcome, as well as the mechanism you proposed, with no changes. This is full acceptance, and the easiest path forward for you.
Congratulations!
Reinforcing
aka. “Hey, it’d be even better if we did this, too.”
“We could even add a banner to the page to upsell in addition to the ad you proposed.”
“That’s great - maybe we can also do a secondary survey.“
“If we have an offsite, we could probably throw in some fun events to build team camaraderie.“
When stakeholders start to suggesting improvements on top of the proposed solution that help reach the same or substantially the same goal, that is actually a great sign.
In order to move to a formal acceptance and avoid scope creep that could then make the proposal unwieldy and thus move it to rejection, explicitly get agreement that they agree to the outcome and the general solution, and propose further discussions to iterate on the solution together one the proposal is formally accepted.
Incorporate their feedback, consider the scope, cost, and other factors and generally move forward.
Testing
aka. “Look good to me, but let’s check in after a month.”
“I think the plan makes sense, but let’s look at numbers in a month.“
“Let’s roll out the A/B test and reconvene in a week.“
“If the monetization rate stays above 20% next quarter, we’ll keep it.”
Testing is a conditional acceptance of your proposal.
Your proposal’s outcome and solution was accepted, but there’s a decision re-evaluation at some point in the future to determine whether the decision should be kept - ie. a trial run or a test. It means if it turns out to have issues, it might be reversed.
You’ll need to get agreement on the parameters of the test - if there are unreasonable expectations of early or immediate success, you’ll want to hash that out now before going forward and having the test fail. Your discussions will mostly revolve around managing the timing and scale of expectations rather than the outcome or solution.
After you all agree on the parameters, that’s it. Follow the test, report results accurately, and proceed with a permanent rollout if the results are positive. Make sure it goes as smoothly as possible.
I once proposed and got conditionally accepted a test of a major user workflow change. It was an extremely risky bet I had high confidence in. When it was approved, it was conditionally so - “we’ll check later to see how effective it is.”
My error was that I didn’t nail down ahead of time was the definition of “later”. Two weeks later, the leadership team reconvened and asked for metrics. It was far too early for any promising results to have occurred.
While I managed to negotiate for more time for the test to run, it put me in an awkward spot of trying to justify the test’s underperformance. I could have avoided this altogether had I ensured I aligned early on expectations of when the outcome could reasonably be measured.
De-risking
aka. “I have some concerns with the approach.”
“Can we try this out on a subset of people? I’m afraid they’ll react quite negatively”
“We should get some opinions from the team before committing to this.“
“Let’s wait until after the busy season before making this change.“
De-risking is when stakeholders agree with your outcome and mechanism, but impose constraints or guardrails to address a perceived or real risk. The most common guardrail are typically around budget, timing, and audience.
If the guardrails are appropriate, incorporate them and move forward. If they are busy-work, you can try to argue out of it but it might be easier to just do the busy-work.
If the guardrails would cause undue burden to your solution, propose other mechanisms to address or mitigate whatever risk is being brought up.
Knowing how to address the various kinds of objections you will receive when you deliver a proposal is key in successfully driving forward the change you want to see.
People are complex with different motivations and perspectives - being able to easily and quickly factor in their perspectives to strengthen your proposal is a skill that can be learned.
A single objection doesn’t mean the end of your idea. Treat it as a beginning for further discussion and refinement.