We talk a lot about technology in engineering leadership. Architectures. Frameworks. System design. Technical debt. Platform migrations.
We talk a lot about stakeholders. Roadmaps. Alignment. Cross-functional partnerships. Quarterly planning.
We barely talk about the people.
Not the engineers. The people.
The Gap Nobody Talks About
When engineering leaders think about mentoring, they think about the technical track. How do I help this person write better designs? How do I help them approach code more thoughtfully? How do I get them ready for the next level on the engineering ladder?
All of it assumes the person wants to climb that ladder.
Most leaders never stop to check.
I sit down with every person on my team and ask one question that has nothing to do with engineering. Where do you want to be in 10 years?
Not "where do you see yourself in this company." Not "what's your next career milestone." Where do you actually want to end up?
Sometimes the answer is Staff Engineer. Sometimes it's VP of Engineering. Sometimes it's starting their own company. Sometimes it's running a farm.
I've gotten all of those answers. And every single one of them changed how I led that person.
The Goat Farmer
Early in my leadership career, I would have heard "I want to be a goat farmer" and thought ... okay, that's interesting, but how does that help me develop you as an engineer?
That's the wrong question. The right question is: what skills does a goat farmer need?
Managing risk with incomplete information. Building systems that work without constant supervision. Making decisions when there's no clear right answer. Planning for seasons you can't control. Doing hard physical and mental work when nobody's watching.
Every single one of those skills makes someone a better engineer today.
When you know where someone is trying to go, you start seeing their current work differently. The engineer who wants to start a company ... you give them more ownership of decisions, more exposure to the business side, more practice making calls without a safety net. The engineer who wants to lead people someday ... you pair them with junior engineers, let them run meetings, give them feedback on how they communicate.
The engineer who wants to be a goat farmer ... you help them build self-sufficiency, resilience, and the ability to operate independently. And your team gets a more autonomous, more reliable engineer in the process.
The destination doesn't matter. What matters is that you know what it is. Because once you do, every piece of feedback, every stretch assignment, every difficult conversation has a direction.
We Under-Index on the Person
Engineering leadership has a blind spot. We index heavily on technical growth and career progression within the company. We have frameworks for leveling. We have competency matrices. We have promotion criteria and technical skill assessments.
We have almost nothing for the person underneath all of that.
How are they doing personally? What's energizing them right now? What's draining them? Are they operating out of their strengths or grinding through weaknesses they'll never enjoy?
People spend an enormous amount of their lives at work. If the work feels disconnected from who they are and who they're becoming, it shows. Not in their code. In their energy. Their engagement. Their willingness to go beyond what's asked.
I've seen engineers who were solid performers transform into exceptional ones after a single conversation about what they actually cared about. The technical skills didn't change. The connection to the work did.
Strengths, Not Just Skills
There's a difference between developing someone's skills and developing their strengths.
Skills are things you can teach anyone. How to write a technical design document. How to conduct a code review. How to estimate a project.
Strengths are patterns of thinking and behavior that are natural to someone. Some people are naturally strategic. Some are naturally empathetic. Some are wired to compete. Some are wired to build consensus.
When someone operates from their strengths, work gets fun. Problems feel like puzzles instead of obstacles. Challenges feel energizing instead of exhausting. And fun matters more than most leaders want to admit, because people who enjoy their work produce better results than people who are grinding through it.
Your job as a leader is to figure out what someone's strengths are and put them in a position to use them. Sometimes that means giving them a project that plays to what they're naturally good at. Sometimes it means reframing their current work so they can see how their strengths apply.
And sometimes it means having an honest conversation about whether they're in the right role at all.
The 10-Year Question
Here's what happens when you ask someone where they want to be in 10 years.
First, most people don't have an answer. They've never been asked. Their previous managers talked about the next promotion, the next quarter, the next project. Nobody zoomed out far enough to ask about the actual life they're building.
So they think about it. And that thinking alone is valuable. Because an engineer who has thought about their long-term direction makes different decisions than one who's just trying to get through the next sprint.
Second, whatever they tell you becomes a lens for everything you do as their leader. If they want to be a VP, you start giving them leadership reps now. If they want to be a founder, you start exposing them to the business side now. If they want to do something completely different, you help them build transferable skills now.
Third, they trust you differently. Because you asked about them, not about their output. You showed interest in the person, not just the engineer. That trust compounds into everything else. They bring you problems earlier. They're honest about what's hard. They push back when they disagree instead of going quiet.
All because you asked one question.
What This Looks Like in Practice
I don't do this once and check a box. It's woven into how I lead.
In 1:1s, I regularly check in on whether someone feels like they're growing in the direction they care about. Not whether they're hitting their sprint goals. Whether the work feels connected to something meaningful to them.
When I'm assigning projects, I think about which engineer will grow the most from this, not just who can execute it fastest. Sometimes that means giving a harder project to someone less experienced because the growth opportunity aligns with where they're headed.
When I'm giving feedback, I connect it back to their goals. "Here's what I observed, and here's how developing this skill connects to the thing you told me you want." Feedback lands differently when it feels like investment instead of criticism.
And when someone tells me they want to leave engineering entirely, I help them. Because my job was never to retain engineers. My job is to develop people. Some of those people will stay. Some will leave. The ones who leave because you helped them find their path will refer better people to your team than the ones who stayed because they had nowhere else to go.
The Meat and Potatoes
This isn't complicated. It's one question and the willingness to let the answer change how you lead.
Where do you want to be in 10 years?
Ask it. Listen to the answer. Then do something with it.
Most engineering leaders never ask. They mentor the engineer and ignore the person. They develop skills and overlook strengths. They plan for the next quarter and never zoom out to the next decade.
The leaders I respect most didn't just make me a better engineer. They made me a better version of myself. And the skills I built under their leadership are skills I still use today, in contexts they never could have predicted.
That's what mentoring a person looks like. It outlasts the job. It outlasts the company. It outlasts the technology.
Your team is full of people with 10-year goals they've never told anyone. Some of those goals have nothing to do with engineering. All of them have everything to do with how they show up at work every day.
Ask the question. You might be surprised what you learn.