Growth disappears when urgent work owns every available hour.
The development conversation often begins well.
An employee and manager agree on a goal. Perhaps it is a certification, a stretch assignment, time with another team or the chance to lead part of a customer engagement.
Everybody leaves the conversation encouraged.
Then the workday returns.
A customer issue needs attention. The queue grows. Somebody is away. A deadline moves forward. The learning session is postponed once, then twice. The stretch assignment goes to the person who can already do it because there is no time for someone else to learn.
Three months later, the development plan still exists.
The development does not.
When growth depends on spare time, urgent work will win almost every time.
I think organizations sometimes treat development as an employee aspiration rather than an operating responsibility.
We ask people where they want to grow. We encourage them to own their careers. We give them access to courses and learning platforms.
Those things matter.
But access is not capacity.
An employee can have a library of excellent training and no realistic hour in which to use it. They can be told to seek new experiences while every difficult assignment goes to the people who already have experience. They can be encouraged to prepare for the next role while being measured almost entirely on today’s output.
The message becomes difficult to miss.
Development is important—until the work gets busy.
And the work is always busy.
This creates more than disappointment.
Capable employees begin to see growth as something they must negotiate around the organization rather than something the organization helps create. Managers keep relying on the same experts. Less-experienced employees wait longer for meaningful exposure. The capability gap widens, and the team becomes even more dependent on the few people who already know how to handle the difficult work.
Postponed development eventually becomes an operating risk.
This is where employee engagement, enablement and empowerment connect directly to first-line management systems.
Roles should make capability development part of management accountability, not a personal favour. Work allocation should include deliberate learning opportunities, with appropriate support and risk boundaries. One-to-one meetings should revisit development commitments alongside delivery commitments. Reporting should make skill concentration and single-person dependency visible before they become emergencies.
None of this requires pretending every employee can spend Friday afternoon studying while customers wait.
Operational demands are real. Some periods will be intense. Some learning will need to move.
But there is a difference between rescheduling development and treating it as permanently optional.
A useful manager does not simply ask, “What do you want to learn?”
They ask, “What experience would build that capability, where can we create it in the work, and what will we stop or redistribute so it can happen?”
That last question matters.
Development has a cost: time, supervision, temporary inefficiency and the possibility that an experienced person could have done the work faster.
That is not wasted capacity.
It is how capacity is built.
The strongest teams do not separate learning from execution completely. They use the work itself: paired ownership, shadowing, bounded decisions, rotations, after-action reviews and progressively more complex assignments.
People still deliver.
But they are also becoming more capable of delivering tomorrow.
If development in your organization keeps losing to urgent work, the issue may be less about employee motivation and more about how roles, workload, meetings and capability risk are managed. The 7 Essential First-Line Management Systems offers a practical way to strengthen that day-to-day management architecture: www.imadlodhi.com/flm1
