Your Team Doesn’t Hate the Software. They Hate the Rollout.
Why do software rollouts fail even when the software is good?
Because the rollout is a people problem wearing a software costume. The team isn’t resisting the tool. They’re resisting uncertainty, disruption, and the chance of looking incompetent in front of a client while they learn it. No feature list gets past that; the way you introduce the change does.
What’s the biggest mistake when introducing new software to your design team?
Announcing a full system change at the worst possible time, like the week before busy season, with a one-line directive: “start using the new system.” That earns resistance on the spot. What works is timing the announcement, saying what’s in it for each role, setting clear expectations, and making help easy to find.
How long does it take to turn a resistant team member into a champion?
About 30 days of communication before launch, then three weeks of adoption. The pieces that make it hold: involve the team’s natural go-to person early, name the learning dip before it happens, and make it safe to ask questions and make mistakes.
You bought the software everyone said would fix it. Six weeks later your senior designer still keeps her own spreadsheet, and your new hire learned the workaround instead of the system.
Some software rollouts look more like mutiny than improvement. You announce the change and get eye rolls, quiet non-compliance, and that special kind of silence that means “we’re not on board.”
The hard part most owners miss: introducing new software to your design team is a human challenge dressed up as a technical one. Your team isn’t resisting the software. They’re resisting the uncertainty, the disruption, and the fear of looking incompetent during the transition. No feature set gets past that on its own.
Spotify
Apple Podcasts
Amazon Music
YouTube
Buzzsprout
iHeartRadioWhy does the rollout matter more than the features?
The difference between software that gathers digital dust and software that changes how the studio runs isn’t the features. It’s how you bring your people along.
Most designers already know AI note-taking in client meetings makes sense. Some have tried it. Knowing something makes sense and doing it consistently are two different things, and even when one designer gets great results from a tool, it doesn’t become the team default on its own. Sound familiar?
That gap between knowing and doing is where the rollout lives, and it’s what decides whether introducing new software to your design team sticks or quietly fails.
The five things to say, and when
Getting a team on board comes down to five areas. Handle them and the resister in the back of the room has a real chance of becoming the person others go to for help.
1. Timing and messaging
When and how you announce the change sets the whole tone. Announcing a complete system overhaul right before busy season earns resistance because everyone is already stressed about deadlines. The announcements that land start with the why, meaning the specific problem this change solves for the team, not only for the business.
“This will improve our efficiency by 20 percent” is an abstract business benefit. “This gets rid of the specification reports that keep you working late on Fridays” is concrete personal relief. Same software, different reception.
This is the Order owner’s moment (the Orchestrator). You see the system, the stages, and the payoff, and you want it live by Monday. The rollout is where that strength needs a calendar and a why.
2. Identify and use champions
Every office has one person others naturally go to with software questions. They’re often not a manager. Bring that person into the selection process before you announce anything. When the change is announced, someone on the team already knows the system, is excited about it, and is ready to help colleagues.
This seems obvious in hindsight and gets skipped constantly. It’s usually a win on both sides: the tech-comfortable team member gets a leadership role, and everyone else gets support from someone who knows their day-to-day.
3. Acknowledge the performance dip
Performance and morale go down for a while during a transition. That’s how learning works, and the team does better when you say it out loud instead of treating the dip like failure. One approach: a “mistake of the week” share in team meetings where everyone, owner included, talks about their software blunders. It makes the learning curve safe.
When the team knows the dip is expected and temporary, they’re far less likely to go back to the old spreadsheet the first time something is hard. Rosabeth Moss Kanter’s Ten Reasons People Resist Change is the long version of why that dip feels so personal to the people in it.
This is where the Wisdom owner (the Legacy Leader) and the veteran on the team meet the rollout. The old way works, and it has for years. The dip is the moment the old way looks better than the new one, and the week two decision gets made right there.
4. A personal “what’s in it for me”
Designers, project managers, and admin staff each have different concerns and different wins from new software. A one-page sheet per role, showing how the new system solves that role’s specific pain, does more than any all-hands presentation. Generic benefits don’t move anyone; a designer cares about different functionality than an administrator does. (The same logic runs through training a design intern: the person learns what’s useful to them first.)
5. Clear expectations and support
“Start using the new system” is an implementation killer. The plan says what’s expected of each person, by when, and where to get help when they’re stuck. The support matters as much as the expectation; people need to know help exists before they’re frustrated enough to quit the tool. If your new hire is learning by watching whoever sits nearest, that’s your current support system, and it’s the one the rollout is replacing.
How early should we start talking about a software change?
About 30 days before launch. That gives the team time to process it, ask questions, and get ready without feeling rushed, and it lets you hear concerns before they harden into resistance.
If the software is good, won’t the team figure it out?
Good software with a bad rollout loses to ordinary software with a good one. The dip is real, and the team decides in week two whether to push through it or quietly go back. The rollout is what tips that decision.
What a 30-day rollout plan looks like
Theory helps. A calendar helps more. This is the shape of the month before introducing new software to your design team.
Day 1: open the conversation. Skip the email blast. Small-group conversations where you collect the team’s wish list for the current systems, acknowledge what’s working (not everything is broken), and listen more than you talk. It shows respect for how things run now and opens the door to what’s hard.
Day 7: introduce the solution. Demo the features that address the pain points from Day 1, share a realistic timeline rather than an aspirational one, and introduce the champion. Connect what they said they needed to what this tool does.
Day 14: make it personal. Role-specific sessions: each group gets a hands-on preview of their own workflows, with room for questions in a smaller, safer setting. This is what prevents “this doesn’t apply to me.”
Day 21: set learning expectations. Training schedule with protected learning time, the support resources (champion, documentation, who to ask), an honest conversation about the learning curve, and a stated “no silly questions” rule. This is where the performance dip gets normalized.
Day 28: map the journey. The timeline for phasing out the old system, adoption milestones with dates, and how you’ll mark the wins. Knowing the whole route lowers the anxiety about the unknown.
What this looks like with AI meeting notes
Introducing AI meeting notes to a design team follows every one of these steps. Timing: launching it the week before busy season makes designers worry about tech trouble in a client meeting. Champion: the designer most comfortable with both technology and clients tests it with familiar clients first, then shares the wins. The dip: first meetings with a recorder running feel awkward, so week one is familiar clients, week two is every consultation, and week three is when the recap becomes the thing clients mention. What’s in it for each role: designers stop juggling sketching, eye contact, and note-taking; project managers get a record without watching a recording; whoever is selling gets a same-day summary that impresses. Expectations: when to record, how to introduce it to clients, and where to get help. The AI Meeting Notes Implementation Guide is that whole rollout plan written out for this one tool.
How do we know the rollout is working?
Early signs: people ask questions (engagement), the champion is getting pulled into conversations (peer support), and training sessions have everyone in them (commitment). Later signs: the system is where the work lives, people get faster, and someone on the team suggests an improvement instead of a workaround.
What about the person who still resists after all of this?
First check whether the resistance is feedback: sometimes it’s valid information about timing or a missing feature. If it isn’t, a private conversation usually surfaces the real concern, whether that’s job security, a past bad experience, or learning anxiety. Adjusting that person’s responsibilities during the transition can acknowledge the concern while the rollout continues.
Order meets Wisdom
Most rollouts are a conversation between two Dealer Archetypes, sometimes in two people and sometimes inside one owner. The Order owner (the Orchestrator) sees the system and wants it live; the risk is a rollout that moves faster than the team’s trust. The Wisdom owner (the Legacy Leader), or the veteran on the team, has run things from experience for years and knows the old way works; the risk is a quiet return to the spreadsheet in week two. Introducing new software to your design team goes better when both are in the room on Day 1, and when the Order side builds the plan around the Wisdom side’s reasons for hesitating.
Which side of that conversation you sit on is your Dealer Archetype. The Sales Superpower Quiz shows you which of the 4 you are and gives you the roadmap for your specific Kryptonite. It takes under two minutes.
Before the next rollout
Your team doesn’t resist change. They resist being changed. When people have a hand in the process and know what’s in it for them, they become partners in it. Five questions to answer before introducing new software to your design team again: who are the influencers on the team, regardless of title; what pain does this software solve for each role; what’s the plan for the dip; how will questions and mistakes be made safe; and what does success look like at 30, 60, and 90 days.
If the rollout is for a CRM, NKBA’s CRM Optimization Secrets webinar covers what the tool has to do once the team is in it. The software only earns its place when the process it holds is written down; Sales Process Documentation is that side of the pair. And for the questions owners ask before, during, and after building the system, Kitchen and Bath Sales System FAQs answers them in one place.
If you’d like to know whether you’re the one rolling it out or the one resisting it before the next change arrives, the Sales Superpower Quiz names your Dealer Archetype and the Kryptonite that goes with it, in under two minutes.
Want to explore more strategies for successful technology adoption? Subscribe to the Elevated podcast for practical frameworks you can implement immediately. New episodes deliver actionable insights for building better businesses.
Prefer video content? Subscribe to our YouTube channel where we break down complex business concepts into clear, step-by-step guidance.
About the Author: Brandy Lawson is a speaker, author, and the founder & CEO of FieryFX, where she helps luxury design businesses put AI to work. She hosts the Elevated podcast, wrote High-er Help, and starts every AI conversation in one place: the meetings where everything gets decided and nothing gets written down.