Helping engineeers grow

by Stephen Kernan on 11-23-2023

I’ve been incredibly lucky to have managers who have given me clear expectations for my role. Not only that, but I was fortunate enough to work with some fantastic senior engineers who have helped me grow.

My career ladder, and the work I needed to do to climb it, was both obvious and well-supported. So I climbed.

But as a senior engineer, my work became less and less about my work and more about how my contributions enable the work of others. Now I was expected to help other people grow.

Helping engineers grow was a huge learning curve for me, but here's what I've learned so far.

Key areas of progression

While each company’s career ladder has different steps, almost every company maps their career path along the following three areas of progression:

  1. Technical skill: The job of an engineer is inherently technical. As a result, we should strive to improve our technical knowledge and competency. Without technical proficiency, the rest of our work will suffer.

  2. Scope of impact: When we’re first starting out as an engineer, our primary goal should be self-improvement. But as we learn and grow in our role, we should see the impact of our work move beyond ourselves and toward our team or organization.

  3. Independence: As engineers grow, we should become more self-sufficient. This doesn’t mean that we never ask for help - it just means that, over time, we require less help to complete our day-to-day work.

While these key areas of progression are relatively universal, it’s important to keep in mind the context of our own company. If at all possible, we should align these broad areas with the specific context of our company’s career ladder.

Technical skill

  • Junior Engineer: Understands the basic syntax of at least one programming language well enough to write code with some guidance.

  • Mid-Level Engineer: Familiar enough with their team’s commonly-used languages to uphold best practices and provide syntactical feedback in reviews. Has a basic understanding of the way systems interact in their infrastructure, such as clients, servers, queues, etc.

  • Senior Engineer: Familiar enough with their team’s commonly-used languages to create/establish new best practices and to help junior-/mid-level engineers learn the language as well. Familiar enough with their team’s infrastructure to build upon them by designing new systems.

How to improve

Here are a few ways we can guide engineers toward improving their technical skill:

  • Encourage them to work in unfamiliar code: They’ll probably need help, but they’ll learn so much along the way.

  • Find relevant cross-team projects: Working with other teams is a great way to find new learning opportunities. Be on the lookout for guild work or other cross-team initiatives that would be a good fit for their learning objectives.

  • Recommend specific learning material: Depending on the engineer, they may have a preference for courses or for books. It’s important to know their preference so that we can find resources that are more likely to help!

  • Find targeted pair programming opportunities: Pair programming on everything can actually impede growth. Instead, try pairing for short spurts focused on only the parts of a ticket that are more difficult. If you want to learn more about effective pair programming, I’ve got a newsletter just for you!

Independence

  • Junior Engineer: Requires some help or guidance on a significant amount of their tickets. Gets stuck often.

  • Mid-Level Engineer: Requires relatively little guidance on well-defined, familiar work. May require more guidance when working on new projects or unfamiliar areas of the codebase. Isn’t stuck very often during the normal course of their work.

  • Senior Engineer: Requires almost no additional guidance unless working in an unfamiliar codebase. Typically helps provide guidance to junior or mid-level engineers. Can almost always get themselves unstuck if necessary.

How to improve

Here are a few ways we can guide engineers toward becoming more independent:

  • Facilitate micro-brainstorms with them: When the engineer is taking on a new project, start by spending 5-10 minutes brainstorming approaches with them. This allows them to compare approaches rather than immediately honing in on a single approach.

  • Taper off pair programming: As engineers grow the frequency and scope of pair programming should gradually decrease. It can be hard to break this habit, but it’s one of the best ways to build independence.

  • Avoid immediately filling in the answer: If we immediately answer a question, we increase the chances that the engineer doesn’t understand why we answered the way we did. Instead, try to guide them through your thought process by asking questions.

Scope of impact

  • Junior Engineer: Impact is primarily focused on their own improvement. Participates in the efforts of their immediate team.

  • Mid-Level Engineer: Impact moves beyond themselves to include improvements to their immediate team. Leads small projects or features within their immediate team.

  • Senior Engineer: Impact moves beyond their immediate team to include improvements to related teams (or, depending on the company, even their entire organization). Leads larger-scale projects either within their team or across multiple teams.

How to improve

The only way to improve the amount of responsibility we can take on as engineers is to take on more responsibility.

  • Give people projects that stretch their abilities a little bit.

  • Resist the temptation to intervene.

It sounds simple, but it's hard. But when done correctly, the growth you’ll see is incredible.