L&D Maturity

September 27, 2026 · 4 min read· 102 views
Timur Gareev

Timur Gareev

Founder & Product owner Brusnika.LMS

L&D Maturity

Integrations mentioned in this article

Bitrix24 logoKommo logo

Sometimes the best way to increase L&D maturity is to implement nothing new.

It sounds strange.

Especially when there are so many interesting technologies around us.

AI.

Adaptive learning.

Personalized learning paths.

Skills-based organizations.

360-degree feedback.

Talent marketplaces.

Analytics.

Recommendation systems.

You want to try everything.

But there is one problem.

New technology doesn't make an old process mature.

If a process doesn't work without AI, adding AI often just makes it not work faster.

Let's imagine an ordinary company

There is no proper process for identifying learning needs.

Courses are created because someone asked for one.

The course catalog is outdated.

Learning data is scattered across several systems.

Managers have different ideas about who needs to develop what.

The competency model hasn't been updated for three years.

But the company wants to introduce AI-powered personalized learning recommendations.

It sounds modern.

But there is an obvious question:

What exactly will the system use to make those recommendations?

If the underlying data is poor, AI won't magically fix it.

It will simply make recommendations faster.

Maturity is not the number of technologies you have

I think it is useful to separate two things.

Technological maturity.

And

process maturity.

You can have a very modern platform and very immature processes.

And the opposite is also true.

You can have a simple LMS, several well-designed processes, and a fairly mature learning system.

This becomes especially visible when organizations start implementing complex practices.

Take 360-degree feedback.

360 by itself doesn't make development better.

If people aren't used to giving and receiving feedback, you may end up with a huge amount of data and very little change.

Or take competency models.

You can create a beautiful competency framework with 150 competencies.

But if managers don't use it in their work, it is just a framework.

Or personalized learning paths.

If the company doesn't know how to identify learning needs properly, a personalized learning path becomes a beautifully designed list of courses.

Processes have a sequence

I like a simple logic of maturity.

First, an organization needs to learn how to do the basic things consistently.

Then it can start connecting them.

Then it can manage them using data.

And only after that does it make sense to make the system more sophisticated.

For example:

  1. We can deliver training.
  2. We understand who needs it and why.
  3. We can connect learning to roles and tasks.
  4. We can see results and manage them.
  5. We start personalizing development.
  6. We automate some of the decisions.

This is not a universal ladder.

It doesn't always have to happen in exactly this order.

But I find the principle useful: each next level should build on the previous one.

You can't endlessly compensate for missing basic processes with technology.

There's another trap

When a new technology appears, organizations often start thinking they have to implement it.

AI appeared — we need AI.

Skills became popular — we need skills.

Personalized recommendations appeared — we need recommendations.

A new learning format appeared — we need to add it to the LMS.

But maturity also means being able to say:

“We don't need this yet.”

Not because the technology is bad.

But because the organization isn't ready to get a meaningful result from it yet.

That's quite a mature decision.

Sometimes you need a good spreadsheet first

This sounds almost heretical for technology companies, but sometimes it is useful to run a process manually before automating it.

Imagine a company wants to build a development system for managers.

It could immediately buy a sophisticated platform.

Or it could first try the process with 30 managers:

  • define the required competencies;
  • assess them;
  • discuss the results;
  • create development plans;
  • see what actually works;
  • repeat the assessment six months later.

And only then automate.

It may turn out that half of the planned system isn't needed at all.

That's not a failure.

Quite the opposite.

You just saved time and money.

This is especially important for L&D

L&D has one particular characteristic.

Many of its processes don't depend only on the L&D function itself.

We need managers.

We need HR.

We need data.

We need business support.

We need an understanding of roles.

We need real work processes.

So L&D can be technologically ready for something while the organization itself isn't.

And that's perfectly normal.

You can't build a mature development process inside an immature management system simply because you've bought a good LMS.

So I wouldn't start with the question “What should we implement?”

I'd start somewhere else:

“What can we already do consistently?”

Then:

“What isn't working?”

Then:

“What is the next bottleneck?”

And only then:

“What technology could help us solve it?”

I think the difference is important.

In the first case, we're looking for a use for the technology.

In the second, we're looking for technology to solve a real problem.

And that's where L&D maturity starts for me.

Not when an organization has the most modern set of tools.

But when it understands what it actually needs now — and what it can afford not to do yet.