One of my responsibilities as an Engineering Manager was people development. At first, that felt fairly straightforward. If someone wanted to become a better engineer, I could often help by giving them the right opportunities: a technically challenging project, ownership of a new service, the chance to lead an incident, or an opportunity to present their work. Development happened naturally as part of everyday work.
Later, I moved into a Chapter Lead role where my direct reports worked in teams I was not part of. We still had regular 1:1s, discussed career goals and reflected on their development, but I no longer decided what they worked on. One of my strongest tools had disappeared.
Helping people grow became much less about creating opportunities myself and much more about helping people create them for themselves. Over time, I started experimenting with different ways of supporting people’s development and setting goals. Looking back, I realized that reaching a development goal had surprisingly little to do with me having the right answers, but rather with asking the right questions.
Development goals need to belong to the person
I noticed that goals I suggested were often less likely to happen than goals the other person had arrived at themselves. Even when I thought my idea was objectively better, commitment was lower because it wasn’t really their goal. My job was to help them discover it.
That changed how I approached these conversations. Instead of proposing solutions right away, I spent much more time sharing observations and asking questions.
I remember conversations where someone spent ten minutes enthusiastically talking about a topic before explaining, for perfectly rational reasons, why they probably shouldn’t pursue it. Simply reflecting that contradiction back often changed the entire conversation. They usually already knew the answer. They just hadn’t heard themselves say it.
Especially with experienced engineers, I found that perspective was often more valuable than advice. I could help them see something they had not noticed yet.
Different people need different kinds of guidance
There is no such thing as a standard development conversation. People differ enormously in their ambition, confidence and the pace at which they want to grow. Some are eager to take on every opportunity they can find. Others are perfectly happy deepening their expertise where they are. Neither is inherently better. My job was not to decide what someone’s ambition should be, but to help them make progress towards the goals they actually cared about.
The kind of support I gave, however, often depended on experience.
Junior engineers frequently wanted to improve everything at once. Every piece of feedback became another development goal, and it wasn’t unusual for someone to leave a conversation with ten different things they wanted to work on. That pretty much never worked.
Instead, we usually agreed on one technical focus area and one collaboration or communication skill for the next few months. Everything else could wait. Helping people prioritize was often far more valuable than identifying another opportunity for improvement.
Experienced engineers usually had the opposite challenge. They often came into a conversation with a very clear next step in mind.
“I should become a manager.”
“I probably need to become a staff engineer.”
I pay close attention to the wording in those moments: “I should…” or “I need…” The wording and the tone often give away whether it is an internal or an external driver, and it is an interesting start for a conversation. “You said should… how come?” I like to have conversations about what they think the job is like, what they think they would enjoy, what they think they would dislike and mirror back what I observe. Is this something they genuinely want or simply what they believe the next logical career step should be? Have they actually understood the role?
In those conversations, I found that asking questions was much more useful than giving personal advice. Sharing observations, reflecting back what I was seeing and helping people connect patterns in their own thinking usually led to better decisions than telling them what I thought they should or should not do based on their skills.
Development rarely happens alone
Development goals almost always depend on the support of other people.
Someone who wanted to improve stakeholder management might need support from their Product Manager. Someone looking for more technical ownership might need to talk to their Tech Lead. Someone interested in public speaking needed to let people know they were looking for opportunities.
Building that support network made the actual goal much more achievable. And it had one more benefit: if someone shares a goal with me or with the people around them, it becomes more real. It is no longer just an idea they had thought about. It becomes a commitment.
Specific goals beat good intentions
Once people had chosen a goal they genuinely cared about, we tried to make it concrete. Goals like become a better data scientist or improve my communication skills sound reasonable, but they are difficult to act on.
Instead, I kept asking questions until we arrived at actions that could actually be completed at a given point in time.
Whenever possible, those actions were also under the person’s control. Submitting a conference proposal is. Giving a conference talk is not.
Focusing on actions instead of outcomes made it much easier to make and feel progress.
Check-ins matter
Daily work almost always takes priority over long-term development.
Instead of reminding people myself, I started asking two simple questions:
When would you like us to check in on this again?
On a scale from 1 to 10, how confident are you that you’ll achieve this?
If the answer was not a 9 or a 10, I asked one follow-up question:
What would increase your confidence by one point?
That question usually uncovered a real obstacle. Sometimes the goal was too ambitious. Sometimes they simply had not figured out how to make time for it, and we had a conversation about how they could find the time.
Looking back
Looking back, I think I initially believed that helping people develop meant finding good opportunities for them. Today, I think that is only a small part of it.
The more important part is helping people choose goals they genuinely care about, narrow their focus, connect with the people who can support them and keep making progress over time.
Everything in this article assumes that people are already great or excellent performers who want to grow. This was true for most of the people I worked with. It is very different from managing underperformance. When someone consistently is not meeting expectations, conversations become much more directive. Expectations need to be clear, progress needs to be measurable and there is less room for discussion.