If employees must learn a new tool between tickets, the organization has scheduled deployment—not enablement.

There is a familiar pattern in technology rollouts.

A new platform is announced. Employees receive a calendar invitation, a slide deck, and a link to a recording. The go-live date is Monday.

The operational queue does not shrink. Targets do not change. Meetings remain. Customers continue calling.

Employees are expected to “make time” for training somewhere between the work they already have and the sleep they occasionally enjoy.

Then go-live arrives, people struggle, and leadership concludes that they are resisting change.

They may not be resisting it. They may simply have been given information without being given the time and practice required to build capability.

If learning must happen after the workday, enablement has been converted into personal overtime.

The IT delivery example: Remote Support learns in production

Imagine a Remote Support team moving to a new endpoint-management platform. The tool will replace the existing remote-control application and allow analysts to diagnose devices, deploy approved scripts, reset network components, and manage endpoint policies.

The change should improve service. The new platform is faster, more secure, and capable of resolving issues that previously required Deskside intervention.

Training consists of one ninety-minute webinar during a peak support period.

Half the analysts continue taking tickets while listening. The demonstration moves quickly through ideal scenarios. There is no sandbox, no guided practice, and no opportunity to repeat higher-risk actions. A recording and a forty-page guide are posted afterward.

On Monday, the old tool is removed.

Remote sessions take longer because analysts search the guide while customers wait. Some tickets are transferred unnecessarily. Others are placed on hold while employees message the two colleagues who understood the demonstration best.

Late that afternoon, an analyst supports a user whose network agent has stopped responding. The analyst intends to run an approved reset script against one laptop. In the unfamiliar interface, the selected scope remains set to the user’s regional device group.

The script resets network settings and triggers restarts across 180 laptops.

Customer calls disconnect. Remote employees lose access to active sessions. The Service Desk receives a surge of contacts, Network Operations joins an incident bridge, and managers ask why the analyst did not follow the procedure.

The analyst made the final selection. Accountability still matters.

But the organization placed production authority in someone’s hands before creating production readiness.

A software licence gives employees access to a tool. Practice gives them the ability to use it safely under pressure.

The consequences reach well beyond one mistake

For employees: people feel exposed. They are expected to perform confidently while learning publicly, with customers waiting and every error recorded. Confidence falls, experienced analysts retreat to familiar work, and newer employees become reluctant to act without approval.

For service delivery: handling time rises, transfers increase, avoidable escalations reach specialist teams, and a few early adopters become bottlenecks. The promised productivity improvement is delayed because the learning curve was omitted from the capacity plan.

For customers: support becomes slower and less consistent. Customers experience longer holds, repeated explanations, incorrect actions, and disruption caused by employees practising in the live environment.

For the organization: incident costs, overtime, rework, and adoption delays increase. Leaders may blame attitude or competence, missing the uncomfortable truth that the rollout funded technology but underfunded learning.

What human behaviour tells us

Knowing that a feature exists is different from being able to use it correctly under pressure.

Learning research generally supports the value of active practice, retrieval, feedback, and spacing over passive exposure alone. That does not mean every employee needs the same training method or that one webinar can never work. It means attendance is weak evidence of operational competence.

Pressure also changes behaviour. When attention is divided between an unfamiliar tool, a waiting customer, and performance targets, people may fall back on familiar habits, copy prior steps, or miss scope and context cues. This is not proof of a particular brain state. It is a predictable reason to practise important actions before go-live.

Lessons for managers

  • Protect learning time. Reduce queue assignments and meeting load instead of asking employees to learn while delivering at full capacity.
  • Practise real scenarios. Include common cases, exceptions, and high-risk actions—not only the happy path.
  • Verify readiness. Use demonstrations, simulations, and supported practice rather than attendance as the only completion measure.
  • Create a safe first week. Provide floor support, peer coaches, rapid questions, and temporary guardrails.
  • Adjust expectations. Plan for a learning curve in handling time, productivity, and escalation volumes.

Lessons for organizations

  • Include training capacity in the implementation plan and business case.
  • Provide realistic practice environments before production access.
  • Design permissions and confirmation controls around the consequences of error.
  • Measure capability, adoption quality, and customer outcomes—not merely course completion.

Training is not a pause in productivity. It is how tomorrow’s productivity is built.

Key takeaways

  • Information delivery is not the same as capability development.
  • Employees need protected time to practise, ask questions, and make safe mistakes.
  • Attendance confirms presence—not operational readiness.
  • Learning curves belong in capacity and performance plans.
  • When training is squeezed around full workloads, customers eventually pay part of the tuition.

Discussion question: Does your organization genuinely make time for people to learn—or simply announce when they are expected to know?