How I build development plans from engineers’ daily friction

Manager: How will learning Node.js help you in your work here?

Engineer: It won’t. We don’t use Node.js.

That conversation happens more often than you’d think. An engineer’s development plan lists Node.js courses and a conference, a few hundred euros of their development budget, in a company that doesn’t use Node.js and has no plans to.

The plan was built the way many are. Someone asks “what would you like to learn?”, and the answer becomes a wishlist of topics disconnected from the day-to-day. The budget gets spent and nothing changes at work. Many other teams I meet have no development plans at all.

I build them from a different starting point: the frictions in the engineer’s day.

What I use a development plan for

For me, a development plan has to do two things at once. You become a better professional, so your value grows. And that new value makes it easier for you to achieve your goals in the company. I look for the plan where both happen.

Explain this to the engineer with the Node.js wishlist, and they often reach the conclusion themselves: “Then this won’t help me. It doesn’t make sense to spend money and my time on it.”

Step 1: Find the friction

With the wishlist off the table, ask a different question: “What are the top two or three frictions that make your day difficult?”

A common first answer goes like this:

Engineer: I can’t work very well with my product manager.

Manager: Is that because you’re missing a skill, or because of the relationship?

Engineer: The relationship. He’s very difficult to work with.

That is a real problem, and it needs solving, but it doesn’t belong in a development plan. What I’m looking for is anything that makes the day difficult, slow, or uncomfortable because the person is missing knowledge or a skill. The friction has to be centered on them.

The same complaint can hide a real friction. If the answer were “when we talk, I don’t understand him because I don’t know enough about the business”, the gap would be business knowledge, and that goes in the plan.

Other frictions that come up often:

• An engineer building agentic solutions without knowing much about LLMs, or about how solutions based on probability differ from deterministic ones. The solutions come out poor.

• An engineer who can’t influence their peers as much as they want because their English isn’t strong enough.

• An engineer who feels very slow because the team has moved to a new technology they don’t know well.

Step 2: Define where you are and where you want to be

Many plans fail here because the objectives are subjective. “Be more proactive.” “Participate more in meetings.” “Write better quality code.” Nobody can act on those, and nobody can tell when they’re done.

So for each friction we define where the person is today and what the ideal state looks like. If they don’t know, I help them define it. Then we put a time limit on it.

Take the engineer with the English gap. The working environment is in English, it isn’t their first language, and they can see that their level is limiting how much they influence other engineers. The development budget can pay for weekly business English lessons with a teacher, say a block of ten weeks. The target is about the result they care about: how many of the change initiatives they propose get accepted. If one in five is being accepted today, the target could be three in five.

For a technical gap, I look at things like:

• How often their pull requests are rejected and have to be redone

• How long their work takes compared with what was expected or what they estimated

• Bugs reaching production because of missed edge cases

• How often they have to interrupt their peers for help

That last one is easy to miss. It’s common for an engineer to come to their manager because a colleague asks them questions five or ten times a day and they can hardly progress on their own work.

When the time is up, we review. Either the gap is closed or we give it another iteration.

Step 3: Build the plan with 70-20-10

The 70-20-10 rule says that about 70% of your growth comes from your daily work, 20% from the people around you, and 10% from formal training like courses and books.

This is why the Node.js wishlist could never have worked. It was all 10%. If your daily work never asks you to use what you’re learning, you won’t improve.

Picture a team moving to an event-driven architecture and migrating its services to a new event-streaming platform. Nobody knows much about it, and one engineer feels especially slow building solutions. Here’s how the three parts work together:

• The 70: their daily work is fully about the new platform, because of the migration.

• The 20: a staff engineer on the team who knows it well becomes their go-to person when they get stuck, and they learn from them.

• The 10: they get around 10% of their week to follow online courses on it.

When you start from a daily friction, the 70 is already there. Your job is to add the 20 and the 10.

When the engineer says “I have no friction”

This is very common, with juniors as well as seniors. To me it shows the person is comfortable in the role. So I start setting goals I would expect from the next level.

With a senior engineer, a good question is: “What is the lead engineer doing that you are not doing?” The answer is often something like driving discoveries and planning the team’s work with the product manager. Then you can agree with the lead engineer that the two of them rotate that role.

Engineer: But I’ve never led a discovery.

Manager: Fine. You’re going to lead one now.

Once they do, new frictions usually appear. Maybe they don’t understand some parts of the business domain well enough, or they struggle when their work depends on a team outside their own business area. These are frictions from a higher level of complexity, and now you have something to work on.

It also works as a test. If the person is still comfortable with next-level goals, they’re probably ready for a promotion. If they aren’t, you’ve found their development plan.

When they want to learn something the company doesn’t use

Sometimes the engineer pushes back: “I want to learn this for my career.”

I ask why it matters for their career if it isn’t part of their day-to-day. If their future really is in a technology the company can’t offer, they’re probably in the wrong company, and it’s better to say so openly.

Otherwise, I come back to the two dimensions. The plan has to make you a better professional, and it has to serve the company. If you stay, you both benefit. If you leave one day, your value has grown and you’ll be better paid somewhere else.

The takeaway

Don’t ask “what would you like to learn?”. Ask what makes their day hard because of a missing skill, define where they are and where they want to be, put a timebox on it, and build the plan from their daily work, the people they can learn from, and a small amount of formal training.