The training department didn't break your ATM transition. Procurement did.

The first time I ran a familiarisation session on a new ATM system for operational controllers, nobody learned anything.

The entire session, and many subsequent sessions, were filled with complaints about the system, feature requests, and hostility. Controllers wanted to know why features they used every day weren't there. They wanted to know who signed off on this. No learning. No engagement. No trust in what they were being shown.

At this point in a project, many organisations decide they have a "training problem."

The assumption that kills transition programmes

When controllers push back in training, the instinct is to fix the training.

Trainers treat the resistance as either a competence gap or an attitude problem. The usual response is more sessions, better materials. Management sends an email, or holds a briefing, highlighting the importance of the programme. Attendance remains the same. Engagement drops further.

Training sessions are increased. Attendance drops. Financial incentives are added. Attendance increases. Engagement drops.

None of this works because the diagnosis is wrong. Controllers aren't resisting training, they're resisting a system that arrived without their input, missing things they need, through a process they had no say in.

The problem started in procurement

Every training problem I've encountered in an ATM modernisation programme had its roots in a procurement decision made months or years earlier.

The requirements specification was written without meaningful operational input. In some cases, controllers didn't even know a new system was on the way until contracts were signed and installation began.

The manufacturer delivered to spec and to budget exactly what was asked for. But what was asked for didn't include tools and features controllers relied on every shift.

Controllers couldn't believe features they considered basic weren't part of the core package, or even available as an additional feature. Blame landed on the manufacturer. The manufacturer pointed back to the user spec. Both were right, and neither could fix it.

The training room is the first time most staff will come face-to-face with the system. And by then, the damage is already done. The training inherits a credibility deficit it didn't create.

What controllers are actually telling you

Controllers aren't being difficult. They're being precise. They know exactly what they need to make their airspace work.

When controllers complain that the new system can't do what the old one could, they're giving you a gap analysis. For free.

When they refuse to engage, they're telling you they don't trust the process that delivered this system, because nobody asked them what they needed before the contract was signed.

The organisations that treat this as obstruction miss the most valuable feedback loop they have.

In our transition we started logging every single complaint, every feature request, and every suggestion. We prioritised them based on safety, urgency, and ease of implementation. We pushed out at least one fix or feature a week. When we couldn't, we told them what we were working on and where it stood.

Once controllers started seeing the changes and getting the feedback that something was being done, both attendance and engagement returned.

What would actually fix this

The fix is earlier involvement, not better training.

Operational controllers need a seat at the requirements table before procurement, not after delivery. Not a token review of a finished spec. Actual involvement in deciding what the system has to do, drawn from the people who will sit in front of it for the next fifteen years.

Training departments need the authority to escalate system deficiencies, not the expectation that they'll train around them. When a trainer flags a feature as missing, that should trigger a procurement conversation, not a redesign of the lesson plan.

And transition ownership has to sit with someone who understands both the operation and the system. Not the vendor. Not the project office. Someone whose job is to make the system work in the hands of the people who have to use it, and who has the authority to make it happen.

If your controllers are resisting a new system, the problem is probably in the contract that was signed before they ever saw it and not in the training room.

Ask controllers what they need long before they're expected to "just make it work."