The Squeaky Wheel Belongs on the Committee

Earlier in my career, I thought one of the best things I could do as a leader was bring people well-researched solutions.

If we needed a new system, I researched the options. If costs were rising, I looked for alternatives. If a process wasn't working, I tried to find something better.

I would sit through demonstrations, compare pricing, check references, ask questions, negotiate terms, think through implementation, and sometimes spend weeks or months making sure I understood an issue from every angle.

Then I would present what I believed was the best solution.

And occasionally, it would blow up in my face.

Not because the solution was bad.

Sometimes it saved the organization money. Sometimes it saved the employees money. Sometimes it provided better service or greater convenience. Often it accomplished several of those things at once.

What I hadn't yet learned was that making a good decision and successfully implementing it are two different things.

When the Numbers Aren't the Problem

I learned this more than once with health insurance.

Around 2009, in the middle of the global financial crisis, I was trying to balance several competing responsibilities: controlling organizational costs, maintaining generous employee benefits, and navigating an economic environment that had created considerable uncertainty.

Years later, I faced another version of the same challenge as insurance costs skyrocketed. I negotiated alternatives that could dramatically reduce costs without sacrificing benefits.

From my perspective, these were good outcomes.

But employees didn't experience the weeks or months of research, analysis, and negotiation that had led to the recommendation.

They experienced something much simpler:

My health insurance is changing.

And health insurance is personal.

People worried about doctors, coverage, costs, and what the change might mean for their families. Some came to me with questions, and those were relatively easy to address.

The harder part was what happened outside my office.

A few people would raise concerns with colleagues. Questions became worries, worries became assumptions, and before long a change designed to benefit employees could generate a firestorm of negativity.

We ultimately moved forward because I remained convinced that the change was the right one.

But getting there consumed enormous amounts of time and energy. More importantly, it burned leadership capital unnecessarily.

I had solved the insurance problem.

I hadn't adequately managed the change.

What You Don't Know That You Don't Know

I encountered another version of the same lesson when implementing technology.

About 13 years ago, we were introducing a comprehensive school information system for the first time. Until then, different functions had been handled through a collection of smaller systems, spreadsheets, paper, and other processes.

I did the homework.

We looked at vendors. We evaluated systems. We asked questions. We compared pricing, functionality, and service. The administration was deeply involved in the selection.

What we didn't do well enough was involve the broader staff, particularly some of the people most likely to resist the change.

When the system was rolled out, we discovered that completing the technical due diligence wasn't the same as preparing the people who would actually have to use it.

Another technology implementation taught me an even subtler version of that lesson.

When I joined one school, families receiving financial assistance were already required to use an online tuition payment platform. Other families could pay in different ways, including methods that created significant administrative work.

I wanted everyone on the same platform.

Operationally, it made tremendous sense. It would reduce manual processing and collections, allow us to handle incidental charges more efficiently, and ultimately make things easier for parents as well.

We announced the change in February for the following school year.

And I immediately encountered resistance I hadn't anticipated.

Some families had developed a perception that using this particular platform was associated with receiving financial assistance or having difficulty paying tuition.

I saw a payment system.

They saw a stigma.

No vendor demonstration, pricing analysis, or implementation checklist would have told me that.

By the time the new school year arrived, even many of the strongest critics had discovered how convenient the system was. Families could handle tuition and incidental charges in one place, see what they owed, and avoid writing small checks throughout the year.

The outcome was good.

But knowing what I know now, I would have handled the rollout very differently.

The problem wasn't the decision. It was that I didn't understand what the decision meant to the people experiencing it.

Learning to Ask Earlier

Over time, I adjusted.

Instead of doing all the research myself and presenting a finished recommendation, I started creating small committees. I invited people into vendor meetings. I asked prospective users to test systems. I informally polled people who would be affected.

For one later system implementation, I even brought six people to a summer conference so some of our power users could learn about the system with me. We attended sessions, spent time together, ate together, and built a shared understanding of what we were about to implement.

The difference was significant.

Sometimes people offered genuinely valuable feedback that changed what we did.

Other times they asked questions I hadn't considered.

That became another important lesson for me: expertise can create its own blind spots.

When you have spent months studying something, you begin taking certain information for granted. The person who knows much less may ask the basic question you no longer think to ask.

And if one person is wondering about it, others probably will too.

Hearing those questions before a rollout gave me the opportunity to change the plan, clarify the communication, or simply anticipate where anxiety might arise.

But there was another benefit I hadn't initially appreciated.

Sometimes people didn't really want to participate. They didn't attend every meeting. They didn't have strong opinions. They didn't necessarily contribute much to the decision.

They just wanted to know that someone thought to ask them.

That mattered more than I had realized.

Then A Mentor Gave Me the Missing Piece

Eventually, I thought I had figured this out.

I was collaborating more. I was creating committees. I was bringing other people into decisions.

And yet I found myself complaining to a mentor about the same few people who continued to push back against changes.

I couldn't understand it.

I thought I had learned my lesson.

This time, I hadn't worked in a vacuum. I had involved other people. I had sought feedback.

Why were these same people still creating so much resistance?

His advice was simple:

Bring them into the group.

My immediate reaction was essentially: Why would I do that?

These were precisely the people I found difficult to collaborate with. They were skeptical. They resisted change. They could be negative. If I was assembling a committee, why wouldn't I choose knowledgeable, reasonable people who could work constructively together?

That, he helped me understand, was precisely the point.

I was bringing people into the process, but I was mostly bringing in the people who were easiest to bring into the process.

The people most likely to challenge the eventual decision were still outside the room.

The Squeaky Wheel Belongs in the Room

So I began doing something that initially felt counterintuitive.

When I formed a committee or gathered feedback, I deliberately considered including someone I expected might object.

Not because that person had veto power.

Not because every decision needed consensus.

And certainly not because the loudest person should get to dictate what an organization does.

I wanted the perspective.

If someone was going to find ten reasons why an initiative wouldn't work, I would rather hear those ten reasons before the rollout than afterward.

Some objections were useful. Some exposed issues we could fix. Some helped me communicate the change more effectively. And some weren't particularly persuasive at all.

But something else often happened.

The person who might have become the loudest critic after the decision could become one of its strongest advocates.

They had been part of the conversation.

They understood why certain alternatives had been rejected. They had heard the questions and answers. They knew their concerns had been considered, even when the final decision didn't reflect every suggestion they made.

And the same informal influence that could once have spread resistance could now work in the other direction.

The squeaky wheel could become a catalyst for change.

But Not Every Squeaky Wheel Belongs on Every Committee

Like many management lessons, this one can be taken too far.

I know because I did that too.

There were times when I included too many skeptics, or simply the wrong ones, and the energy became counterproductive. Instead of challenging assumptions, people undermined the process. Instead of identifying legitimate concerns, the conversation became resistance for resistance's sake.

I've also had situations where trying too hard to solicit input created anxiety that might not otherwise have existed.

In one employee benefits discussion, I was so determined to involve people and avoid the mistakes of the past that I oversold the consultation itself. Questions and concerns began circulating through the group, anxiety fed more anxiety, and we never recovered enough momentum to implement what otherwise seemed like an obvious improvement.

That experience swung the pendulum back a little.

The lesson wasn't that every critic belongs on every committee.

It was that I needed to become more thoughtful about who was in the room.

Who understands the issue? Who will actually use what we're implementing? Who will ask the questions I won't think to ask? Who has influence with others? Who is likely to be skeptical? And who can challenge an idea constructively rather than simply sabotage it?

Those are different questions from:

Who will be easiest for me to work with?

Inclusion Isn't Consensus

This distinction matters.

Stakeholder engagement does not mean everyone gets a vote.

Leadership still requires decisions. There will be times when people disagree with the final choice. There will be recommendations that aren't adopted and concerns that don't outweigh the broader needs of the organization.

I've moved forward with plenty of decisions despite objections.

The purpose of inclusion isn't to eliminate disagreement.

It's to make better decisions, understand resistance before encountering it, communicate more effectively, and give people a meaningful opportunity to participate in changes that affect them.

Sometimes their feedback changes the decision.

Sometimes it changes the implementation.

Sometimes it changes only the communication.

And sometimes it changes nothing except their understanding of how and why the decision was made.

That can still be enormously valuable.

Earlier in my career, I believed that if I did enough homework, negotiated the right deal, and found the best solution, people would recognize the value of what I was bringing them.

I eventually learned that organizations aren't spreadsheets.

"People don't experience change as an analysis. They experience it as change."

The work of leadership isn't finished when you've reached the right answer.

Sometimes that's when the harder work begins.

And before you roll out the next great idea, it may be worth asking one more question:

Who is most likely to complain about this?

You might want that person in the room.