How do I scale myself as a senior or staff engineer?

There are, as I think of it, levels or stages of mentorship and multiplying impact.

1. You can’t really help anyone, you’re just learning yourself. How you can have impact is writing down every question you have while learning and their answers, noting everything that didn’t work (and what you had to do instead) while following the on-boarding documents, anything that wasn’t easy to understand, and so on, then make sure your notes are correct and codify them by publishing a “read-along” of the onboarding tools, updating the onboarding documentation, etc. Contributing to future onboarding success as a new team member is great.
2. You are comfortable helping new team members with their onboarding. You can walk them through tricky parts, answer their questions, etc.
3. You’re comfortable mentoring/coaching 1-2 people 1:1, helping them improve, move toward promotion, making better choices, etc. You are comfortable with 1-2 people pairing with you on a project and directing their work.
4. You coach or mentor many people, have an understanding of needs across your team and make improvements, you are able to teach others how to effectively mentor or lead a small project, and you can lead larger projects with 4+ other engineers, making all of them better as they work with you.
5. You are coaching many people to coach effectively. You are teaching people to lead large projects. You are able to delegate large project ownership to others with the right level of involvement to make them succeed at delivery and making the other participants better. You have cross team focus for engineer experience and making improvements.
6. You can teach people to teach people how to coach. You can coordinate multiple large projects led by others and make sure they are all working well together. You focus on an org, and improving things for everyone.
7. You can codify coaching, teaching coaching, teaching teachers, etc in a standard program. You may run this program initially, but should hand off ownership. People can take these classes and become better leaders, regardless of knowing you or being in your org. You help others codify their own areas of expertise to teach at scale. You improve experience for engineers across orgs, or a whole company depending on size.

I’m sure it can scale to industry-wide impact, too.

You need to learn to put practices in place that work without you there. You want to be the “top” of a coaching tree, where people you taught are prolific, people they taught are strong leaders, and so on.

If you hand someone something and they don’t follow through, it’s their loss. You can give them another shot but you partner more closely, or hand it to someone else and let them know you’re happy to help them again when they can commit.

If you aren’t able to communicate details and that’s why they didn’t succeed, then you know you don’t actually have that ability down, and you either shadow really closely to fill in gaps next time, or you do it yourself more and document more completely, assuming you need to show someone starting from zero how to do it.

they dropped the ball because they were too busy

Two thoughts here:

• A good team lead will create systems such that bad surprises are, by default, caught early. Bad news isn't bad if it can be discovered early enough. Some examples on how to do this:
  • Ask for an async project update every week, posted to a relevant group where stakeholders can comment or provide feedback.
  • Work with them to break down the deliverable into smaller chunks that have clear completion criteria.
• Exercise judgment on the person you're delegating to. The skill of being able to evaluate skill, ambition, and bandwidth of a colleague is critical. Spend a few minutes looking at their past work to determine if you're comfortable handing them the project, or at least a portion of it.
  • Tell them that you think they're up to the challenge.
  • Tell them what you think are the biggest risks for the project, and how you might mitigate them.

Related:

• How can I think like a staff engineer? (amazing answer from Philip Su)
• How to be an effective senior engineer?

This is a related question framed a different way: How to increase communication and collaboration with people as a SWE?

I think the underlying principles for building relationships are the most important for this going well. However the tactical questions still stand and I'm curious what people have done who have faced challenges with this at scale.