Teach to Scale

At the Staff+ level, your impact is measured by how effectively you multiply the abilities of those around you.

In fact, one study found that engineers who actively mentor others are 6x more likely to be promoted into bigger roles.

This lesson shows you how to turn everyday workflows into high-leverage teaching moments. You’ll learn how to:

• Use pairing to transfer knowledge without taking the keyboard.

• Turn code reviews into opportunities for long-term growth.

Let’s get started.

Turning pairing into permanent leverage

Pairing is one of the most effective ways to transfer knowledge, but it’s easy to fall into the trap of simply taking over the keyboard. Don’t be that person.

To make pairing a truly scalable and high-leverage activity, you must actively teach and empower your partner. 

Here are some key practices to follow:

• Avoid using the keyboard: Instead of typing the solution yourself, use “driver-navigator pairing.”

• Driver-navigator roles: For pairing to have an impact, take turns as the “driver” and the “navigator”: 

  • Driver is the person at the keyboard writing the actual code.

  • Navigator will guide the driver, monitor the big picture, suggest improvements, and ensure the code aligns with project goals.

• Explain your thought process: When you’re the navigator, articulate your reasoning aloud and challenge your partner to think through the problem collaboratively. Conversely, when you are the driver, make sure to think out loud.

After each pairing session, create reusable notes or snippets that your partner can reference later:

• Write down key takeaways

• Document useful code snippets

• Link to relevant resources.

Turning reviews into knowledge transfer

When reviewing someone’s work, it is important to go beyond LGTMLooks Good To Me or nitpicks.

Use a three-part framework to guide your feedback:

• What: State the specific observation or issue in the code.

• Why: Explain the underlying principle or reason behind your suggestion.

• How: Provide a clear, actionable alternative or a path forward.

For example:

• What: “This function mutates shared state.”

• Why: “It makes debugging harder.”

• How: “Try passing in a copy or use immutability helpers.”

This is how reviews turn into micro-lessons instead of bottlenecks—framing feedback around what, why, and how.