Episode 5: Leading Without Becoming a Manager: Making Other Engineers Better

Early in a career, contribution is mostly individual. A problem arrives and gets solved. With experience, problems grow larger, and the work shifts toward design decisions, ambiguous requirements, and issues that span multiple parts of the system.

A further shift eventually happens, changing the question an engineer asks. "Can I solve this?" becomes "Can I help the team get better at solving this?"

If we teach three engineers how to solve that class of problem, document what we learned, improve the review process, and create opportunities for others to practice it, the impact continues long after our own task is finished.



That is technical leadership. Not doing everyone else's work but making the team more capable of doing the work themselves.

Each of those saves time this week and costs the team next quarter. The most valuable output of technical leadership is sometimes not code at all. It can be the context behind a decision, or an engineer who will not need help with the same problem next time.

Knowledge sharing does not require scheduling a presentation. Most of it happens inside work that is already underway.

Explaining how the root cause of an unusual production issue was found takes a few extra minutes. So does writing down undocumented system behavior when it turns up, or recording the reasoning next to an architectural decision rather than only the decision itself. When a question is likely to be asked again, the answer is worth turning into something reusable.

The goal is simple:

Reduce how much important knowledge depends on remembering who to ask.

Good engineering teams should be able to answer more questions through shared context and fewer through tribal knowledge.

Code reviews are among the best learning opportunities a team already has, and they slip easily into being transactional. Change this, rename that, use this pattern instead. The code improves while the engineer who wrote it learns very little.

 
A stronger review explains the reasoning. Rather than "don't do this here," something closer to: "This works, but putting the logic here gives the module two responsibilities. Moving it behind this interface keeps the dependency easier to test and change."



That takes longer to write, and it does two jobs at once. The implementation gets better and so does the author's judgment. Reviews written this way gradually reduce the amount of review a team needs, because engineers start catching the same issues on their own.

Experienced engineers tend to become the default owners of difficult problems. Again, this feels efficient. But if we always take the hardest work, nobody else gets experience solving it.

Episode 2 covered the alternative, handling over ownership while staying available. That means letting another engineer lead an investigation with support rather than running it, giving someone a design proposal to own and reviewing their thinking, or bringing a less experienced engineer into a debugging session.

There is a meaningful gap between letting someone fail and giving them enough room to learn. Knowing which one is happening is most of the skill.