Employee Resistance Is Design Feedback: A Creative Leader’s Approach to Organizational Change

My answer to employee resistance is to investigate before trying to persuade. Ask what the objection is protecting, distinguish a practical constraint from an untested assumption, and invite employees to help redesign the implementation. Then test a limited version before expanding it. Treat resistance as design feedback—not as proof that the change is wrong, and not as a character flaw in the person questioning it.

I'm Tucker Bryant, an artist, keynote speaker, and former Google product marketer. For me, creative leadership during organizational change isn't primarily about producing another exciting idea. It's about being willing to edit the idea you've already committed to. That includes asking an uncomfortable question: What if the plan needs to change before we ask people to change?

Start with the objection, not the label

Prosci recommends approaching resistance as a signal of employee concerns, with feedback informing the change strategy. That's practitioner guidance, not evidence that every objection reveals a design flaw. I find the distinction useful: take the concern seriously without accepting its conclusion automatically.

I'd begin by replacing “Why are you resisting?” with more specific questions:

• Which part of this change will be hardest to carry out?
• What responsibility would become harder to fulfill?
• What would need to be true for this approach to work?
• What should we observe before deciding whether to expand it?

The point isn't to conduct a warmer interrogation. It's to produce something concrete enough to examine. “This won't work” is a starting point. “The proposed approval deadline falls before the information is available” gives you a condition to investigate.

Separate constraints from assumptions

The Grossman Group describes systemic resistance as arising from organizational barriers such as incompatible systems, insufficient resources, and competing priorities. Its practitioner classification offers a useful prompt: investigate the conditions of implementation before deciding that unwillingness is the problem.

I'd sort objections into three working categories. These are discussion tools, not a validated diagnostic test.

A constraint to address

Imagine a hypothetical team being asked to adopt a new reporting process while retaining every existing report. “We don't have capacity” deserves an inventory: what work is being added, what remains, and what can stop? Ask for enough detail to make a resource decision—not for employees to prove their exhaustion.

An assumption to test

Now imagine the objection is, “Our customers won't accept a different handoff.” I'd ask what supports that prediction and what a safe test might look like. Don't dismiss it as habit. But don't treat familiarity as sufficient evidence that an alternative cannot work.

A trade-off to decide

Some objections deserve an explicit choice rather than a workaround. Suppose a proposed process prioritizes speed over individual discretion. Ask whether that trade-off is intentional, who bears its costs, and who has authority to make the decision. If you proceed, explain what you're choosing and what you're declining to preserve.

My rule would be simple: don't call an objection habitual until you've made a reasonable effort to understand it. Equally, don't give an objection permanent veto power just because it has been stated forcefully.

Write By Erasing: make room for the transition

One principle of my keynote, Do Different Things Differently, is Write By Erasing. Applied here, I'd turn it into a practical question: What will we remove so this change has room to happen?

The Grossman Group notes that change initiatives can temporarily add workload as employees maintain current operations while learning new processes or systems. That is a qualitative explanation, not an estimate of your team's capacity. Use it as a reason to ask, not as a substitute for asking.

Before launching a pilot, name the meeting, report, approval, or obligation you propose to pause. If nothing can be removed, identify the additional resources required or reduce the pilot's scope. I wouldn't ask employees to treat “make it work” as a resource plan.

Also name what won't change. If service commitments, safety requirements, or regulatory obligations are nonnegotiable in your situation, put them in the design brief. Don't leave employees to infer which responsibilities they are allowed to compromise.

Invite employees to redesign something real

I wouldn't call a process collaborative if every meaningful decision were already closed. Before inviting feedback, specify the boundaries: here is the outcome we must pursue; here are the implementation decisions still open; here is who will make the final call.

This is where I'd apply two other principles of Do Different Things Differently: Think Inside the Box and Be Who You Aren't. Define the actual constraints, then examine the proposed change from a position other than your own.

For a hypothetical new approval workflow, invite people responsible for submitting, reviewing, and using the work to examine a sample case. Ask them to trace it from beginning to end. Where would someone wait? What information would they need? What exception would require a different route?

Give the group a bounded redesign task: propose a workflow that meets the required control without exceeding the agreed time or capacity limits. This isn't a request for unlimited ideas. It's an invitation to shape how the change will operate.

Then close the loop. Paycor recommends actually using employee feedback to revise change plans, rather than merely collecting it. That's practitioner advice, not a measured promise of adoption. My recommendation is to publish three things: what you heard, what you changed, and what you declined to change—with reasons.

Aim for the Trash Can: test a version you can discard

Aim for the Trash Can is another principle of Do Different Things Differently. Here, I'd use it to give an early implementation permission to be replaceable. The goal of a pilot shouldn't be to manufacture a success story. Set it up to help you decide what deserves to continue.

Before starting, write down:

• The question: What uncertainty is this pilot intended to resolve?
• The boundary: Which team, task, or workflow will participate, and for how long?
• The comparison: What does the current process require?
• The observations: What will you track—completion time, rework, exceptions, or added effort?
• The decision: What would justify expansion, revision, or stopping?

Choose observations that address the actual objection. If employees are concerned about duplicate work, don't evaluate the pilot only by whether they logged into the new system. Examine the duplication.

Ask participants where the pilot required extra workarounds. Before expanding, decide whether those workarounds are acceptable, need resources, or indicate a design problem. Don't quietly make them part of the permanent job.

Make trust a responsibility, not a demand

I wouldn't ask employees to demonstrate trust by withholding criticism. I'd ask leaders to make their decisions inspectable: explain the purpose, acknowledge the costs, keep stated boundaries, and return with an answer when feedback is unresolved.

James Maddox warns that threats, coercion, manipulation, and information control can worsen resistance. His comments in a University of Arkansas article are expert judgment, not a quantified comparison. My takeaway is to avoid treating pressure as a substitute for a credible implementation plan.

You can listen carefully and still decide to proceed. I'd make that decision explicit: explain which concerns the revision addresses, which trade-offs remain, and when you will review the consequences. Don't pretend disagreement has disappeared just because a decision has been made.

FAQ

How can leaders distinguish legitimate constraints from habitual objections?

Ask for the specific condition behind the objection, then examine it. A capacity concern calls for a workload review; a prediction calls for evidence or a bounded test. Avoid deciding based on whether the employee sounds enthusiastic. Evaluate the concern separately from its delivery.

Does involving employees mean giving everyone a veto?

No. I recommend defining decision rights before requesting input. Explain what is fixed, what employees can influence, and who decides. Participation should include a meaningful opportunity to revise the implementation, without implying that every preference will be adopted.

How does Tucker Bryant approach creative leadership during change?

In my speaking work, my signature keynote is Do Different Things Differently. For change adoption, I'd apply its principles to editing commitments, working within real constraints, testing replaceable versions, and considering perspectives beyond the leader's own. I'd start with making the change workable, not making the pitch louder.

If you're considering how to lead a change without treating employee concerns as something to defeat, I'd welcome a conversation. A useful place to begin: which part of your plan are you genuinely willing to revise?