Every technology transition has a valley. The period after deployment when the team is slower, less confident, and less productive than they were before the change. Leadership panics. "Is the system broken?" No. The system is fine. The team is learning. And that learning comes at a temporary performance cost that nobody warned them about.
What You Need to Know
- Performance dips during technology transitions are normal, predictable, and temporary
- The typical dip lasts 4-8 weeks and can reduce team output by 15-30%
- Organisations that plan for the dip recover faster and retain more staff
- The worst response is to blame the team or the technology. The best response is to reduce operational pressure during the transition
15-30%
typical productivity dip during major technology transitions
Source: McKinsey & Company, Change Management Research, 2021
The Performance Valley
Here's what happens. On Monday, the team is operating at full capacity using the old system. They know every workaround, every shortcut, every quirk. They've built years of muscle memory. They might complain about the system, but they're fast with it.
On Tuesday, the new system goes live. All that muscle memory is useless. Every task takes longer. Things that were automatic now require conscious thought. The team's effective capacity drops, and it stays down for weeks.
This is the J-curve of technology adoption. Performance drops before it rises. Everyone knows this intellectually. Almost nobody plans for it.
What the Valley Looks Like
Week 1-2: Conscious incompetence. The team knows they're slow. Every task feels effortful. Errors increase. Frustration builds. This is the highest-risk period for negative sentiment.
Week 3-4: Grudging competence. Tasks start getting faster. The team can do the basics but still hits friction on complex workflows. The old system starts to fade from muscle memory.
Week 5-8: Growing confidence. The new system starts feeling natural. The team discovers capabilities the old system didn't have. Performance approaches and then exceeds the pre-change baseline.
Week 8+: New baseline. The team operates at full capacity with the new system. The performance gain the business case promised starts showing up in the numbers.
Why Leadership Gets It Wrong
They Measure Too Early
The business case said "20% efficiency improvement." Leadership checks the numbers four weeks after go-live and sees a 15% efficiency decrease. Alarm bells ring. The project gets labelled as "underperforming." Resources get pulled. Support gets reduced.
This is exactly backwards. Four weeks is the bottom of the valley. It's the worst possible time to evaluate. Measuring outcomes before the team has stabilised is like weighing a cake while it's still in the oven.
They Blame the Team
"The team isn't using the system properly." This is almost always wrong. The team is learning. Learning takes time. If performance dips during a transition, the response should be support, not blame.
When a team is slower after a technology change, the problem isn't that they're not trying. The problem is that we took away their expertise and asked them to build new expertise while still hitting the same targets. That's not a people problem. That's a planning problem.
Tim Hatherley-Greene
Chief Operating Officer
They Add Pressure
The instinct when performance drops is to increase pressure. More oversight. More reporting. More "why aren't the numbers better?" conversations. This makes the valley deeper and longer. People under pressure revert to old behaviours. If the old system is still accessible, they'll use it. If it isn't, they'll find manual workarounds.
Planning for the Valley
Set Expectations Before Go-Live
Tell leadership and the team what to expect. "Performance will dip for 4-6 weeks. This is normal. We've built a plan for it." Setting expectations doesn't prevent the dip, but it prevents the panic that makes it worse.
Provide leadership with a measurement timeline: "We'll measure baseline performance from Week 8, not Week 2. Here's what the interim period will look like."
Reduce Operational Load
During the transition period, reduce the team's workload if possible. Defer non-critical tasks. Bring in temporary support for routine work. Give people space to learn.
This feels expensive. It's cheaper than the alternative: a team that's simultaneously learning a new system, maintaining full output, and dealing with management pressure. That combination produces burnout, errors, and staff turnover.
Provide Embedded Support
Not a helpdesk. Not a FAQ document. A person, physically or virtually present, who can answer questions in real time. Someone who sits with the team during the first two weeks and helps them through the friction points.
The best support is peer-based. If you've piloted the system with a small group, those pilot users become the support network for the wider rollout. They've been through the valley. They know the shortcuts. And they're trusted in a way that IT support isn't.
Celebrate Progress, Not Perfection
During the valley, morale is fragile. Small wins matter disproportionately. "The team processed 40% more claims this week than last week" matters, even if they're still below the pre-change baseline. Track progress from the bottom of the valley, not from the old baseline.
Share these wins visibly. In team meetings, in leadership updates, in informal conversations. The narrative needs to be "we're climbing" not "we're behind."
The Canterbury Experience
During the earthquake recovery, we deployed new systems into organisations that were already under extreme operational pressure. There was no luxury of reducing workload. People had to learn new systems while simultaneously managing crisis-level demand.
What we learned: the valley is unavoidable, but its depth and duration are manageable. The organisations that acknowledged the valley, provided hands-on support, and protected their teams from blame recovered in 3-4 weeks. The organisations that treated the dip as a failure took 10-12 weeks and lost staff in the process.
The difference wasn't the technology. It was how leadership responded to the inevitable transition period.
Technology transitions have a cost. Not just in dollars, but in team performance, confidence, and energy. The organisations that plan for this cost, budget for the valley, and support their teams through it emerge stronger. The ones that pretend the valley doesn't exist spend months wondering why adoption failed.