Mentoring engineers by giving them real ownership

A lot of engineering mentoring sounds better than it works.

Managers talk about growth, stretch, and coaching, but then design team environments where engineers are protected from any real ownership. Important decisions get escalated too quickly. Hard problems get quietly reabsorbed by senior people. Mistakes are treated as evidence that someone was given too much rope rather than as part of how judgment develops.

I think that leaves a lot of growth on the table.

My own philosophy is that engineers get better by holding real responsibility. Not performative responsibility. Not “you own this, but I will actually make every important call.” Real responsibility, with clear expectations, meaningful consequences, and enough support that the person can learn rather than flail.

That does not mean setting people up to fail. It means understanding that growth requires decision-making, and decision-making always carries some risk.

Growth requires more than feedback

Feedback matters. So do regular 1:1s, calibration, and thoughtful performance conversations.

But mentoring does not become real until it changes what a person is trusted to do.

The fastest growth I have seen usually happens when engineers are given a problem that stretches their current instincts:

• a backend system when they are stronger on frontend
• a project with more ambiguous stakeholder coordination than they are used to
• ownership of estimates rather than just execution
• a migration or foundational project that forces system-level thinking
• responsibility for specs, communication, or rollout quality

These assignments reveal gaps much faster than generic advice ever can. They also make progress more visible, because the person is learning in the context of work that actually matters.

Why some managers overprotect their teams

Overprotection often comes from good intentions.

Managers want delivery to stay predictable. They do not want the business to suffer because someone is still learning. They do not want engineers to feel overwhelmed or publicly fail.

The problem is that overprotection often creates a different failure mode: engineers who remain highly capable within narrow lanes but do not build the judgment needed for larger ownership.

When that happens, teams become manager-heavy and senior-heavy. The same small group ends up carrying specification quality, cross-team coordination, and architectural direction because nobody else has enough reps. The system may look safe in the short term, but it becomes fragile over time.

What real ownership actually looks like

Real ownership does not mean disappearing and hoping someone figures it out.

It usually means being explicit about five things:

1. What outcome matters.
2. What constraints are real.
3. Which decisions the person should make independently.
4. Where to escalate early.
5. What “good” looks like beyond merely finishing the task.

That structure matters because it gives the engineer room to think without forcing them to guess the whole operating environment from scratch.

For example, when I want someone to grow, I try to match the assignment to the kind of judgment I want them to build. If the gap is around technical ownership, they need a system where design choices matter. If the gap is around communication, they need a project where clarity and coordination are unavoidable. If the gap is around prioritization, they need a problem with competing constraints.

That is mentoring through work design, not just through conversation.

Mistakes are part of the process, but not all mistakes are equal

Letting people learn through mistakes does not mean tolerating preventable chaos.

The point is not to be casual about quality. The point is to distinguish between useful mistakes and destructive mistakes.

Useful mistakes usually happen in places where:

• the blast radius is bounded
• the learning is real and transferable
• recovery is possible without major organizational cost
• the manager has enough visibility to intervene if needed

Destructive mistakes are the ones where nobody defined the constraints, the engineer was set up with poor context, or the manager ignored obvious warning signs in the name of “empowerment.”

Good mentoring lives between micromanagement and neglect. It gives engineers enough room to build judgment while making sure the environment is designed thoughtfully.

Coaching should sharpen thinking, not replace it

I care a lot about helping engineers think for themselves.

That means I try not to answer every question in the most direct possible way. Often the better move is to ask:

• What do you think the core tradeoff is here?
• What are you optimizing for?
• If we wanted this to scale, what would have to change?
• What assumptions are you making that we should validate?
• Where could this design create friction later?

Those questions are not rhetorical. They help engineers move from local implementation mode into system judgment mode.

That shift matters more than short-term correctness. An engineer who gets an answer becomes faster once. An engineer who builds a stronger decision process becomes more useful repeatedly.

Matching work to stretch matters

Not all growth opportunities are equally useful for all engineers.

Part of the manager’s job is matching assignments to the right stretch profile. Someone who needs more confidence may benefit from deeper ownership of a contained problem. Someone who is strong technically but weak in communication may need a more cross-functional project. Someone who thinks narrowly may need a project that forces them to consider reusability or long-term architecture.

This is one reason I think career growth should be tied tightly to project design. The assignment itself is often the best coaching environment.

When you get this right, the team improves on multiple levels:

• more people can own meaningful work
• the manager becomes less of a bottleneck
• the organization has better succession and bench strength
• engineers feel trusted in ways that are concrete, not symbolic

What this demands from a manager

If you want to mentor this way, you have to be willing to tolerate some imperfection.

Not recklessness. Not avoidable quality problems. But imperfection.

People building judgment will sometimes choose a narrower design than you would have. They will under-spec something, or communicate too late, or optimize locally before they learn to see the full system. That is normal.

The manager’s job is not to erase that entire learning curve. The job is to make sure the curve produces growth instead of confusion.

That requires:

• close enough context to coach well
• clear enough expectations to avoid false starts
• enough patience not to snatch work back too quickly
• enough rigor to intervene when the learning cost is becoming too high

In other words, it requires active management, not passive hope.

The team you want is built this way

Over time, the teams I most want to build are teams where people do not wait for the manager to think on their behalf. They ask better questions. They spot risks earlier. They communicate more clearly. They grow more comfortable with ambiguity because they have learned to navigate it, not because it was hidden from them.

That kind of team does not appear by accident.

It is built by giving people real work, real expectations, and enough room to develop real judgment.

That is the version of mentoring I believe in.