Middle managers and innovation: the quiet blockers, and how to win them

Middle managers rarely block innovation by saying no. They block it by saying "yes, after the quarter", by not releasing people, and by letting a pilot sit in their area without an owner. You win them by changing what innovation costs them and what it gives them: protect their targets, give them a real decision, and make their team's work visible under their name.

Why the middle goes quiet

Leaders tend to read slow middle managers as resistant or unimaginative. That reading is usually wrong, and it leads to the wrong fix: more inspiration, more town halls. Look at the job instead.

A department head is judged on delivery this year. An innovation programme asks for their best people's time now and promises a benefit later, often credited to someone else. They also carry the risk: if the pilot disrupts a service, the complaint lands on their desk, not the innovation team's. Saying "not now" is a rational answer to that deal.

Research on strategy has long pointed the other way from the stereotype. Steven Floyd and Bill Wooldridge's work in the 1990s showed middle managers do far more than implement: they champion alternatives, synthesise information upwards and quietly adapt plans to reality. The same people who can stall an idea are the ones who can carry it into operations. The task is not to get around them. It is to make the deal worth taking.

Seven steps to win middle managers

1. Map who actually holds the keys

Not every manager matters equally to a given initiative. List the managers whose people, budget, systems or customers the idea touches. For each, note what they control, what they are measured on, and what this initiative changes for them. A stakeholder map gets you the list; a stakeholder expectations map gets you the "what do they need to be true" column, which is where the real work is.

2. Talk to them before the programme is announced

The surest way to create a blocker is to let a manager learn about an initiative in their area from a launch email. Meet each key manager one to one first. Ask what is hardest in their area right now, and what they have tried. You will often find their problem and the programme's problem overlap. When they do, frame the initiative around their words, not the strategy deck's.

3. Name the cost honestly, then reduce it

Ask directly: "What would this cost you this quarter?" The answer is usually hours, a key person, or a target at risk. Then reduce it on purpose. Agree a fixed time box (for example, half a day a week for six weeks), name a back-fill, or ask the sponsor to adjust one target for the pilot period. A force field analysis done with the manager, not about them, makes the restraining forces concrete and shows you which one to remove first.

4. Give them a decision, not a briefing

Managers support what they help decide. Give each key manager a real decision right: which of their team joins, which week the test runs, which customer segment it starts with, or the go or no-go after the pilot. Write it down. A simple RACI that shows the manager as accountable for the pilot in their area is worth more than any amount of engagement.

5. Make room by stopping something

New work on top of full workloads fails slowly. Run a short stop-doing list session with the manager and their team: which report, meeting or approval step can pause during the pilot? This is the step leaders skip, and it is the one managers notice most. It signals that the organisation means it.

6. Put their team's work in front of senior people, with their name on it

When the pilot produces something, the manager presents it, or presents it alongside their team member. Credit for the idea goes to whoever brought it; credit for making room goes to the manager, said out loud in front of their own boss. This changes the deal from "you take the risk and someone else gets the credit" to "your area is where things happen".

7. Agree the handover before the pilot ends

The quietest form of blocking is the orphaned pilot: it worked, but nobody owns it in operations. Before the test starts, agree with the manager what happens if it works: who runs it, from which budget, by when. If they will not commit to that, you have learned something important early. The lab to operations handover covers this in detail.

Worked example (Illustrative)

A regional logistics firm in Rotterdam wanted to test a self-service rebooking flow for missed deliveries. The innovation team had sponsor backing and a prototype. Three weeks in, nothing had moved. The customer service manager kept postponing the test because her team was measured on call handling time and was short two people.

The innovation lead changed approach. She met the manager alone and asked what cost her most. The answer: repeat calls from the same customers about the same missed delivery. That was exactly what the rebooking flow targeted. They agreed three things on one page: the test would run for four weeks in one region only; the sponsor would exclude that region's handling time from the monthly review for the period; and the manager would choose the two agents who reviewed failed rebookings and make the go or no-go call at the end.

The test ran. The manager presented the results to the operations director with her two agents. When the flow went live, it went into her area with her team running it. Nothing about the idea changed. What changed was the deal.

Do's and don'ts

Do

• Meet key managers one to one before any public launch.
• Ask what the initiative costs them, and fix at least one cost.
• Give them a written decision right, not just a seat in a steering committee.
• Credit their area publicly in front of their own leadership.
• Agree the operational owner before the test begins.

Don't

• Don't treat silence as agreement. A manager who says nothing in the meeting may say no with their calendar.
• Don't go over their heads to get people released. You will get the people once and lose the manager for good.
• Don't run "innovation mindset" training for managers as the fix. The problem is the deal, not their mindset.
• Don't ask for "a few hours" without an end date. Open-ended asks get open-ended delays.
• Don't label managers as the frozen middle in front of others. People live up to the labels they are given.

When a manager still says no

Sometimes the deal really is bad for them this year: a regulatory deadline, a system migration, a team in crisis. Accept it and move the pilot to an area where the timing works, then come back with results. A clear, respected no is better than a reluctant yes that quietly starves the work. What you should not accept is a no that is really a no to being consulted. That one usually changes once step 2 is done properly.

If several managers say no for the same reason, the problem is upstream. Their targets or incentives leave no room, and the conversation belongs with senior leadership. Our piece on getting senior leadership to back an idea covers how to bring that case up the line.

Questions people ask

Why do middle managers resist innovation? Usually because the deal is poor for them: innovation takes their people and time now, adds risk to their area, and the credit often goes elsewhere. Fix the deal before you try to fix their attitude.

What is the role of middle managers in innovation? They turn ideas into operations. They know where the real problems are, decide whether people get time, and own the service after a pilot ends. Without them, pilots succeed and then disappear.

How do you get managers to release staff for innovation work? Ask for a fixed time box, offer a back-fill or adjust a target for the period, and let the manager choose who joins. Release is easier to give when it is bounded and when the manager chose it.

Where to go next

Start by mapping the managers your next initiative depends on with a stakeholder map, then use a force field analysis and a stop-doing list with each of them. Agree roles in a RACI. For the wider picture, read innovation culture: what it is, and how leaders actually build it and innovation in hierarchical cultures.