How I build development plans from engineers’ daily friction

Me: How will learning Node.js help us in the company?

Engineer: It won’t. We’re not using Node.js.

That was a web engineer on one of my teams. Our front end was in React, our back end was in Java, and we had no plans to use Node.js at all. His development plan listed Node.js courses and a conference, a few hundred euros of his development budget.

His plan had been 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.

When I explained this to the web engineer, he reached the conclusion himself: “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 Node.js off the list, I asked him a different question: “What are the top two or three frictions that make your day difficult?”

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

Me: 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 he had said “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 I’ve seen:

• 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 couldn’t influence his peers as much as he wanted because his English wasn’t good enough.

• An engineer who felt very slow because the team had moved to Kafka and he didn’t know it 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. He was Spanish, the working environment was in English, and he could see that his level was limiting how much he influenced his community of engineers. We used his development budget for weekly business English lessons with a teacher, starting with ten lessons, so ten weeks. The target was about the result he cared about: how many of the change initiatives he proposed to his community were accepted. As an illustration, if one in five was being accepted, the target would 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 we 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. I’ve had engineers come to me because a colleague was asking them questions five or ten times a day and they could 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.

The Kafka case shows the three parts working together. We were moving to a more event-driven architecture and had to migrate our services from Kinesis to Kafka. Nobody on the team knew much about it, and one engineer in particular felt very slow building solutions.

• The 70: his daily work was fully about Kafka, because of the migration.

• The 20: we had a staff engineer who was very good at it. When the engineer got stuck, he asked him for support and learned from him.

• The 10: we gave him 4 hours out of his 40 each week to follow online courses on Kafka.

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.

I had a senior engineer in this situation. I asked him: “What is the lead engineer doing that you are not doing?” He told me the lead was the one driving discoveries and planning the team’s work with the product manager. So I agreed with the lead engineer that the two of them would rotate that role.

Engineer: But I’ve never led a discovery.

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

Once he did, new frictions appeared. He didn’t understand some parts of the business domain well enough, and he struggled when his work depended on a team outside his own business area. These were frictions from a higher level of complexity, and now we had 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 we 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, we 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.