Mentoring engineers by giving them real ownership

A lot of engineering mentoring sounds better than it works.

Managers talk about growth, stretch, and coaching, then design environments where engineers are protected from real ownership. Important decisions escalate immediately. Hard problems get reabsorbed by senior people. Mistakes are treated as proof that someone was given too much rope.

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

My job is not to become the person everyone needs for the hardest decisions. It is to help more engineers become capable of making those decisions.

That only happens if the decision space actually gets larger.

Growth requires more than feedback

Feedback matters. So do 1:1s and performance conversations.

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

I try to move engineers through a progression:

• task ownership
• project ownership
• technical judgment
• organizational ownership

That is not a ladder of ticket difficulty. A harder ticket with the same decision-maker behind it is still a ticket. Growth starts when the person has to choose the approach, explain the tradeoff, and live with the result.

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

• a project with more stakeholder coordination than they are used to
• ownership of a native integration rather than a slice of someone else’s design
• responsibility for a spec, not only the implementation
• on-call ownership for a surface they previously only patched
• a platform problem that forces them to think beyond one customer

These assignments reveal gaps faster than generic advice. They also make progress visible, because the person is learning on work that matters.

What this looked like in practice

I have helped three engineers progress from SDE1 to SDE2. The useful part of that story is the mechanism, not the count.

We created explicit growth paths. We gave them meaningful technical and project ownership. We provided continuous feedback. We built evidence against next-level expectations instead of waiting for a calibration meeting to invent a narrative.

I also tried to create opportunities that are easy to hoard as a manager: native integrations, on-call, specifications, architecture decisions, roadmap conversations, stakeholder communication, operational systems.

If those stay with the manager because the manager is “still close to the work,” the team gets a technically impressive bottleneck.

I stay close to architecture because it keeps my judgment honest. I should not stay so close that nobody else gets to form judgment.

Why managers overprotect

Overprotection usually comes from good motives.

You have seen the failure modes. A weak spec ships. A customer-specific shortcut becomes next quarter’s incident. A review misses an edge case. So you step in. Then you step in again. Eventually the team learns that the real owner is you.

There is also ego, even when we do not name it. Being the person who can still unstick the hardest problem is a strong identity. It is especially tempting if you came up as an engineer who enjoyed high-context work, which I did — first as a software engineer at SpotDraft building the questionnaire and workflow foundation, later as a senior engineer on integrations and Legal Intake, and now as a manager.

The correction is not to disappear. The correction is to change the layer you occupy.

I have been trying to introduce clearer review layers so implementation quality can be handled through peer and technical-lead reviews, while I spend more review time on architecture, contracts, risks, edge cases, and high-context decisions. That still uses technical depth. It uses it to scale judgment rather than replace it.

Support without taking the pen back

Real ownership without support is neglect. Real support without ownership is theater.

The practical pattern I try to use:

1. Be explicit about the decision the person owns, and the decisions that remain shared.
2. Require a written spec or decision record before the work gets large. Writing makes the thinking inspectable without you sitting in every huddle.
3. Review the design at the right altitude. Do not rewrite the implementation in the comments unless the design is actually wrong.
4. After a miss, separate “what the system needed” from “what this person needs to learn.” Then give the next problem, not a permanent shadow.

Legal Intake taught me the same lesson at the product level. Execution can be engineered: specs, milestones, named owners, visible risks. People development uses the same instinct. If growth lives only in 1:1 notes, it will not survive a busy quarter.

What I am optimizing for

I want engineers to think independently, make judgment calls, and learn through stretch rather than wait for perfect instructions.

Business context belongs with them. They make better decisions when they understand why something matters: customer impact, reliability, enterprise blockers, support load, implementation speed, long-term leverage.

If they only get tasks, they will optimize locally. If they get context plus a real decision space, they start creating leverage themselves — which is the only way a 15-plus-engineer organization across Integrations and Platform keeps getting more capable instead of more dependent.

The test is simple. After the project ships, can this person own the next similar problem? If the answer is no, we did not mentor. We delivered.