Chapter 8: Good Influence at Scale
tsep influence teaching mentoring sponsorship guardrails opportunities leveling-up
Status: Notes complete
Overview
Chapter 8 is about deliberate, active influence — as opposed to the passive influence that Chapter 7 covers. While Chapter 7 focuses on who you are and how you behave, Chapter 8 is about what you specifically do to raise the level of engineers around you.
The framework is a 3×4 matrix: three tiers of reach (Individual, Group, Catalyst) crossed with four mechanisms of influence (Advice, Teaching, Guardrails, Opportunities). This structure prevents the common mistake of thinking “leveling up others” only means one-on-one mentoring. A staff engineer’s time is too scarce for that to be the only lever.
The underlying philosophy: invest in interventions that scale. A codelaboratory reaches hundreds of engineers; a one-on-one mentoring conversation reaches one. Both have their place, but staff engineers should deliberately choose the right tier for each investment.
Core Concepts
Three tiers of influence:
- Individual: One-on-one interactions — mentoring, answering questions, pair programming
- Group: Mechanisms that reach a team or organization — processes, style guides, paved roads, talks, documentation
- Catalyst: Culture-level interventions — changing how the organization thinks about teaching, opportunity, or guardrails
Four mechanisms of influence:
- Advice: Sharing knowledge and judgment
- Teaching: Developing skill and capability in others
- Guardrails: Preventing mistakes and creating safe defaults
- Opportunities: Opening doors for others to grow
Sponsorship ABCDs: The four ways to sponsor someone:
- Amplifying: Making their work visible to people they don’t have access to
- Boosting: Speaking up for their skills, ideas, and leadership
- Connecting: Introducing them to people who can help them grow
- Defending: Protecting them from unfair criticism or being passed over
“Give away your Legos”: The advice (from Molly Graham) to hand off pieces of work you care about as your scope grows, so others can build on them. Holding on creates single points of failure and blocks others from growing.
The 3×4 Framework
| Advice | Teaching | Guardrails | Opportunities | |
|---|---|---|---|---|
| Individual | Mentoring, answering questions, feedback, peer reviews | Pairing, shadowing, coaching | Code/design/change review, project guardrails | Delegation, sponsorship, connecting |
| Group | Talks, docs, Q&A sessions | Codelabs, classes, teaching others | Style guides, paved roads, processes, linters, templates | Sharing spotlight, amplifying others’ work |
| Catalyst | Mentorship programs | Teaching others to teach | Culture change | Creating a culture of opportunity |
Mechanism 1: Advice
Individual Level
Mentoring: Regular, ongoing relationship where you share knowledge, perspective, and judgment. Most valuable when targeted — “I’m strong in X; here’s what I’d do.”
Answering questions: When someone comes to you with a technical question, the most valuable response often isn’t just the answer. Ask what they’ve already tried. Help them figure out how they would find the answer. The goal is to reduce how often they need to come back.
Feedback: Specific, timely, honest. The “SBI” model: Situation, Behavior, Impact. Avoid vague praise (“great job”) and vague criticism (“be more confident”). Name the specific behavior and its effect.
Peer reviews: Code review and design review are primary vehicles for advice at scale. Review what matters: clarity of intent, safety, maintainability. Don’t nitpick style (that’s what linters are for).
Group Level
Talks and presentations: A single talk can reach hundreds. Share lessons learned, introduce frameworks, explain decisions. Record them.
Documentation: The most scalable form of advice. Good documentation lets people answer their own questions.
Catalyst Level
Mentorship programs: Formalize mentoring so it doesn’t only happen for the people with the most social capital. Structured programs can give access to mentorship for engineers who don’t know how to find it.
Mechanism 2: Teaching
Individual Level
Unlocking topics: Help someone go from “I don’t know what I don’t know” to having a map of the space. Introduce vocabulary, frameworks, and key resources.
Pairing spectrum: There’s a spectrum from “I do, you watch” → “We do together” → “You do, I watch” → “You do alone.” Scaffold to the right level. Reverse shadowing (you watch while they work) is particularly valuable — you see what’s actually hard for them.
Coaching: The distinction from mentoring — coaching uses questions rather than answers. Coaching principles:
- Ask open-ended questions (“What have you tried?” “What’s stopping you?”)
- Practice active listening — don’t formulate your next point while they’re still talking
- Make space — silence after a question is OK; they’re thinking
Group Level
Codelabs and workshops: Structured, hands-on learning experiences. More engaging than documentation; more scalable than one-on-one pairing.
Classes: For foundational knowledge that many people need — onboarding, domain basics, tooling.
Code and design review culture: Write reviews that teach, not just reviews that approve or reject. Explain the “why.” Link to principles and standards. Over time, reviewers’ principles become the team’s principles.
Catalyst Level
Teaching others to teach: The highest leverage: develop people who develop people. Write review guidelines that help reviewers write better reviews. Document your coaching approach so others can use it. Train people to run the codelabs you designed.
Mechanism 3: Guardrails
Guardrails prevent mistakes at scale. They’re the alternative to catching every mistake personally.
Individual Level
Code review: The primary individual-level guardrail. Check for correctness, security, and maintainability. Catch mistakes before they reach production.
Design review: Earlier-stage catch. Review before code is written, when changes are cheap.
Change review: Pre-production review of infrastructure changes, configuration changes, or high-risk deployments.
Project guardrail: A staff engineer can serve as a safety check for a project outside their day-to-day — reviewing the plan, the architecture, or the launch criteria.
Group Level
Processes: Explicit workflows that encode good practices. Incident response processes, deploy checklists, architectural review boards.
Written decisions: Document why decisions were made. This prevents relitigating them and helps future engineers understand what trade-offs were accepted.
Style guides: Consistency at scale. The style guide is the document form of “this is how we do things here.”
Paved roads: The default path that makes the right thing easy. A paved road provides a well-supported, well-documented approach that most projects should follow — not a mandate, but the path of least resistance.
Policies: Rules that apply to everyone. Use sparingly; policies are expensive to maintain and create compliance overhead.
Robots, linters, templates: Automated guardrails. Linters catch style and safety issues without requiring human review. PR templates prompt for information that’s often missing. Automated tests enforce behavior.
Catalyst Level
Culture change: The hardest guardrail — shifting the organization’s default toward better practices. This requires consistent behavior from many senior people over a long time, not a single intervention. Lead by example; reinforce examples when you see them; explicitly name the culture you’re building.
Mechanism 4: Opportunities
Individual Level
Delegation / Give away your Legos: Hand off pieces of your work to others. Not everything — keep the work you specifically need to grow or that only you can do — but actively transfer ownership of tasks where another engineer would benefit from taking them on.
Sponsorship ABCDs:
- Amplify: “I wanted to share this analysis from [person] — it’s really insightful.”
- Boost: In a room where they’re not present: “Have you seen [person]‘s work on X? They’re excellent at this.”
- Connect: “You should talk to [person] — they solved exactly this problem last year.”
- Defend: “That objection isn’t fair — [person] explicitly addressed it in their proposal.”
Connecting people: Introduce people who should know each other. Your network is valuable; sharing access to it multiplies the value.
Group Level
Sharing the spotlight: Explicitly acknowledge others’ contributions in public. Include names in launch emails. Recommend team members for talks and panels. When you get credit for group work, redistribute it.
Catalyst Level
Creating a culture of opportunity: Shape norms so that opportunities flow based on merit and potential rather than existing access. Push back when the same names keep getting recommended. Ask “who haven’t we considered?”
Key Takeaways
- Leveling up others requires a framework, not just ad hoc mentoring. The 3×4 matrix (tiers × mechanisms) structures your investments.
- Scale your interventions — group and catalyst-level actions reach more people per unit of your time.
- Advice at scale: talks, documentation, mentorship programs.
- Teaching at scale: codelabs, coaching culture, teaching others to teach.
- Guardrails at scale: paved roads, linters, written decisions, style guides.
- Opportunities at scale: sponsor (ABCD), give away your Legos, share the spotlight.
- Sponsorship is distinct from mentoring — it uses your social capital to open doors, not just your time to share knowledge.
Related Resources
- ch07-role-model — Passive influence through behavior; this chapter extends to active influence
- ch09-whats-next — Building your own skills and network, the mirror of building others’
- ch03-creating-big-picture — Strategy as a group-level “advice” mechanism