How to handle a team that's resistant to process

When a design team pushes back on process, the managerial interpretation is usually that the team doesn't want structure, doesn't understand why it matters, or is being difficult. Sometimes that's true. Usually it isn't.

Resistance is often the most informative thing a team can tell you about the process you've introduced. The question is whether you're treating it as a complaint to manage or as feedback worth taking seriously.

The two kinds of resistance

There's resistance that comes from the nature of the change: unfamiliar workflows, new tools, steps that add friction before the value is visible. This kind is normal and temporary. It shows up at the beginning, decreases as people get used to it, and mostly disappears once the process starts delivering on what it promised.

Then there's resistance that comes from the process being wrong. The handoff checklist is thorough but adds half a day of work to tasks that take an afternoon. The weekly sync was designed for a team of ten and is still running on a team of three. The review gate was built to catch quality issues that haven't existed for two years. This kind doesn't get better over time. It gets louder.

The test is whether the resistance targets the process itself or specific outcomes from it. If people are complaining about the format of a doc, that's probably adjustment friction. If they're telling you the doc doesn't change anything and nobody reads it, that's a critique of whether the doc is doing anything.

What good resistance sounds like

The most useful dissent is specific. "This retrospective format doesn't work because we do it too long after the project to remember what actually happened" is actionable. "I don't like retrospectives" isn't, but it might be pointing at the same thing.

When the resistance is vague, the move is to ask what outcome they'd want from the process if it were working. That question separates people who've thought about it from people who just want less structure, and it gives you something to design against.

The designers who most actively resist process are sometimes the ones who can most clearly see what's wrong with it. They're not trying to torpedo your operating model. They've just developed a lower tolerance for theater. The meeting that could have been an email, the template that nobody fills out fully, the review that everyone attends but where nothing changes.

The manager who enforces anyway

One failure mode I've seen enough times to recognize: a manager who introduces a process, gets resistance, and doubles down. The reasoning is usually something about consistency or professionalism. If we don't hold the standard, nothing will stick.

The risk is that you end up enforcing a process that doesn't work and teaching your team that raising objections is useless. That's a more expensive outcome than having an imperfect process that the team helped shape.

There's a difference between holding a standard and defending a specific implementation. The standard might be: design reviews happen before development starts. The implementation might be: a formal presentation with a prepared deck, attendees including five stakeholders, one hour on the calendar. If people are resisting the implementation, you can defend the standard while opening the implementation for reconsideration.

How to actually fix it

The most productive path is usually to audit the process with the people who are complaining about it. Not to validate every objection, but to separate the parts that are working from the parts that aren't.

Be willing to cut things. A process that's 60% useful should be trimmed to the 60%, not preserved in full because you already agreed to it. The parts you cut communicate that the feedback mattered. That's what makes future feedback more likely.

The teams that eventually internalize good process are usually the ones that had a hand in building it. Not because co-creation is inherently valuable, but because people understand the reasoning behind choices they participated in making. When the process stops working, they know which part to change rather than scrapping the whole thing.

Resistance to process is often a team asking to be trusted with the reasoning. That's a reasonable ask.