How to Drive Organizational Change in a Professional Services Team

Most organizational change programs in professional services fail before implementation starts.

A tool gets selected, a rollout plan gets built, and the team gets notified. Then adoption lags, processes fragment, and six months later, you're debugging the same problems on a different platform. 

The issue usually isn't execution. It's that the real problem was never clearly defined before the solution was chosen.

At Propel 26, Kristin, PS Program Manager at Submittable, and Whitney Eskenazi, Manager of Implementation Services at LogicGate, joined moderator Happy Luther, CEO of Zinger Consulting, to share what they've learned driving change inside their own PS organizations. 

Their message was clear: successful change management in professional services starts with curiosity, cross-functional ownership, and accountability that survives beyond the rollout.

How Do You Identify the Real Problem in a PS Change Initiative?

Kristin was two months from the end of a software contract when her company decided to migrate to Rocketlane, their new system of record for delivery. She thought it would be manageable: a tool transition, some process updates, and a few automations she could repurpose.

Then she started talking to people.

"I thought I knew the problem and I don't know the problem," she said.

Two years earlier, her company had gone through a merger. What had been one software product was now four. Multiple teams were implementing multiple platforms with no shared structure, no consistent ownership, and no unified process. 

The scope of the migration exploded, not because Rocketlane was complex, but because the organizational structure underneath the work had never been fully mapped.

This is where many PS change initiatives fail. Teams optimize for a problem that was defined too quickly. The presenting issue may be a tool migration, a handoff process, or a workflow redesign. But underneath it might be fragmented ownership, unclear accountability, or teams operating from completely different assumptions about what "good" looks like.

Happy Luther pushed on the importance of connecting people to the why. Not just why leadership wants the change, but why the people living through it should care. Kristin's answer was to lead with curiosity instead of conviction: test assumptions, ask better questions, and give people space to respond differently than they have in the past.

Whitney added a broader frame: every PS organization is already inside a change, whether it has named it or not. AI is becoming a new team member, customer expectations are shifting, and services teams are being asked to do more with more visibility and less tolerance for ambiguity. The question isn't whether change is happening. It's whether you're designing it or just reacting to it.

What's the Cross-Functional Committee Model for Change Management?

Once Kristin understood the real scope of the problem, she started with individual interviews to capture pain points one by one. Then she brought those same people together and let them hear each other's frustrations directly instead of translating every issue herself.

That became the foundation for a cross-functional committee called the Handoff Heroes. The group included sales, customer success, professional services, support, product marketing, and revenue operations: every team that touched the buyer and customer journey. 

They meet every six weeks, and the first session was essentially a structured brain dump. The value was immediate. Some team members genuinely didn't know what adjacent teams were experiencing.

"We're taking the whale and choosing which parts to tackle one bite at a time," Kristin said.

Whitney built a similar model at LogicGate. Weekly Rocketlane reviews still include individual contributors, not just leadership, because ground-level feedback is what surfaces where process is adding administrative overhead instead of creating customer value. 

Her guiding question is simple: we don't want to add admin work to your plate, so tell us where you're getting stuck.

Both approaches share a design principle that's easy to underestimate: change built with the people it affects tends to stick. Change handed down to them usually doesn't. That's not just about buy-in. It's about access to the information you need to make the change work.

This is also where a platform like Rocketlane becomes critical. When teams migrated to Rocketlane, they weren't just swapping tools. They were codifying the handoff workflows, accountability checkpoints, and cross-functional visibility their committees had designed. The platform gave them a place to operationalize what they had learned together.

Why Accountability Matters More Than Documentation

You can run an inclusive process, build a cross-functional committee, and document every decision—and still watch a change program fall apart. The gap between agreement and execution is accountability.

Whitney put it directly: "You can have all of the documentation you want. You can get agreement. But holding each other accountable—that's the linchpin."

The challenge is structural. When a committee spans sales, CS, PS, and rev ops, it inherits every power dynamic in the organization. Holding an individual contributor accountable for a process they helped design is one thing. Holding a VP to the same standard is a different conversation.

Kristin's approach treats the feedback loop itself as the accountability mechanism. Nothing is set in stone. Processes get revised and refined continuously. But the only way to improve them is to see what's actually happening, not through manual reports at the end of the week, but through a shared operating system where project status, implementation data, and ownership signals are visible as work unfolds.

When data flows continuously into a single system of record, the team can see what's working and what's not without relying on memory or status chasing. 

The feedback loop runs whether people remember to report or not. The system itself becomes part of the accountability mechanism.

That matters because accountability cannot depend entirely on meetings. It has to be built into how work moves.

How Can Data Support Change Management in Professional Services?

Data plays a supporting role in change management, but a critical one.

Whitney described the early days of flying blind, trying to convince leadership that a problem existed without clear numbers behind her. Once implementation data was systematized in Rocketlane, the conversation changed. She could show implementation length trends, time-to-first-value improvements, and the downstream renewal impact of a better onboarding experience.

The difference wasn't just better reporting. It was continuous visibility. Instead of waiting for someone to explain what was happening, leaders could see where friction existed and where process changes were creating measurable improvement.

Kristin described data slightly differently. For her, it was often defensive. When edge-case objections threatened to derail a decision the group had already reached, data helped bring the conversation back to the pattern rather than the exception.

Both uses matter. Data can prove that change is needed, and it can prevent isolated anecdotes from overpowering collective progress. In PS change management, the best data doesn't replace judgment. It keeps judgment grounded.

4 Key Takeaways on Driving Organizational Change in PS Teams

Start with Curiosity, Not Conclusions

The real problem is often bigger than the presenting problem. A tool migration may reveal a handoff issue. A handoff issue may reveal an ownership issue. Test assumptions before building a solution around them.

Build the Full Cross-Functional Table

Don't shortcut the committee. Sales, CS, PS, support, rev ops, and product-adjacent teams all see different parts of the customer journey. The teams you're tempted to skip often hold the context you need most.

Make Accountability Operational

Agreement and documentation are not enough. Accountability needs a mechanism: clear ownership, visible workflows, shared data, and a system that surfaces drift before it becomes normalized.

Use Data to Keep Change Grounded

Data can help prove need, track progress, and neutralize edge-case objections. The most useful implementation data is connected to business outcomes like time-to-value, customer experience, and renewal impact.

Conclusion

Organizational change in professional services fails when leaders lead with the solution instead of the problem.

Kristin and Whitney's shared lesson is that the practitioners who drive change well are the ones who discover what they don't know before they start solving. 

They build committees that outlast the initial rollout, treat process revision as an ongoing operating model, and hold the line on accountability even when the power dynamics make it uncomfortable.

The discipline underneath tools is what makes change stick. And the right system of record—one purpose-built for how services work—makes that discipline sustainable. It enforces playbooks, surfaces risks before they compound, and keeps teams accountable without constant manual chasing.

The tools will keep changing.

The teams that succeed will be the ones that build the operating discipline to change with them.