Most people will tell you to be patient.
Trust the process.
Good things take time.
Do not rush quality.
There is truth in all of that.
But there is also a problem.
Sometimes “trust the process” is simply what we say when we have stopped questioning the process.
I learned that firsthand while leading an L&D team.
At the time, a typical eLearning engagement took us about 14 weeks from start to finish.
That included the usual work: consulting with the business, analysis, design, SME engagement, development, review, revisions, stakeholder updates and launch preparation.
It was not unusual by industry standards.
In fact, it probably looked reasonable.
But I kept wondering whether reasonable was the problem.
So I challenged my manager to cut the timeline in half.
The immediate response was predictable:
“It cannot be done.”
And honestly, that was a fair reaction.
We were not struggling because the team was lazy or incapable. People were already working hard. The process had simply become accepted. Fourteen weeks was how long the work took because fourteen weeks was how long the work had always taken.
I was not convinced.
So I proposed something intentionally unreasonable.
We selected a safe project.
There was no hard external deadline. The topic was low risk. If the experiment failed, the consequences would be limited.
The purpose was not to prove that every project could suddenly be rushed.
The purpose was to test what would happen if we stopped treating the existing timeline as fixed.
The development portion of the project would normally have taken about four weeks.
I asked the team to complete the first build in one week.
Not four.
One.
The reaction was exactly what you would expect.
There were concerns about quality.
There were concerns about workload.
There were concerns about cutting corners.
And to be clear, we were cutting corners.
Intentionally.
But not carelessly.
We were trying to find out which corners actually mattered.
That distinction changed the conversation.
The team was not being asked to work four times harder.
They were being asked to examine the work differently.
What had to be included?
What could be removed?
Where were we overbuilding?
What decisions were taking too long?
What was being done out of habit rather than necessity?
What could be standardized?
What could be reused?
What could be clarified earlier?
What work was slowing down the build without improving the learner experience?
The result surprised us.
The first build was completed in one week.
But the more important result was this:
It was better.
The program was more focused.
More relevant.
More concise.
More practical.
The unreasonable deadline forced us to be clear about what mattered.
We did not have time to add content simply because it was available.
We did not have time to overcomplicate the design.
We did not have time to turn every SME comment into another screen.
We had to make decisions.
That pressure improved the product.
The four-week build had been compressed into one week, but the real value came afterward.
Once the team saw that the build could be completed differently, we started examining the entire L&D process.
Where else were we losing time?
Where was friction hiding?
Where were instructional designers doing work that did not require instructional design expertise?
Where were SMEs being asked the same questions in different ways?
Where were stakeholders waiting for updates?
Where were people manually performing tasks that a system could handle?
That led to a series of changes.
We introduced templates.
We standardized the SME engagement process.
We improved the way requirements were gathered.
We gave SMEs more consistent guidance.
We automated routine stakeholder notifications.
Instead of relying on someone to remember to send every update, we designed the notification logic into the process.
We separated consulting work from build work more deliberately.
A dedicated person handled more of the upfront consulting and coordination so instructional designers could focus on design and development.
We identified recurring friction points and dealt with them systematically.
We stopped treating every engagement as though it were completely unique.
Within about a month, we had done far more than speed up one eLearning build.
We had redesigned the operating model.
The full engagement cycle dropped from approximately 14 weeks to six.
Productivity improved.
Clarity improved.
SME support became more consistent.
Stakeholders were better informed.
Administrative effort decreased.
The team had more focus.
And the quality did not decline.
It improved.
That experience changed how I think about unreasonable goals.
Most people assume an unreasonable deadline means asking people to work faster.
That is usually a mistake.
People rarely become four times faster.
Systems often can.
The deadline was not really a productivity target.
It was a diagnostic tool.
It exposed unnecessary work.
It exposed waiting.
It exposed duplication.
It exposed weak handoffs.
It exposed unclear ownership.
It exposed manual tasks that should have been automated.
It exposed work that highly skilled people should never have been doing in the first place.
The unreasonable timeline forced us to redesign the system instead of pressuring the people.
That is the part many organizations miss.
They use aggressive timelines badly.
They keep the same process, remove time and expect employees to absorb the difference.
That creates stress, poor quality and burnout.
Compression should not mean forcing people to run faster inside a broken system.
It should mean questioning why the system requires so much running.
This matters even more now.
AI is entering L&D at exactly the moment many functions are still operating like course factories.
Requests come in.
Courses go out.
Success is measured through completions.
Long timelines are defended as necessary for quality.
Teams remain busy, but the connection to performance is often weak.
The obvious response to AI is to use it to produce more content faster.
That would be the wrong lesson.
The bigger opportunity is to use AI, automation and unreasonable constraints to redesign the work itself.
What if a 12-week process had to happen in three?
What if a four-week build had to happen in one?
What if stakeholder communication happened automatically?
What if SMEs received structured guidance instead of open-ended requests?
What if instructional designers spent less time coordinating and more time solving performance problems?
What if every step had to justify its existence?
What if the course was not automatically assumed to be the answer?
Those questions create a different kind of L&D function.
One focused less on production volume and more on capability, performance and speed to value.
There are, of course, things that should not be rushed.
People need time to practise.
Judgment develops through experience.
Trust takes time.
Complex skills require repetition.
Reflection matters.
The lesson is not that everything should happen faster.
The lesson is that we should stop confusing necessary development time with unnecessary process time.
Compress the system, not the human.
That is the distinction.
Be impatient with bureaucracy.
Be impatient with duplication.
Be impatient with vague ownership.
Be impatient with work that adds no value.
Be impatient with processes that survive only because no one has challenged them.
But do not be impatient with mastery.
The most powerful part of an unreasonable timeline is not that you are guaranteed to achieve it.
You probably will not.
That is not the point.
The point is that an impossible deadline forces questions a comfortable deadline never will.
It forces prioritization.
It forces clarity.
It forces trade-offs.
It forces people to separate what matters from what has simply become normal.
Our goal was not to prove that every eLearning program should be built in one week.
Our goal was to find out what we would have to change if it had to be.
That question helped us reduce a 14-week engagement cycle to six weeks.
But more importantly, it helped us build a better system.
So yes, trust the process when the process has earned your trust.
But every once in a while, suspend that trust.
Be unreasonable with the timeline.
Even when you fail to reach it, you may discover how much of the original timeline never needed to exist.
