No “Time to Learn”

Why Teams Don’t Have “Time to Learn”  

“Give me six hours to chop down a tree and I will spend the first four sharpening the ax.”
— Abraham Lincoln

Teams love to talk about continuous improvement, but most are too busy “delivering” to actually do it. I’ve heard the same phrase countless times:

“We’d love to spend time learning, but we’re under pressure to ship.”

On the surface, it sounds reasonable: the work must get done. But beneath that lies a cultural assumption that quietly shapes most software organizations: learning is personal, not professional.

That’s the heart of the problem.

The Production Mindset Trap  

Most companies operate under what I call the production mindset. It’s the belief that software development is a “factory process” where value is measured in features delivered, tickets closed, or velocity charts trending upward.

Under this mindset, learning is a luxury. If it doesn’t directly move a story from “in progress” to “done,” it’s considered waste. Developers are told that learning is an important part of their job. Sometimes that management will explicitly tell them that personal and career growth is important. But, implicitly, they are pushed to deliver features and meet deadlines. Time spent learning on the job is looked at as a distraction from the “real” work. Anything more than reading a blog post or attending a “Lunch and Learn” is seen as a waste of company time.

But that’s shortsighted. A team that never learns eventually slows down. Not because they’re lazy, but because the systems they build, the tools they use, and the skills they rely on all decay without deliberate renewal. They spend more time fighting complexity and less time creating value.

When we stop learning together, we stop getting better.

What a Learning Culture Looks Like  

A true learning culture looks very different. It’s visible in the daily rhythms of a team, not in a company handbook.

It’s the team that blocks off an hour every week to explore a new concept together.
It’s the pair that experiments with refactoring old code rather than just patching it.
It’s the engineer who mentors a teammate through a tricky design decision.
It’s leadership that treats time spent sharpening skills as essential, not optional.

These aren’t side projects or distractions. They’re investments that compound over time.

When learning is part of the workday, not a guilty pleasure squeezed into the edges of it, something powerful happens:

• Code quality grows.
• Team cohesion strengthens.
• Developers start enjoying their work again.
• Delivery actually speeds up.
• Innovation becomes a natural byproduct, not a special event.

The Observable Shift  

As a technical coach, I’ve watched this transformation up close. Teams that once believed they were “too busy to learn” discovered that structured learning time didn’t slow them down, it freed them.

They delivered with more confidence. Their refactors were safer, their design discussions sharper, their collaboration smoother. The difference wasn’t a new tool or process. It was the shift from a production culture to a learning culture.

It’s ironic: the teams that think they can’t afford time to learn are often the ones who can’t afford not to.

Leadership’s Role  

This is where leadership comes in.
Teams reflect the values they see modeled.

If leaders treat learning as something to be done sparingly, teams will follow suit. But if leaders make space for curiosity: if they attend internal workshops, encourage experimentation, and celebrate what the team learns as much as what it delivers the culture changes.

Making learning part of work is not about losing productivity; it’s about defining productivity correctly. Growth is delivery, just at a different scale.

Creating “Time to Learn”  

Leaders who want to build this culture can start small but act deliberately:

• Schedule regular learning hours during production time and protect them.
• Model curiosity by learning with the team, not above it.
• Celebrate experiments and lessons, not just launches.
• Encourage mentorship and team-based exploration.
• Reflect openly on what the team is learning and how it changes their craft.

These aren’t radical moves. They’re small but powerful signals that learning is not extracurricular. It’s part of the craft.

The Real Waste  

Lincoln understood that sharpening the ax wasn’t wasted time: it was what made the cutting possible.

Software is no different. The sharpness of our collective skill determines how effectively we can deliver. Yet many organizations keep swinging dull axes, mistaking motion for progress.

The best teams don’t measure success by how much they produce. They measure it by how much they improve.

So, if your team says they’re “too busy to learn,” pause and ask:

What’s keeping us from sharpening the ax?

Because the real waste isn’t the time we spend learning, it’s the time we spend not learning.