Growth is a scheduling problem
Engineers do not grow from feedback alone. They grow from work that is slightly too big for them, handed over on purpose. How I plan that, and what it costs the roadmap.
Ask a manager how they support growth on their team and you will hear about career conversations, learning budgets, and mentorship. Those are fine. They are also not where growth happens.
Growth happens when someone is given a piece of work that is a little beyond them, with enough support that they do not fail badly, and enough room that they might. Everything else is preparation for that moment. If the moment never comes, the career conversation was a nice chat.
Which means growth is mostly a scheduling problem, and the scheduler is me.
The roadmap is also a development plan
When I plan a quarter, I look at two lists side by side. One is the work. The other is what each person told me they want to be doing that they are not doing yet. Then I look for overlaps.
An engineer who wants to lead a project gets the next medium sized one, with me as the safety net instead of the owner. An engineer who wants to move toward infrastructure gets the migration, paired with the person who knows the system. An engineer who has never presented to leadership gets the project update this month.
None of these are the most efficient assignment. The person who already knows how to do it would be faster. That is the cost, and I pay it on purpose, because a team where the fastest person always does the thing is a team where nobody else ever learns it.
Slightly too big
The size matters. Work that is comfortably within someone's ability teaches nothing. Work that is far beyond them teaches them that they cannot do it, which is worse than nothing.
I aim for a stretch of about one level. A strong midlevel engineer gets a project a senior would normally own. A senior who wants to lead gets a project with two other people on it, not eight. When I get this wrong it is usually in the direction of too big, because I am optimistic about people, and the fix is to pull scope out early rather than let them sink.
The safety net has to be real
Handing someone a stretch assignment and then disappearing is not development. It is abdication with a nicer name.
What I do instead: I tell them, on day one, what I expect to go wrong and how I will know. I set a checkpoint in the first week, not the third. I make it clear that asking for help is part of the assignment, not evidence against them. And when they make a decision I would not have made, I let it stand unless it is going to cause real damage, because the decision being theirs is the point.
When the work runs out
Sometimes the roadmap does not have the assignment someone needs. The team is in a maintenance quarter, or the growth they want is in a direction we are not going.
I have three answers to this, in order of preference. First, find it on another team, and be willing to lend the person for a project. Second, make it: an internal tool, a proof of concept, a piece of technical debt nobody has had time for. Third, be honest that it is not here right now and say when it might be. The third answer is the one people respect most and managers give least.
What the AI rollout did to growth
The year we moved to an AI first way of working was the fastest growth year I have seen on a team, and not for the reason I expected.
I expected the tools to make people faster at what they already did. What happened instead was that the tools removed the floor under a lot of tasks, and the assignments that used to be a two level stretch became a one level stretch. A junior engineer could take a service migration that would have been out of reach the year before, because the parts that would have taken weeks of reading now took an afternoon of questions.
The stretch assignments got bigger and the safety net had to get better at the same time. The checkpoints moved from weekly to twice a week, and most of the conversation was about judgment: does this change make sense, do you understand what it does, what would you do if it broke.
What I measure
I keep one number per person: the month of their last stretch assignment. If it has been more than two quarters for anyone, the roadmap is wrong, not the person.