When someone keeps blocking your ideas, ask these five questions before you push harder
Every leader knows the meeting
The analysis is solid. The numbers hold. The slides are clear. You present the idea, you look around the room, you get the nod, and then nothing happens. Weeks later, the idea is still under review, still parked, still waiting for a better moment that never arrives.
If you have ever taken a new role as a director or a VP, you have probably felt this inside your first ninety days: you were hired to change things, and yet the organization absorbs every change you propose the way a sponge absorbs water.
I have sat on both sides of that table many times
I have been the designer defending the redesign of a banking portal in Quito. I have been the solutions architect defending a new integration pattern. I have been the business development manager trying to shift how we run a multi-million-dollar RFP across six Latin American markets.
And, although it took me years to admit it, I have also been the person blocking someone else’s idea. The pattern is always the same, and it is never really about the quality of the idea. An organization is a living system with an immune system, and a new idea is treated like a foreign object until proven otherwise.
The mistake most leaders make is to push harder
More data, more slides, more meetings, more escalation. That usually strengthens the resistance, because pushing harder treats the symptom and ignores the cause.
Over the years, I learned to stop re-presenting and start diagnosing. There are five questions I ask myself when someone keeps blocking my ideas. They work in a bank, in a software company, in a government agency, in a family business. They work today, and they will work in five years, because they are not about technology or trends; they are about human nature, and human nature does not get upgraded.
Why resistance is information, not rejection
Before the five questions, one frame shift.
Resistance is not rejection; it is information.
When someone blocks your idea, they are telling you something about the system: about its history, about its timing, about what someone stands to lose, about how the problem is perceived, about who really holds influence. Leaders who treat resistance as data stop taking it personally and start reading the organization like a map.
The five questions below are my way of reading that map, and each one comes with a practical move you can use this week.
Question 1: Did they build the thing I’m proposing to change?
The first thing I investigate before proposing a change is authorship, I mean “who”.
- Designed the process I want to replace?
- Fought for its budget?
- Got promoted because the current system works?
If the person blocking me is the author of the status quo, I need to understand that what they are hearing is not “this process is outdated” but “your best work was a mistake“. No one accepts that message calmly, and no amount of data will make it painless.
I learned this the hard way early in my career, when I wanted to retire a manual reporting routine that a senior colleague had built years before. In my head it was obvious: the routine was slow, fragile, and expensive. In her head, the routine had saved the operation during a crisis, had survived two audits, and had proven her value to the company.
Every time I presented my automation plan, she found a risk I had not considered. I read it as obstruction. It was not obstruction; it was protection of the business as she saw it and of her own story.
The move that changed the outcome was simple
I stopped presenting the future and started honoring the past. I asked her to walk me through why the routine was built, what it had prevented, what it had achieved. I put that history on the first slide of my proposal, in her words, with her name on it. Only then did I introduce the change, framed not as a correction of her work but as the next chapter of it. The same idea that had been blocked for months moved forward in weeks.
Practical move: before you present the fix, find out who built the current thing.
Then credit, publicly, the problem it solved at the time. If you can make the author feel like a foundation rather than an obstacle, you convert your strongest blocker into your strongest sponsor. If you cannot, at least you will understand the real weight of what you are asking them to let go of.
Question 2: Have they told me no, or have they told me not yet?
Not every block is a no. Some blocks are a “not yet”, and confusing the two is one of the fastest ways to waste political capital. “Let’s revisit this next quarter“, “we need the pilot numbers first“, “this is not the right moment with the audit coming” — these are often not rejections of the idea but statements about sequencing and conditions. The idea may be fine; the calendar, the budget cycle, the risk appetite may not be.
The problem is that both answers feel like rejection, so leaders respond to both in the same way: they present again, louder. Imagine a client in a procurement process telling you, “Not yet, we have to close the current fiscal year first“, and you respond by re-sending the same proposal the next morning.
You have not shown persistence; you have shown that you do not listen. In enterprise deals, I have seen more opportunities lost to mistimed pushing than to weak proposals, and the same is true inside companies.
The diagnostic question is: what would need to be true for this to be a yes?
Ask it out loud, with genuine curiosity. If the other person can name conditions — a budget line, a headcount approval, a pilot result, a board meeting — then you are dealing with a “not yet“, and conditions are something you can work on:
You can sequence, you can pilot, you can wait, you can prepare.
If they cannot name a single condition that would turn it into a yes, then you are probably facing a real no dressed up as a delay, and you need a different conversation, usually about a concern they have not yet said out loud.
Practical move: keep a simple log of the conditions you hear
Write them down, repeat them back, and come back when they are met. “Last quarter you told me this needed the pilot results and the budget review. Both are here. Can we move forward?” That question turns a vague block into a concrete negotiation, and it makes it very hard for anyone to hide a no behind a not yet.
Question 3: What does this cost them personally?
Most leaders assume the decision is about the idea. It rarely is
Decisions are about people, and people resist what your proposal takes from them: headcount, visibility, control over a process they fought to own, a seat at a meeting, a line in the org chart, the feeling of being the person who knows. If your idea wins, something of theirs loses. Until you know what that something is, you are negotiating blind.
In my work on large IT deals I see this constantly on the client side:
- A technical director who has spent years building an internal team may block a managed-services proposal that is objectively better for the company, because for him the proposal means a smaller team, a smaller budget, a smaller title.
- A procurement lead may resist a framework agreement that would save money, because it removes the discretion that makes her powerful.
None of this is irrational. It is a rational defense of personal equity, and it is present in every organization, at every level, in every country I have worked in.
So I do the exercise on paper before every important conversation: if my idea wins, what does this person lose? I write it down without judgment. Then I design one of two responses. Either I protect what they value, for example by giving them leadership of the transition so the change becomes their project too, or I give something back that is honest and real: a new mandate, visibility with the board, ownership of the next phase.
You do not buy people; you design change so that more people win than lose. When that is impossible, at least you know the true price of the resistance, and you can decide whether the idea is worth paying it.
Practical move: write down what the blocker loses if you win
Then protect it, or give something back. A change that leaves the other person’s dignity and status intact moves; a change that humiliates someone stalls, no matter how good the numbers are.
Question 4: do people think there is a problem to fix?
Here is a humbling discovery for anyone in a new role: what looks broken to you may look normal to them. People adapt. They build workarounds, duplicate spreadsheets, parallel chats, informal rituals that compensate for the broken process, and after a while they stop noticing the cost. The pain becomes part of the landscape, like noise in a busy street. Then a newcomer arrives, points at the noise, and is surprised that nobody panics.
I have lived this from both sides:
- As a UX designer I watched users develop astonishing tricks to survive objectively terrible interfaces, and then defend those tricks as if they were features.
- As a business developer I have met teams that accepted weeks of manual rework as “the way things are”, because the cost had never been measured and named.
The block you receive when you propose a fix is often not disagreement; it is a lack of shared pain. They simply do not feel the problem you feel.
That is why I never start with the solution
I start with the cost of doing nothing, made visible and concrete.
- Count the hours lost per week.
- Count the deals delayed.
- Count the errors, the rework, the audits, the nights before a release.
Put a number on it, and whenever possible, let the number come from their own mouths and their own records, not from your analysis.
People argue with your data; they do not argue with their own. Once the cost is visible, the conversation changes from “do we like this idea?” to “can we afford to keep things as they are?”
Practical move: before you propose the fix, show the impact of the problem and the price of the status quo
Make the invisible cost visible, in their units and their words. Sell the problem first; the solution will then sell itself.
Question 5: who really influences this decision?
The org chart tells you who signs; it does not tell you who decides. Influence in organizations sits in unexpected places: a veteran engineer whose opinion the CTO trusts, a finance partner who controls the assumptions, an executive assistant who shapes the agenda, a regulator’s informal criterion, a founder’s old friend. You can win every meeting you are invited to and still lose the decision, because the decision was shaped in rooms you were not in.
When an idea keeps getting blocked, I ask myself who the blocker listens to, and who listens to the blocker
Often the person saying “no” to your face is not the source of the no; they are repeating a concern they absorbed somewhere else. Chase the concern to its origin. In one deal I remember, the visible blocker was a mid-level manager, but the real weight behind his resistance was an external auditor’s conservative reading of a regulation. Once we understood that, we stopped arguing with the manager and invited the auditor to a technical session. The block dissolved in one afternoon.
Practical move: ask, openly and without threat.
Who else needs to see this, or be consulted, before it moves forward?
Then consult them early, before the formal decision, when objections are still cheap to address. Mapping the invisible influence network is not office politics in the bad sense; it is respect for how organizations actually think.
Putting the five questions to work
None of these questions is a trick
They are a discipline of humility: before asking the organization to move, I make the effort to understand where it stands. In a new role, I use them as a rhythm for the first months.
- First, I learn who built what, and I pay respect to the legacy before I touch it.
- Second, I separate no from not yet, so I do not exhaust myself against closed doors that are actually open on a schedule.
- Third, I audit the personal costs my changes would create, and I design compensation.
- Fourth, I measure and narrate the cost of the status quo until the problem is shared.
- Fifth, I map the real influence network and bring the invisible stakeholders into the room early.
Only then do I push. And when I push, I push with the grain of the organization instead of against it. That is the difference between a leader who wins arguments and a leader who moves organizations. The first feels good for a day; the second compounds for years.
Closing thought: resistance is a map
If someone keeps blocking your ideas, resist the instinct to repeat yourself louder. Slow down. Ask who built the current thing.
- Ask whether you heard a no or a not yet.
- Ask what your win would cost them.
- Ask whether they feel the problem at all.
- Ask who really influences the outcome.
These questions will not make resistance disappear, and they should not: resistance is part of organizational life, and it is often a useful brake that saves us from confident mistakes. But they will turn resistance from a wall into a map, and maps are things leaders can actually use.
References and further reading
Web references
- “Leading change: why transformation efforts fail“, John P. Kotter, Harvard Business Review —
hbr.org - “The psychology of change management“, McKinsey & Company —
www.mckinsey.com - “The four building blocks of change“, McKinsey & Company —
www.mckinsey.com
Books that reinforce this post
- “Leading change”, John P. Kotter
- “Switch: how to change things when change is hard“, Chip Heath and Dan Heath
- “Influence: the psychology of persuasion“, Robert Cialdini
- “How to win friends and influence people“, Dale Carnegie
- “Crucial conversations: tools for talking when stakes are high“, Kerry Patterson, Joseph Grenny, Ron McMillan and Al Switzler
