You think you're rolling out software. You're leading an entire team through 5 emotional states nobody taught you to recognize.
There's a story that repeats itself in thousands of companies — and almost nobody sees the pattern.
A company decides to roll out new software.
It signs up for the platform.
Approves the budget.
Sets the schedule.
Names the key user.
Holds the kickoff.
Starts the rollout.
And then, on the inside, a journey begins that nobody anticipated.
- In the first 30 days, the team is confused, anxious, and full of technical questions.
- In the next 30 days, a strange resistance shows up — subtle, silent, hard to name.
- After that, part of the team starts to loosen up. Others are still stuck.
- And around month six, the project either gets tangled up or matures, but rarely for the reasons in the original schedule.
And in the end, the manager is left with that feeling:
👉 "I followed all the right technical steps. Why was the rollout so hard?"
The answer is both harsh and liberating:
👉 Because you ran a technical project where a collective emotional journey was taking place.
And collective emotional journeys follow their own rules — rules no PMO schedule teaches.
What nobody told you about software rollouts
There's an uncomfortable truth in the enterprise technology market:
Most software rollouts are run as if they were engineering projects.
Schedule.
Phases.
Deliverables.
Triggers.
Milestones.
And that works well — for installing the software.
But software only delivers value when it's used consistently by people.
And people don't follow schedules.
People go through collective emotional states during any change of tools.
And those states follow a well-defined pattern.
There are five emotional states every team goes through in any software rollout that matters at all. Ignoring them is the silent reason so many projects sink in the first 12 months.
Let's look at them one by one.
The 5 emotional states of software adoption
State 1 — Anxiety
"Can I handle this? What if I don't get it?"
Clear signs:
- Lots of technical questions in the first weeks
- Repeated requests for the same kind of tutorial
- Subtle tension in meetings
- Unusual mental fatigue for the routine
What the team really needs here: emotional safety. Not more training — but collective patience with the people who are learning. The classic mistake is to confuse anxiety with incompetence. It's just the natural discomfort of someone who has just changed terrain.
State 2 — Resistance
"It always worked. Why do we have to change?"
Clear signs:
- Constant comparisons with "how it used to be"
- More mistakes due to "distraction"
- Discouraging offhand comments in the locker room
- A sudden rise in "I didn't have time" and "I forgot to log it"
What the team really needs here: emotional legitimacy. Someone who acknowledges that it really is hard, that something gets lost in the change, and who is honest about it. Trying to bulldoze through this phase creates passive sabotage for months.
State 3 — Curiosity
"Wait a minute… this part here is good. Let me see what else it has."
Clear signs:
- Someone starts exploring features on their own
- Questions like "what if I do it this way?" show up
- One technician informally becomes "the guy who knows the tool"
- Spontaneous suggestions for better use start to appear
What the team really needs here: room to discover. Don't force process. Let them explore. Publicly recognize every discovery. Every spark of curiosity becomes a positive emotional anchor.
State 4 — Adoption
"Now it's part of our routine."
Clear signs:
- The software gets opened without anyone having to remind people
- The team starts defending the tool against outside criticism
- New hires are trained by team veterans (not by the vendor)
- The technology is no longer a topic — it's infrastructure
What the team really needs here: systematic recognition. This is the moment most managers ease off — and that's why so many adoptions slide back. Keep naming the value of that adoption. Strengthen the habit. It's still fragile.
State 5 — Authorship
"The system is part of our culture. And we're the ones who decide how it evolves."
Clear signs:
- The team suggests structural improvements to the vendor
- It builds internal automations and customizations
- It teaches other plants or companies in the group
- It talks about the software as "our way of working" — not as "the system"
What the team really needs here: real autonomy. Give back the power to make decisions about the tool. Here the team has stopped being a user and become the author of its own digital transformation. And authorship is the greatest cultural asset a company can build in a software project.
Why most projects die between states 2 and 3
If you look back at the unsuccessful rollouts you've lived through (in your company or in consulting work you followed), you'll notice a pattern:
👉 Most projects die between the resistance state and the curiosity state.
Why?
Because resistance is uncomfortable — and it pressures everyone for quick answers. And then, under pressure:
- Consultants try to "speed things up" with more training (it doesn't work)
- Managers try to "get tough" with more pressure (it gets worse)
- Leadership starts doubting the investment (anxiety goes up)
- The vendor goes into defensive mode (and stops listening)
- The team closes off even more (protecting the locker room)
And the project goes into a downward spiral — without anyone noticing that the problem is collective and emotional, not technical.
If you understand this dynamic, you have a huge advantage:
👉 You stop trying to rush through the resistance.
👉 You start feeding the curiosity.
👉 And the project crosses its most critical phase naturally.
That's one of the most powerful leadership turns in digital transformation there is.
How Manusis4 guides these 5 emotional states in its rollouts
Over the years, we've learned something important: a rollout isn't the product's starting phase. It's an ongoing path of human support.
And that's why Manusis4 structures its rollouts around these 5 emotional states — even if it doesn't appear in the contract.
In practice:
- In the first 30 days, our team stays in close contact — not to push for speed, but to welcome the natural anxiety.
- From day 30 to 90, we know resistance will show up. We don't fight it. We normalize it. "It's normal. We're here until it passes."
- From day 90 to 180, we look for the first signs of curiosity — and amplify them with public celebration.
- From day 180 to 360, we focus on anchoring usage in the culture — not on new features. Consolidate before you expand.
- From the first year on, we start giving authorship back — involving the customer in the roadmap, in betas of new features, in the user community.
In other words: Manusis4 doesn't sell a rollout.
It sells a guided crossing.
And that's a quiet difference — but one customers only fully notice when they compare it with previous rollouts of other platforms.
Because, deep down:
Software gets installed in 90 days. A culture of use gets built in 360.
And whoever understands that leads projects that age well — instead of dying quietly after two years.
What to do with this map of the 5 states in your next rollout
Whether you're starting, in the middle of, or even finishing a software rollout today, try these 3 practices:
- Diagnose your team's current emotional state.
Which of the 5 states are you in today? Anxiety? Resistance? Curiosity? Adoption? Authorship? Honestly naming the current state changes everything.
- Adjust your leadership to the state — not to the schedule.
The schedule says "we're in month 3, we should be adopting." Emotional reality says "we're still in resistance." Whoever leads reality — wins. Whoever leads the schedule — spins their wheels.
- Communicate the current state, the next state, and what the team needs to get across.
Transparency about the emotional process helps A LOT. People feel less "lost" when they understand they're on a normal crossing — not in an anomaly.
Three practices.
No additional investment.
Real turnarounds for projects that were spinning their wheels.
This week's reprogramming
"My company's software isn't being rolled out. It's being crossed — emotionally — by my entire team. And my role as a leader is to guide that crossing with maturity, respecting the human pace of each state."
Repeat this sentence before your next rollout status meeting.
Before your next decision to "speed up adoption."
Before your next frustration with "the team that doesn't use the tool."
And see how your reading of the process changes — and the results along with it.
To wrap up
The great historical mistake of the enterprise software industry was treating rollouts as technical projects with project KPIs.
And the price of that is stamped on thousands of companies with paid licenses and underused tools.
The great opportunity of the next decade is to do it differently:
👉 Treat rollouts as a human journey with emotional milestones.
👉 Measure adoption not by daily logins, but by the quality of use.
👉 Measure success not by scope delivered, but by authorship earned.
Companies that do this first:
- Will have smoother, longer-lasting rollouts
- Will spend less paying for the same project twice
- Will build a technology culture — not just stacks of software
- Will attract mature vendors who also work this way
- Will lead digital transformation with the calm only maturity brings
Because, deep down:
Software gets installed. A culture of use gets cultivated.
And what separates a company that harvests from one that plants and gives up is just one thing: strategic patience with the human journey of digital transformation.
Next week, we'll close Block 9 talking about the new professional profile Maintenance 4.0 demands — and the emotional delicacy of reinventing yourself in the middle of a mature career.
It's going to be one of the most moving editions of the series.
Until then.