Making Changes That Stick

You’ve assessed the operation. You’ve identified the gaps. You’ve started building the systems—documentation, workflows, ownership structures, tool configurations. And now you’re about to hit the part where most PMC improvement initiatives quietly die.

Not because the systems are wrong. Not because the team is incapable. But because nobody managed the transition between the old way and the new way. The systems were built, the training was scheduled, the rollout was announced—and three months later, half the team is using workarounds, a quarter is doing things the old way, and leadership is frustrated that nobody uses the system they invested in.

If this sounds familiar, you’re not alone. It’s the norm in property management, not the exception. And the instinct is usually to blame the tool or blame the team. The tool wasn’t the right fit. The team is resistant to change. The training wasn’t good enough. But in most cases, the tool was fine, the team was capable, and the training covered the features. What failed was the space between “here’s the new system” and “this is now how we work.”

I’ve led technology rollouts and process changes across a portfolio of more than 200 multifamily properties. I’ve been the pilot site for new products, the person who designed the training, the administrator who configured the system, and the help desk that fielded the calls when things didn’t work. I’ve seen rollouts achieve full adoption and I’ve seen rollouts that were functionally dead within weeks. The difference was never the technology. It was always whether someone managed the human side of the change.

Training is not adoption

This is the core misconception that kills most PMC rollouts. Leadership treats the training session as the implementation milestone. Training happened, therefore the system is implemented. But training and adoption are completely different things. A Deloitte survey of real estate firms found that 70% increased their technology investment post-pandemic—but only 28% had a formal training program in place to support it.¹ The industry is spending on tools and skipping the human side of making those tools work.

I’ve led enough training sessions to know what the nodding means—and what it doesn’t. You walk through the new process, you ask if everyone understands, and you get a room full of nods. But if you keep pushing—if you pause and ask specific questions, if you walk back through a step and ask someone to explain it back to you—there’s almost always one person who eventually admits they didn’t understand something way back at step two. And the moment they say it, the floodgates open. Suddenly everyone has questions. The nodding wasn’t understanding. It was social pressure—nobody wants to be the one who slows down the group or admits they’re lost.

And even when the training goes well—even when the questions do come out and get answered—the real test isn’t the training room. It’s Tuesday morning when your team goes back to their desks and tries to do the work. That’s when the questions come in. That’s when the confusion surfaces. That’s when the gap between “I understood the demo” and “I can do this on my own with a resident on the phone” becomes real.

Training tells people how the system works—where the buttons are, what the fields mean, how to generate a report. It’s necessary but wildly insufficient. Let me show you what I mean.

Say your company is switching to a new work order management system. Your maintenance coordinator, Maria, has been using the old system for three years. She’s fast with it. She knows every screen, every shortcut, every workaround for the things it doesn’t do well. She has a personal system—a spreadsheet she maintains alongside the platform—that tracks vendor response times because the old system doesn’t report on that.

Training shows Maria where the buttons are in the new system. Here’s what it doesn’t address:

Why she should change. Maria needs to hear that the new system routes work orders directly to vendors without her copying details into a text message—something she does fifteen times a day. She needs to hear that it tracks vendor response times natively, which means the spreadsheet she maintains manually every week becomes unnecessary. If instead she hears, “the new system has better reporting for leadership,” she has no reason to care. The reason to change has to solve her problem, not leadership’s.

This is true for every role in the rollout—the leasing agent needs to hear how the new CRM eliminates the manual follow-up tracking that eats an hour of her morning, not how it improves pipeline visibility for the regional. The reason to change has to connect to a pain point the person doing the work actually experiences.

What happens to her daily workflow. Maria currently checks the old system first thing in the morning, triages the overnight requests, texts the vendors, and updates her spreadsheet. That routine took her three years to build and it works. The new system doesn’t exist in a vacuum—it lands in the middle of routines your team has built over months or years. Nobody has mapped how the new system changes Maria’s morning—what she checks first, how the triage works, whether the vendor notifications are automatic or whether she still needs to initiate them. Without that mapping, Maria’s first morning on the new system is confusion, and her second morning is a decision about whether to keep trying or revert to what she knows.

What she loses. Maria was an expert in the old system. She was the person other coordinators called when they had questions. She was fast, confident, and competent. On day one of the new system, she’s none of those things. Every change involves giving something up—a familiar process, a personal system that worked, a sense of competence. That loss of identity—from expert to beginner—is real and it’s painful, and no amount of “this will be better eventually” addresses the fact that right now, today, she’s slower and less confident than she was yesterday. If nobody acknowledges that loss or provides a bridge, the natural response is to revert.

If your rollout plan accounts for all three of these—Maria’s motivation, Maria’s workflow, and Maria’s loss—adoption becomes dramatically more likely. If it only covers where the buttons are, Maria will smile through the training and be back on her spreadsheet by Thursday.

Why your team resists (and why they’re not wrong)

Resistance to change in property management gets labeled as a people problem: the team is stuck in their ways, they’re not tech-savvy, they don’t want to learn something new. But resistance is almost always a rational response to real experience. Your team isn’t resistant to change in the abstract. They’re resistant to this specific change, based on what they’ve seen before.

They’ve been through “the new thing” before. Most PMC teams have lived through at least one—often several—failed rollouts. The new software that was supposed to change everything and was abandoned six months later. The new process that lasted until the owner got busy and stopped enforcing it. Every failed change erodes trust in the next one. When your team hears, “we’re switching to a new system,” their internal response is, “again?”—and they conserve energy by waiting to see if this one sticks before investing in learning it.

Their workarounds exist for a reason. The spreadsheet, the text group, the sticky note system, the personal checklist—these aren’t signs of incompetence. They’re signs that the existing tools didn’t meet their needs, so they built something that did. Dismissing those workarounds as “the wrong way to do it” dismisses the operational intelligence behind them. A better approach: understand what the workaround solves and make sure the new system solves it too.

They’re being asked to slow down while being held accountable for speed. Learning a new system takes time. During the transition, everything takes longer—tasks that should take five minutes take thirty minutes or an hour because you’re learning a new interface, figuring out where things moved, and discovering that the workflow you had memorized now requires different steps in a different order. But nobody reduces the workload during the rollout—you’re still expected to lease units, respond to residents, process renewals, and coordinate maintenance at the same pace. The new system is additional cognitive load on top of existing work, at least temporarily. That’s a legitimate burden, and pretending it doesn’t exist doesn’t make it go away.

They weren’t asked. The decision to change systems was made by leadership, often without consulting the people who’ll use it daily. The property manager who could have told you that the new CRM doesn’t handle their specific renewal workflow wasn’t in the evaluation. The maintenance coordinator who could have flagged that the new work order system doesn’t account for after-hours emergency routing wasn’t asked. When people aren’t included in the decision, they don’t own the outcome—and ownership is what drives adoption.

What actually drives adoption

Here’s what I’ve learned leading rollouts across a portfolio of 200+ properties. These aren’t theoretical principles—they’re what I’ve seen work, repeatedly, across different teams, different tools, and different levels of initial resistance.

Design around the workflow, not the feature. Don’t train on what the button does. Map the daily task and show how the new system fits into the way work already flows. Better yet, redesign the workflow so the system makes the job genuinely easier—fewer clicks, fewer handoffs, less manual entry. When I configure a new platform, I start by shadowing the team: what do they do from 8 AM to 5 PM, in what order, using what tools? Then I configure the system to match that flow, not the other way around. Training becomes, “here’s how your morning routine works now,” instead of, “here’s what this menu does.”

Solve a problem they feel. If the change doesn’t address a pain point the frontline actually experiences, adoption will be compliance-driven at best—people will use it because they have to, not because it helps. Find the daily frustration the new system eliminates and lead with that. “This CRM replaces the manual follow-up tracking that eats an hour of your morning” is a reason to change. “Leadership needs better pipeline visibility” is not—at least not for the person being asked to change their workflow.

Make the old way harder than the new way. Not punitively—structurally. When the new process is genuinely faster, easier, or less error-prone than the workaround, people switch because it’s in their interest. If the new system requires more steps than the spreadsheet it replaced, the spreadsheet will survive. That’s not resistance—it’s rational behavior. If people aren’t adopting, the first question should be, “is the new way actually easier?” not, “why won’t they change?”

Close the loop visibly. When someone reports a problem with the new system and you fix it, tell them. When feedback leads to a configuration change, announce it. When a suggestion from a property manager shapes how the tool works, credit them. The fastest way to kill adoption is silence after complaints—it teaches the team that feedback goes nowhere, so they stop giving it and start working around the problems instead. The fastest way to build adoption is showing that input leads to action. This is the same principle from Chapter 2’s listening sessions, applied to the rollout context: every time you close a feedback loop visibly, you’re building the trust that makes the next change easier.

Support through the valley. Every rollout has a valley—the period after go-live when the new system is live but the team isn’t fluent yet. Everything takes longer. Frustration peaks. This is when rollouts die, because leadership sees “the training is done” and moves on to other priorities while the team is still struggling. The support during this valley—on-the-ground help, quick responses to questions, visible presence from whoever owns the rollout—is what carries adoption through to the other side. Pull support too early and the team reverts.

I know this from personal experience—not as the person managing the rollout, but as the person living through it. I piloted a major new suite of property management software—and I want to be clear, I wanted to pilot it. I’ve always been a power user. I’m not an IT person; I’m a property manager who happens to care deeply about the tools I use. I knew there would be challenges going in. I volunteered for this.

Even so, the transition nearly broke me. Tasks I could do in five minutes on the old system took thirty minutes or an hour on the new one. The training covered the basics but not the edge cases that make up half of actual property management work. I was figuring things out alone, working directly with the software provider because internal support had moved on, and falling behind on my actual job while I muddled through the learning curve. There was a stretch where I seriously considered quitting—not because the software was bad, but because the experience of using it without adequate support was so frustrating that it overshadowed every other part of the job.

I stuck it out because I’d volunteered. I knew what I was getting into. I was invested in making it work. Now imagine your property manager who didn’t volunteer—who showed up on Monday and was told, “we’re switching systems.” Who doesn’t consider themselves a power user. Who’s just trying to do their job. For that person, the valley isn’t a challenge they signed up for. It’s a disruption imposed on them. And the frustration hits harder, the patience runs shorter, and the threshold for giving up is much, much lower.

That experience is why I’m so insistent about the pilot methodology and the valley support. I’ve been the person in the valley. I know what it feels like when leadership has moved on and you’re still struggling. And I know that the difference between a rollout that sticks and one that fails is almost never the technology. It’s whether someone was there to help when the frustration peaked.

And here’s the connection to Chapter 1 that most leadership doesn’t make: failed rollouts are a turnover accelerant. Every botched implementation adds weight to the cumulative burden your team carries. It’s one more thing that was supposed to make their jobs easier and didn’t. One more reason to believe that nothing here ever actually changes. The property manager who’s already frustrated by the lack of documentation and the scattered communication now has a half-adopted CRM added to her list of systems that don’t work. She doesn’t file a complaint. She updates her resume. The cost of the failed rollout isn’t just the software license—it’s the person you lose because it was the last straw.

The pilot: the step most PMCs skip

If I could change one thing about how property management companies handle rollouts, it would be this: pilot everything.

I’ve been the pilot site for major product rollouts for most of my career—and I don’t mean I was assigned to it. I volunteered. Every time. I’m the person who raises their hand when the company is evaluating a new system, because I’d rather be in the room shaping how it gets implemented than receiving a finished rollout that doesn’t match how the work actually gets done. I’ve tested new property management platforms, new communication tools, new workflow systems, and new AI features—usually as the only property in the portfolio running the new system while everyone else is still on the old one.

That experience has taught me something most leadership doesn’t see: when you’re the pilot site, you’re often on your own. The implementation team configures the basics and moves on to the next client. Your company’s leadership checks the “pilot launched” box and shifts attention to other priorities. And you’re left figuring things out—calling the software provider directly when something breaks, working through edge cases nobody anticipated, and discovering that the workflow that looked clean in the demo falls apart when a real resident calls with a real problem the system wasn’t designed for.

I’ve spent hours working directly with software providers—not just reporting bugs, but explaining how the tool needs to work in a real operation, requesting feature enhancements, and making the case that the change isn’t just for my property but for every customer using their product. I’ve never been afraid to ask for what I want from a vendor, and I’ve learned that the providers who listen to frontline users build better products than the ones who only listen to purchasing committees. That direct relationship between the person using the tool and the people building it is one of the most undervalued dynamics in property management technology—and it only happens at the pilot site.

I share all of this because it illustrates what a pilot actually requires: not just a property willing to test the system, but someone willing to invest the time, provide honest feedback, and work through the problems instead of abandoning the tool when it doesn’t work perfectly on day one. A pilot does four things that a companywide launch cannot.

It catches the problems real users find. No matter how well a system is configured, real-world use reveals gaps that testing can’t. The workflow that makes sense in a demo breaks when a resident calls with a situation the system wasn’t designed for. The form that looks complete is missing a field the team needs daily. The automation that should save time actually creates a bottleneck because it triggers at the wrong point in the process. A pilot catches these at one property instead of creating them at every property simultaneously.

It produces a rollout that works, not just a rollout that launches. After a pilot, you don’t have a theoretical implementation—you have a tested one. The configuration has been adjusted based on real feedback. The training materials reflect actual workflows, not assumed ones. The FAQ addresses real questions, not anticipated ones.

It builds internal champions. The pilot team becomes your best asset for the broader rollout. They’ve used the system. They’ve shaped it. They can tell their peers, “I had the same concern, and here’s how it actually works.” Peer credibility is more powerful than any training session—a property manager who trusts another property manager’s experience will adopt faster than one who’s told to adopt by leadership.

It limits blast radius. When a rollout has problems—and they all do—a pilot contains those problems to one property. The team there works through them with close support. A companywide launch puts those same problems on every manager’s desk at the same time, with diluted support, and the collective frustration can poison the rollout permanently. I’ve seen a single bad companywide launch create years of resistance to the next change, because the team remembers how the last one went.

On the occasions when a company skips the pilot and pushes a change across the entire portfolio at once, the result is almost universally the same: the “oh crap” moment. The kinks that a pilot would have caught in a controlled environment are now hitting every property simultaneously. The settings aren’t dialed in for how the company actually does business. The team implementing the change didn’t fully understand every place the process could break—because you can’t understand that from a demo or a test environment.

You can only understand it when a real property manager tries to process a real application at 4:45 PM on a Friday with an applicant on the phone. That kind of discovery is fine when you’re testing with one property and the company’s full support behind you. It’s a different thing entirely when every manager in the portfolio is pulling out their hair and the company is scrambling to support and respond to dozens of frustrated users at once—with no capacity to fix the underlying problems because the support team is buried in individual troubleshooting.

The objection is always time: “we don’t have time to pilot, we need this rolled out now.” But a 30-to-90-day pilot—and yes, most pilots need at least that long, except for the simplest of changes; complex switches like full back-end property management or accounting systems may need even longer—that prevents a failed companywide launch doesn’t cost time. It saves months of remediation, retraining, and the slow work of rebuilding trust with a team that watched the last rollout crash.

The rollout timeline

If you’re planning a technology rollout or major process change, here’s a practical timeline that accounts for the human side. The total duration will vary based on complexity—a straightforward process change can move through these phases in 90 days, while a full platform migration may take six months or longer. The phases are the same regardless of scale. (This is different from the broader 90-day operational plan in Chapter 7—this timeline is specific to managing a single change initiative.)

Weeks 1–2: Map the current state. Before you configure anything, understand how work actually flows today. Shadow your team. Document their real workflows, not the ones in the handbook. Identify the pain points the change should address—from their perspective, not just leadership’s. Select your pilot property or team based on who’ll give you the most honest feedback, not who’s most compliant.

Weeks 3–8+: Pilot. Deploy the new system or process at one property with close support. Be present. Watch how people actually interact with it. Document every friction point, every question, every workaround that emerges. Adjust the configuration, the workflow, and the training materials based on what you learn. The pilot isn’t a formality—it’s where the real implementation happens.

For a straightforward process change, 30 days may be sufficient. For a new software platform, plan on 60 to 90 days at minimum. For a full back-end property management or accounting system, the pilot may extend well beyond 90 days—and that’s appropriate. The pilot should run long enough to encounter the full range of real-world scenarios: month-end processing, lease renewals, move-outs, seasonal maintenance cycles, and the edge cases that only surface when you’re operating in the system day after day. Ending a pilot early to meet an artificial deadline is how you push unfinished implementations to the entire portfolio.

After the pilot: Phased rollout. Expand to the broader team in groups, not all at once. Lead with the problem the system solves. Train on the workflow, not the features. Provide on-the-ground support—not a link to a training video, but a person who can answer questions in real time during the first week at each new property. Use your pilot team as peer champions.

Ongoing: Measure and reinforce. Track adoption—not just logins, but actual usage patterns. Are people using the new workflow or reverting to the old one? Where are the holdouts, and what are their specific reasons? Almost always, the holdouts are pointing to a design problem that everyone else is tolerating silently. Fix it, announce the fix, and adoption accelerates. Celebrate the wins visibly: faster response times, fewer errors, time recovered, problems caught earlier.

When the change is bigger than a tool

Everything in this chapter applies to technology rollouts, but the principles are identical for any operational change—a restructured team, a new workflow, a shift in how properties are managed, or even the kind of comprehensive operational overhaul that the Assess and Build phases of this book describe.

The stakes get higher when the change is organizational rather than technical. A new regional manager restructuring how properties are grouped. A merger that combines two companies with different cultures and different systems. A succession where the founder is stepping back and the next generation is stepping in. An acquisition where the acquiring company needs to integrate a portfolio that was run entirely on one person’s institutional knowledge. These are change management challenges at a scale that dwarfs a software rollout—and the principles are the same.

People need to understand why the change is happening, how it affects their daily work, and what’s in it for them. The transition needs to be managed, not just announced. The feedback loops need to be open and visible.

If you’re navigating one of these larger transitions—and if you read the Introduction’s section on who this book is for, you know this is a growing audience—the change management discipline described in this chapter isn’t optional. It’s the difference between a transition that preserves operational value and one that destroys it. The documented knowledge from Chapter 3 gives you something transferable. The change management practices from this chapter give you the ability to transfer it without the operation falling apart in the process.

The scale changes. The dynamics don’t.

If your company has been through failed changes before—and most PMCs have—the trust deficit is real. Your team remembers. The person who led the last failed change isn’t necessarily the best person to lead the next one, not because they’re not capable, but because the team’s trust is already spent. Sometimes a fresh voice, whether internal or external, resets the dynamic.

And if your internal team is already at capacity—which is almost always the case in mid-size PMCs—adding “manage a companywide rollout” on top of their existing workload is how rollouts get half-done. The pilot gets skipped. The workflow mapping doesn’t happen. The training covers features instead of tasks. The support disappears after week one. Everything that makes change management work gets cut because nobody has the bandwidth to do it properly.

This isn’t an argument for outside help—it’s an argument for being realistic about what your team can absorb. If you’re going to do it internally, protect the time. Reduce the other demands on the person leading the change. Give them the authority to adjust the implementation based on feedback. And commit to the full 90 days, not just the launch.

The compound effect of getting it right

When a change sticks—when the team fully adopts the new system or process and it becomes how they work—the return extends far beyond the specific improvement.

The team’s confidence in leadership increases. They saw a change announced, managed thoughtfully, adjusted based on their feedback, and sustained through the difficult middle period. That experience changes how they respond to the next change. Instead of, “here we go again,” the response becomes, “what are we improving this time?”

The operation’s capacity for change itself increases. The first rollout is the hardest because you’re building the muscle—the workflow mapping, the pilot methodology, the feedback loops, the communication cadence. The second rollout is faster. The third is routine. You’ve created an organization that can absorb change instead of one that resists it.

That capacity for change is itself one of the most valuable assets a PMC can have—especially in an industry where regulations shift, technology evolves, and the tools your team uses today may not be the tools they use two years from now. The companies that can adopt, adapt, and improve continuously will outperform the ones that treat every change as a crisis. And the foundation for that capacity is the same foundation this entire book is built on: documented knowledge, clear ownership, and the discipline of managing transitions instead of just announcing them.

The next chapter shifts from building to sustaining—and there’s a reason I chose that word over “maintaining.” The hardest part isn’t implementing the improvement. It’s designing something that lasts.