Growing Engineers: The Long Game of People Development

The best infrastructure I've ever built isn't technical. It's the 13-person team I work with daily, each of whom is more capable now than when we started working together. That's not a humblebrag (the growth is theirs, not mine). It's a statement about what the job of engineering management actually is when you strip away the meetings, the metrics, and the stakeholder management: growing people. It's the same lowest common denominator work I've written about before, just focused on capability rather than task execution.

The technical systems we build will be deprecated, migrated, or replaced. The engineers we develop carry their growth forward indefinitely, into this team, the next team, and the one after that.

The Misconception About Development

There's a common misconception that engineer development means sending people to conferences and paying for training courses. Those things have value, but they're supplements, not the main course. The bulk of engineering growth happens in the daily work: the stretch assignment that's just beyond current capability, the feedback conversation that reframes a weakness as a skill to build, the delegation decision that gives someone ownership over something meaningful rather than just tasks.

In our environment, the most impactful development moments have been quiet ones. An engineer leading their first architecture review after months of attending them as a participant. A mid-level engineer mentoring a junior for the first time and discovering that teaching solidified their own understanding. A senior engineer being trusted with a cross-team initiative that required influence without authority.

None of those moments came from a training catalog. They came from intentional decisions about who gets what opportunity, and those decisions are the core of the management job.

The Framework I Use

I think about each engineer's development along three axes, and try to maintain forward motion on at least one axis at any given time:

Not every engineer wants to grow on all three axes, and that's fine. Some want deep specialization. Some want to move toward architecture roles that require breadth. Some are eyeing management and need organizational influence skills. The development plan is different for each person, and the first step is always asking "where do you want to go?" rather than assuming I know.

The Socratic Default

My default development approach is Socratic rather than directive. When an engineer comes to me with a problem, my first instinct isn't to solve it for them. It's to ask questions that help them think through it: "What options have you considered? What's the risk profile of each? What data would help you decide? Who else has context that might be useful?"

This is slower than just giving the answer. Significantly slower, in the short term. But it builds decision-making muscle in a way that directive management never does. An engineer who's been given answers for two years will still need answers in year three. An engineer who's been coached through decisions for two years will start making them independently, and that independence is the entire point.

The exception is crisis situations, where speed matters more than development and I'll shift to directive mode without apology (the incident response parallel applies here too). But in steady-state operations, the Socratic approach compounds. Each question I ask is a framework they internalize for future decisions I won't be present for.

Delegation as Development

The hardest lesson for me as a newer manager was learning to delegate not just tasks, but decisions. There's a meaningful difference between "implement this the way I've described" and "here's the problem and the constraints, come back with your recommendation." The first delegates execution. The second delegates judgment. Only the second develops people.

The risk is that their recommendation won't be what I would have chosen. And sometimes that's fine (there are multiple valid approaches and mine isn't inherently superior), and sometimes it requires a coaching conversation about what factors their analysis missed. Both outcomes are development. The only outcome that isn't development is never giving them the chance to recommend in the first place.

The Trust Indicator

Here's how I know the development work is landing: I can take a week of vacation and come back to find that nothing broke, decisions were made in my absence, and the team functioned at full capacity without me. That's the goal state. Not a team that needs me to operate, but a team that operates independently and uses me as a resource when I add value rather than as a bottleneck they're dependent on.

We're not fully there yet (teams are always developing, and the mix changes as people grow into new roles or new engineers join), but the trajectory is clear. Each quarter, the team operates more independently than the quarter before. Each quarter, the decisions they make without me are higher-quality. That trend line is the real metric of my performance as a manager, and it's the one I care about most.

The Connection to Parenting

I'd be remiss not to note the obvious parallel. The goal of parenting is also to work yourself out of the job. To raise humans who can make decisions, regulate themselves, navigate complexity, and function independently. The timeline is different (18 years vs. 2-3 years on a team), but the principle is the same: invest in their capability now so they need you less later, and take pride in their independence rather than interpreting it as a loss of relevance.

The facilitator voice works in both contexts. Not a dictator, not a rescuer, but a guide who asks good questions, provides the right challenge at the right time, and trusts the person to grow into the space you've created for them.