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.
These lessons are about coaching people who are meeting expectations and want to grow. They are not a framework for managing persistent underperformance, where expectations and evidence of progress need to be cristal clear and the conversation needs to be more directive.
Development goals need to belong to the person
In my experience, goals I suggested were less likely to happen than goals the other person had arrived at themselves. Even when I thought my idea was objectively better, commitment was often lower because it was not really their goal. They need to own their goal. My job was to help them discover it.
This insight changes how I approach these conversations. Instead of proposing solutions right away, I spend 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 should not pursue it. Simply reflecting that contradiction back often changed the entire conversation. They usually already knew the answer. They just had not 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
All development conversation are different. 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. The kind of support I gave often depended on experience.
More junior engineers frequently wanted to improve everything at once. Every piece of feedback became another development goal, and it was not unusual for someone to leave a conversation with ten different things they wanted to work on. In my experience, that rarely 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 often 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. I also found it useful to connect an action to the capability someone wanted to build and to the evidence that would show progress.
For example, “I want to improve my communication” might turn out to mean “I want to lead cross-team technical decisions more effectively.” Together, we might turn that into a small plan:
- Capability: Facilitate a technical decision involving more than one team.
- Evidence: The participants understand the trade-offs, leave with a clear decision and give useful feedback on the discussion.
- Next action: Write and share a decision brief for the next cross-team discussion, including the decision needed and the relevant trade-offs.
- Support: Ask a Tech Lead or Product Manager to review the brief and give feedback after the discussion.
- Check-in: Reflect on what worked and choose the next action in the following 1:1.
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
In my experience, daily work usually takes priority over long-term development unless someone has deliberately made space for it.
Instead of reminding people myself, I started asking two simple questions:
When would you like us to check in on this again?
How confident do you feel that you’ll achieve this?
For people who found a scale useful, I also asked:
On a scale from 1 to 10, how confident are you that you’ll achieve this?
If the answer revealed doubt, I followed up with:
What would increase your confidence by one point?
That question usually uncovered a real obstacle. Sometimes the goal was too ambitious. Sometimes we had not yet made enough space for it alongside daily work.
Looking back
Looking back, I think I initially believed that helping people develop meant finding good opportunities for them. Today, I think that is important, but incomplete.
The other 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.