How to Actually Enable and Upskill Your Engineering Team

Every year, companies buy Udemy for Business or Pluralsight. They post it in Slack. Managers say "we have a learning budget, please use it." And then almost nobody does.

I've seen this at every company I worked at. I also did it myself when I first became a manager. I thought buying course access meant I was helping my team grow. It doesn't really work that way.

The Problem With Formal Training Programs

Most learning programs fail because they're based on a wrong idea. They assume engineers will sit down on a Tuesday afternoon and watch a three-hour video about Kubernetes networking. In theory, maybe. In reality, they have a sprint to finish and five Slack messages waiting.

There's also this idea that learning must be separate from work. Like a dedicated activity you do on top of your real job. But for most engineers, the gap between what they know and what they need to know shows up inside the work itself. Not in a course catalog.

I grew up in Vietnam and did a lot of self-study, because there wasn't much else. You read whatever you could find online, you tried things, you broke things, you figured it out slowly. That kind of learning sticks because you actually needed it to solve a real problem. Most corporate training doesn't have that. There's no urgency, so it doesn't stay.

Enabling vs Upskilling - These Are Different Things

I want to talk about two things that people often mix together: enabling and upskilling.

Enabling means removing the things that slow people down. Better tooling. Clear architecture docs. Faster decisions. Giving someone real ownership of a system. These help people perform at the level they already are, without unnecessary friction.

Upskilling is different. It's about expanding what someone can do. That takes longer. You need to match the right challenge to the right person at the right time.

Both matter a lot. But confusing them causes bad decisions. Like thinking a Pluralsight subscription is an upskilling program. It's really not even enabling anyone most of the time.

Growth Happens Inside the Work

The best upskilling I've seen always happens during the actual work. When someone is mid-task and hits something they don't understand - that's the best moment to learn. Not next Tuesday during "learning time."

So I try to think about task assignment more carefully. When I give someone work, I think about where they are right now and what would stretch them just enough. Not so hard they feel lost and stop trying. But hard enough that they actually have to learn something to finish it. That zone where the challenge is slightly bigger than their current skill - that's where real growth happens. Too easy and people get bored. Too hard and they get anxious and just survive without learning much.

Code review is also a very good learning tool. But most teams use it only for gatekeeping. I prefer when reviewers explain the "why" - link to a doc, describe the trade-off, share the thinking behind the decision. Not to be annoying, but because that's exactly what junior and mid-level engineers learn from. A comment that just says "nit: rename this variable" does almost nothing for their growth.

Pairing is even more useful, when you do it right. Not necessarily extreme pair programming all day. But sitting together when someone is working on something hard - either in person or on a call. What you're doing is making your own thinking visible. That's the thing you really cannot get from a course. Watching how an experienced engineer actually thinks through a problem, including the wrong turns and the uncertainty. That's very hard to teach any other way.

Matching the Challenge to the Person

This is where being a manager is actually a skill. You need to know your people well enough to get the calibration right.

Some engineers want to grow fast and they will tell you directly. Others are happy being very good at what they already do, and that's fine too. Both are valid. The first group needs real stretch work and fast feedback. The second group mostly needs to not be blocked and not have every hard new problem dumped on them.

The harder ones are engineers who say they want to grow but then resist the opportunities you give them. In my experience this usually means one of two things. Either the challenge isn't the right shape for them - wrong domain, wrong type of problem. Or there's something else going on, like they don't feel safe to fail, or the workload is already too heavy. Worth having an honest conversation before assuming they just don't care.

And yes, sometimes people genuinely don't want to grow right now. I've learned to stop pushing those people. You can make growth available. You cannot force it to happen. Trying really hard to develop someone who isn't ready just exhausts you and usually damages trust with that person.

The One That Surprised Me

A few years ago I had an engineer on my team - I'll call him Minh - who was solid but nothing special for his first year. He handled backend tasks, didn't ask many questions, kept to himself. I honestly thought he would stay at that level.

Then we had a project that was short on people. I needed someone to own the API design almost from scratch, working directly with the product and mobile teams. There was nobody else. I gave it to Minh. Honestly, not very confidently.

He was uncomfortable at first. He asked a lot more questions than usual. But after maybe six weeks something changed. He started coming to syncs with his own opinions, pushing back on the mobile team's assumptions, writing proper design docs. By the end of the quarter he was the person everyone went to for that domain.

He hadn't watched a single course. He'd just been given real ownership over something that mattered, with enough support so he didn't sink completely.

That's the model I believe in now. Real stakes, real ownership, real support. Not Udemy.

What to Actually Do

Keep the training budget. Use it for books, conferences, an occasional workshop when it's very relevant to what the team is doing right now. But don't confuse spending it with actually doing team development.

Spend more energy on: how you assign work, how your team runs code review, who you pair with who, and whether people have enough ownership to feel the real weight of their decisions. That's where the growth is.

The goal is not to produce well-trained engineers. It's to create conditions where curious engineers can grow fast. Those are very different things.