Effective Change Management: Secrets to Boost Velocity and Secure Buy-In

In enterprise software, cultural friction is often more responsible for suboptimal performance than technical barriers. In my experience of implementing projects aimed at speeding up operations when changing from legacy ERP systems to cloud-native applications, I’ve always been applying the model of recognizing and enabling Internal Champions prior to the project being rolled out. Being involved in various global manufacturing and distribution projects, it has been clear to me that there are informal opinion leaders in every department, even though they might be invisible on the organizational chart. These people are the ones to whom their colleagues turn for help when something goes wrong in the current system or the workflow is jammed.

I find it valuable to involve these champions in the initial design phase of the project. Instead of handing them a finished product during the training phase of the project, I ask them to perform rigorous tests on the products and figure out where the solution does not correspond to operational reality. This allows us to address whatever issues arise in the early stages of the project, when changes are still possible. When we reach the implementation phase of the project, such key people transform from doubters to supporters.

The reason why this is so effective is that peer-to-peer advocacy spreads much faster than top-down management instructions. If, for example, a warehouse manager or a procurement officer tells his/her team that he/she has tested the new software and it works, this completely eliminates any resistance. Real velocity in the implementation of the system occurs not when the software is launched but when everyone is ready to use the newly implemented solution.

Change management cannot be treated as an exercise in logistics. I, for one, approach it as a trust exercise instead. To be honest, no one would resist speed in itself. If there is resistance, it would be because there is limited understanding of the rationale behind the velocity boost. It is the ‘why’ that needs to be visible before rolling out any design intended to move faster. The effect is that when the implementation takes place, they know how to explain it. This in turn proves much more effective than having leadership recite it.

Over-communicating in isolation doesn’t sound very palatable. But if there is a rollout, it is important to repeatedly communicate the reason behind it. Again, it boils down to owning processes which would only come from understanding. Imposing new processes never helps sustain the velocity gain beyond the initial weeks. The shared understanding tends to hold buy-ins most effectively.

The mistake I see most with velocity initiatives is rolling them out as a company-wide mandate on day one — that’s precisely when you get the most pushback, because teams feel a new process is being imposed before anyone has proven it works. What’s worked for us instead is treating the first rollout as a self-contained pilot with its own before-and-after numbers, then letting that team make the case to the next one. On a recent healthtech integration project, we replaced a from-scratch, 16–20-week onboarding process with a repeatable framework that got each new clinical site live in 3–5 weeks — and the site that went first became the internal reference point, not something leadership had to sell.

The technique that mattered most was making that pilot team’s results visible to whoever was next in line. Nobody adopts a faster process because they’re told it’s faster. They adopt it when they see a peer team’s actual numbers and start asking when they get the same tooling — that’s a completely different conversation than “why are we changing this.”

The mistake I try to avoid is announcing a speed initiative as a target. If the message people hear is that leadership wants more output, the honest response from a good team is defensiveness, because they know where the actual friction is and they know it is mostly not effort. So I start by asking what slows them down, and then I fix something on that list before asking for anything in return. Removing a genuine blocker buys you more credibility than any amount of explaining why velocity matters.

The technique that worked best was letting the team pick the first change themselves. We gave the problem rather than the solution, which was that a particular cycle was taking too long, and let the people doing the work decide where to start. Buy-in was not something we had to negotiate afterwards, because it was their idea. It also tends to produce a better first move, since the people closest to the work usually know which bottleneck is real and which one just looks bad on a dashboard.

When we’ve introduced changes at Zibtek, I’ve learned that people usually aren’t resisting the change itself. They’re resisting a change they don’t understand or one that looks like it will make their work harder. So before rolling something out to the whole team, I like to get the people doing the work involved early and let them point out where the new approach doesn’t fit what actually happens day to day.

One technique that has worked particularly well for us is testing the change with a small group first. We can see where people get stuck, fix the parts that aren’t working, and then show the rest of the team what we changed based on that feedback. That makes the rollout feel less like something being handed down to them. It also gives the team a chance to see whether the change actually saves time before they’re expected to adopt it. I’ve found that this kind of proof gets much better buy-in than trying to convince people with a presentation about how much more efficient the new process is supposed to be.

Cache Merrill

Founder, Zibtek

Salt Lake City, Utah

https://www.zibtek.com

We treated change management to boost velocity as if we were updating software. We used a 30-day-long beta test with a definitive expiration date. The team takes a vote on the change at the end of 30 days, and if they decide to terminate, it’s gone. However, this technique inevitably turns into a negotiation over the velocity-boosting measures, where solutions to issues are provided, the changes evolve, and you achieve the same result. The temporary nature of this approach makes it palatable for everyone.

Another excellent technique for change management to boost velocity is rolling out small changes periodically. Baby steps. I find this more effective than the beta test overhaul. Each small change garners feedback and improves before the next is introduced. People can’t accept huge changes all at once. Baby steps.

You’ve probably heard this advice a million times, but change is hard for people to accept, especially when it involves switching something they already know how to use. That’s the exact resistance we run into with customers considering a move to us. Most of them have years of history sitting with their old provider, and the idea of moving all of it feels like it could cost a fortune before they’d even seen the benefit.

So instead of asking customers to trust us on faith, we removed the financial risk entirely. When someone signs an annual contract, we bring over their past history for free. Since we run on usage-based pricing, that means a customer only pays going forward, not for everything they’re bringing over from before. In my experience, that one change did more to speed up adoption than any sales pitch could have. Customers stopped worrying about the bill and started focusing on whether the product actually helped them.

One consideration for other business owners pushing a velocity-boosting initiative is to find whatever is making the change feel expensive or risky to the other side, and remove that first. People rarely resist the initiative itself. They resist the uncertainty around it.

Every initiative we bring in comes with something the team retires, and they choose what goes. That one rule did more for buy-in than any explanation of the benefits ever did.

It works because engineers hear a new practice as an addition to a week that is already full. Automated checks, an extra review step, a written decision record—each is reasonable on its own, and the total is what people are pushing back against. When the change arrives as a trade, the conversation moves to which of the current rituals is still earning its place, and the team is far better placed to answer that than I am.

It keeps me honest as well. If I cannot find anything worth dropping to make room, the idea probably was not worth interrupting a delivery cycle for.

When implementing initiatives to increase velocity, I avoid presenting them as top-down management decisions. Buy-in is strongest when those closest to the work help shape the implementation.

A successful approach involved forming a small pilot group from the affected teams. We provided the new workflow, asked them to identify friction points, and incorporated their feedback before a broader rollout.

This approach was effective because the team saw the goal was not to impose another process. Their practical experience directly shaped the final version.

It also created internal advocates as the initiative expanded. Employees who used the new process could explain its benefits and describe their role in refining it.

I learned this while helping build UiPath’s go-to-market motion for agentic automation.

The resistance wasn’t really about the new approach. People were protecting a process they already knew how to run. Sales had playbooks that had worked. Marketing had messaging that was landing. Asking people to change those things meant asking them to give up something they trusted.

I stopped trying to sell the new process.

Instead, in buy-in conversations, I started walking through what the existing motion was costing us in time and margin. How many hours were tied up in the old handoffs? Where were people doing work because the process had always worked that way?

That changed the conversation. People were much more willing to question a familiar process once they had put a cost on keeping it.

The useful lesson for me was that change management isn’t always about getting people excited about what’s new. Sometimes you have to make the cost of staying put visible enough that people are willing to reconsider something they already trust.

Kuber Sharma

Sr. Director, Product Marketing, UiPath

When we implement velocity focused initiatives, we treat change management as a sequencing problem rather than a communication problem. Most teams do not struggle because they dislike change. They struggle when too many changes arrive at once and clash with existing habits. We reduce the surface area by isolating one decision path, simplifying it, and removing an approval layer.

We then document the old and new process in plain language so the difference is easy to understand. This creates momentum without causing organizational fatigue. People do not need to adopt a new philosophy overnight. They can start with a simpler system, see the benefit, and build confidence before we expand the change further.

Speed improves when ownership stays clear

When I introduce a change meant to increase delivery speed, I do not begin with a company-wide announcement. I begin with one real workflow, the people who do it, and a clear description of what is slowing them down.

At VoiceAIWrapper, our team of 12 has been shifting routine manual tasks toward large language models. The useful change was not telling everyone to use more AI. It was asking team members to identify repetitive work, describe the risk of automating it, and propose a small version they could test and review.

The technique that produced the strongest buy-in was employee-owned pilots. The person closest to the task helped design the new process, chose the boundary, and remained responsible for checking the output. This changed the conversation from “management wants a new tool” to “we are fixing a problem I deal with.”

Each pilot had a simple frame. What happens today? Which step creates delay or rework? What part can change without putting a customer at risk? What would make us stop the test?

I also kept the first demonstration concrete. Instead of presenting a broad transformation plan, we compared the old and proposed workflow on the same type of task. The team could see where judgment was still required, where the model saved preparation work, and where checking the output created new work.

That visibility helped with resistance. People did not have to accept a promise about future productivity. They could challenge the process in front of them. Their objections improved the instructions, clarified ownership, and exposed cases the original idea had missed.

Once the pilot was stable, the owner documented the process in plain language and another teammate tried it. If the second person could not follow it, the change was not ready to spread. This prevented speed from depending on one enthusiastic operator.

The downside is that pilots create temporary duplication. The old and new methods may run together, and a careful rollout can look slower at first. I accept that cost because forced adoption hides problems until they become normal work.

Change moves faster when the team owns the test, understands the boundary, and can stop what is not working. Buy-in grows from evidence and control, not from a louder announcement.

When we changed engineering process to improve velocity, I framed the rollout around delivery risk first. A new checklist only earned attention when the team could see which delay, rework loop, or release failure it was meant to remove.

The technique that worked best was to attach each process change to a visible risk in the team’s normal workflow. For example, we separate technical debt by urgency: if it’s slowing the current task, we reduce it immediately; if it threatens upcoming work, we plan it; if the risk is only theoretical, it waits. Small debt is fixed inside the task or during code review, while larger debt becomes a backlog item owned by the project manager or tech lead. Debt triage gives people a practical way to decide what deserves time.

We used the same logic in review and validation. A merge request stays part of in-progress work, so review time is budgeted into the task from the start. Our bots post a checklist into every new merge request and flag oversized changes. Before a task goes to validation, the developer has to run the ticket scenario in the dev environment and attach evidence, such as a screenshot or a screen recording. During the rollout, review and validation stayed inside the task before it left development.

For buy-in, I started with an oversized branch as the single failure mode. Review slowed down, context got lost, and the team discovered risk later than it should. The change gave leads an earlier signal for intervention while the work was still small enough to review properly.

Adopting AI across the business has boosted our efficiency, but getting there required as much cultural work as technical implementation.

The hesitancy people feel around AI tends to come from a fear of losing creative control or autonomy, a worry that AI will direct them rather than the other way around. So we focused on showing people what was possible through sessions with professional AI coaches and regular knowledge sharing, where employees could demonstrate to each other how they were using it.

A good example of AI-utilisation came from an employee who built an agent using ChatGPT to manage an inbox receiving thousands of emails each month, automatically selecting the right response from a list of pre-approved templates and saving hours of manual work every week.

This is the sort of efficiency gain that other employees see and are inspired to replicate because it takes away a large manual process and allows them to focus their efforts on other projects.

By changing mindsets from ‘AI as a potential threat’, to ‘AI as customisable support’, the whole team can move more efficiently and the business can grow at a faster rate.

One technique I have found particularly effective is involving stakeholders early enough to identify what must not be disrupted, not just what needs to become faster. Change initiatives often lose buy-in because leaders focus entirely on the upside of the new process while employees or customers are worried about losing something that already works.

In complex B2B environments, our approach is to establish continuity first. What do stakeholders value about the current experience? Where is the genuine friction? Which handoffs or decisions could become faster without sacrificing communication, support, or visibility? Once those questions are clear, the change feels less like something being imposed and more like a specific problem being solved.

That creates buy-in because people can see both sides of the equation: what will improve and what will be protected. Speed is valuable, but velocity that introduces confusion, weakens relationships, or creates new rework is not really an improvement.

When I’m brought in for velocity-boosting initiatives, I don’t start with process maps. I start with defining value, because you can’t fix flow if the org doesn’t agree on what should be flowing.

Here’s an example: I worked with a publishing group on value stream mapping, and the first session wasn’t about the process at all. It was about defining value. That single question opened up a lot of conversation, because different parts of the org were defining value differently, and targeting different personas without realizing it. Editorial saw value one way, distribution saw it another way, and neither had been named out loud before.

That gap was the real finding. Once we surfaced it, we could align the org around a shared definition of value, and only then did the process mapping make sense. The waste points we found afterward weren’t my judgment call; they were departures from something the whole group had already agreed on.

The technique that worked best for buy-in: get the definition of value on the table before you touch the process. Translating value across departments is crucial to being able to deliver value.