How do you manage resistance to change within your team or organization?

Situation: At a 200-person SaaS company, we decided to move from a quarterly release cycle to continuous deployment. My team of 14 engineers had shipped on a fixed schedule for years—many saw the change as risky and unnecessary. One senior engineer was openly skeptical in meetings, and his influence was slowing adoption across the org.

Task: I was responsible for driving the adoption of the new release model. The business needed faster iteration to compete, but I couldn't force the change—I had to bring people along, especially the vocal resistors.

Action: I started by listening. In 1:1s, I asked the senior engineer what specifically worried him. He said he'd seen a previous "move fast" initiative cause production incidents and didn't want to repeat that. I validated his concern and invited him to co-design our rollout: he helped define our canary strategy, rollback criteria, and monitoring thresholds. I made him the owner of our "safety guardrails" doc, which gave him a stake in the outcome. For the broader team, I ran a series of "what could go wrong?" sessions where we surfaced fears and addressed them in our plan. I also created quick wins—we shipped one low-risk feature via CD in the first month and celebrated the reduced cycle time. I communicated the "why" in every all-hands and tied it to customer feedback we'd received about slow feature delivery.

Result: Within four months, we were deploying multiple times per day. The former resistor became one of our strongest advocates and later led our CD best-practices guild. Team satisfaction scores on "confidence in our release process" went from 3.2 to 4.5 (out of 5). I learned that resistance often masks valid concerns—involving people in the solution turns skeptics into owners.