Welcome to the final lesson of our course. Over the past eleven modules, we have journeyed from the foundational principles of distributed systems, through the canonical architectures pioneered at Google and beyond, and into the advanced arts of system design and technical leadership. In our last lesson, we focused on communicating complex technical decisions to non-technical stakeholders, a critical skill for bridging the gap between engineering and business strategy.
This lesson brings our focus back into the engineering organization to address the learning outcome: Develop a personal framework for mentoring engineers through architecture reviews and design guidance. As a Principal Engineer, your individual technical contributions, while significant, are finite. Your greatest potential for impact—your primary force multiplier—lies in your ability to elevate the skills and judgment of the engineers around you. This lesson will equip you to transition from being a top-tier problem solver to a world-class engineering leader who builds other leaders.
The Principal Engineer as Mentor and Sponsor
As you transition from a Staff to a Principal Engineer, your responsibilities shift from primarily project-focused execution to setting broader technical direction and cultivating the engineering culture. Mentorship becomes a core function of your role, not an optional side activity. However, mentoring at this level is different from guiding a junior engineer. It's less about teaching syntax and more about shaping technical judgment and strategic thinking.
Discussing Staff Engineer by Will Larson: How to Navigate Technical Leadership Beyond Senior Level
This discussion of Will Larson's book, Staff Engineer, provides an excellent overview of the responsibilities that define senior technical leadership roles.
Please watch the following segments to understand how mentorship fits into the Staff+ role: First, listen to the hosts outline the key categories of a staff engineer's work. Note that "mentorship and sponsorship" to grow other engineers is a primary responsibility, alongside setting technical direction. Next, consider the point that these responsibilities apply at any company, regardless of size. The goal is to be a force multiplier and set the team up for long-term success. Finally, pay close attention to the concept of creating space for others. This is perhaps the most important takeaway for mentoring senior engineers. Your role is not to have all the answers, but to create opportunities for others to step up, take risks, and grow their own capabilities.
The idea of "creating space" is fundamental. It means consciously stepping back to let other engineers lead complex projects, even if you could complete them faster yourself. It means fostering an environment of high psychological safety, where engineers feel secure enough to propose ambitious ideas, make mistakes, and learn from them.
The Design Document: Your Primary Mentoring Artifact
At Google, the design document is the primary instrument for technical design, consensus-building, and, crucially, mentorship. It's a structured narrative that forces an engineer to move beyond just code and articulate the why behind their technical choices. As a mentor, your role is to guide an engineer through the creation of this document, using it as a tool to probe their thinking and develop their design skills.
Design Docs at Google - Industrial Empathy
This article by a former Googler provides an authoritative look at the culture and practice of design docs at Google. It's an essential resource for understanding how to provide effective design guidance in this environment.
Please read the following sections: Start with the introduction to understand the core functions of a design doc, especially scaling senior knowledge. This directly frames the design doc as a mentoring tool. Next, study the anatomy of a design doc section carefully. This provides the structure and key questions you will use to guide your mentee. Pay special attention to "The actual design," which emphasizes trade-offs, and "Alternatives considered." Finally, read about the design doc lifecycle, particularly the "Creation and rapid iteration" and "Review" phases. This outlines the process you'll be mentoring someone through.
Your guidance will revolve around the sections of the design doc. You are not the author, but the Socratic questioner. Here are some examples of guiding questions you can use for each section:
- Context and Scope: "Who are the users of this system? What are the bounds of the problem we are solving right now?"
- Goals and Non-Goals: "What are the most critical success metrics (e.g., latency, availability, cost)? What are we explicitly not trying to solve? Have we clarified this with our Product Manager?"
- The Actual Design: "You've chosen approach X. What are the specific trade-offs you are making compared to approach Y? How does this design handle failure modes? How will we observe this system in production?"
- Alternatives Considered: "Why is the chosen design superior to the alternatives? Have we considered a simpler, less-flexible alternative? What would have to be true for one of these other alternatives to be the better choice?"
- Cross-cutting Concerns: "What are the security and privacy implications of this design? Have you consulted with the SRE team about its operational burden?"
By asking these questions, you are not giving answers. You are teaching the engineer how to think about system design at a Principal level.
The Architecture Review as a Teaching Moment
The architecture review is the formal checkpoint in the design process. For your mentee, it can be an intimidating event. Your role is to prepare them for it and to participate in a way that supports their growth. The review is not a trial; it's a collaborative problem-solving session and a powerful teaching moment.
To guide effectively, you need a clear set of evaluation criteria. What separates a great design from a good one?
Gerrit Code Review - Contributing
While this document is from the open-source Gerrit project, its principles for evaluating design documents are widely applicable and mirror the thinking inside Google.
Read the section on evaluation. As you read, think of this not as a checklist for you to fill out, but as a set of questions you can help your mentee answer before they even get to the review.
The criteria from the Gerrit document—Product/Vision fit, Impact, Complexity, Core vs. Plugin, and Commitment—provide an excellent framework. Before a formal review, you can conduct a "pre-review" with your mentee, walking through these questions:
- "How does this design align with our team's long-term vision?" (Product/Vision Fit)
- "How will we measure the success of this system once it's launched?" (Impact)
- "Is there a way to achieve 80% of the value with 20% of this complexity?" (Complexity)
Your goal is to ensure the engineer has thought through these dimensions and can confidently articulate their reasoning. In the review itself, you can act as their advocate, helping to clarify questions from other reviewers and re-framing discussions to focus on core principles when they get stuck in the weeds.
A Case Study: Mentoring in Action
Let's observe a masterclass in design guidance. The following video is framed as a mentorship session, not an interview, and the mentor's techniques are precisely what you should aim to emulate.
Senior Engineer Gets Mentored by System Design Expert 💯
In this video from interviewing.io, system design expert Dima mentors a senior engineer through a challenging problem. This is a practical demonstration of the principles we've been discussing.
Watch the entire session, but focus on the mentor's actions and words: Setting the Stage (07:02-07:41): Dima sets a high bar but empowers the engineer to "control the narrative." Guiding, Not Telling (17:13-28:36): Observe how he lets the engineer explore a simple (and slow) solution first. He then uses questions like "Can you do better?" and subtle hints ("maximize your utilization of the network") to lead her towards an exponential fan-out approach. He doesn't give the answer (log N), but helps her derive it. Unlocking the Next Level (28:42-33:39): Once she's reached the logarithmic solution for a whole file, he gives another hint ("most of the pairs of connections are not being used") to prompt her to consider breaking the file into chunks—the key insight for a peer-to-peer solution like BitTorrent. The Pull vs. Push Insight (40:02-40:40): When the mentee gets stuck on orchestration ("pushing"), Dima introduces the alternative: "What if instead of pushing we consider pulling?" This simple question opens up a whole new solution space. Distinguishing Levels (55:15-56:24): In the feedback section, Dima's distinction between senior (solves the problem) and staff+ (makes sense of the problem, questions constraints) is the essence of what you are mentoring towards.
Developing Your Personal Mentoring Framework
There is no single script for effective mentorship. Your approach will be shaped by your personality, your technical strengths, and the needs of your mentee. However, you can create a personal framework based on the principles from this lesson.
Consider structuring your framework around these three areas:
-
Guiding Philosophy:
- What is my primary goal? (e.g., "Create space for others to lead," "Ensure every design is robust and scalable," "Use every design as a teaching opportunity.")
- How will I foster psychological safety?
-
Design Guidance Process (using the design doc as a map):
- Phase 1: Problem Framing. Before a line of the doc is written, I will meet with the engineer to discuss the problem, the business context, and the explicit goals and non-goals.
- Phase 2: Iterative Drafting. I will review drafts focusing on asking questions related to trade-offs, alternatives, failure modes, and operational concerns. I will resist the urge to prescribe solutions.
- Phase 3: Review Preparation. I will conduct a 1:1 pre-review with the engineer, role-playing the formal review and using a checklist (like Gerrit's) to find weak points in the proposal.
-
Review & Feedback Tactics:
- My role in the room: Am I a silent observer, a facilitator, or an active participant? (This may change depending on the mentee's experience level).
- Questioning Style: Default to open-ended questions ("What would happen if...?") rather than closed-ended ones ("Did you consider...?").
- Feedback Delivery: Frame all feedback, both positive and critical, around principles and impact, not personal preference.
Conclusion
This lesson marks the end of our formal curriculum, but the beginning of the next stage of your professional growth. Becoming a Principal Engineer at Google is not just about mastering technology; it's about mastering the art of technical leadership.
Key takeaways from this final lesson:
- Mentorship is a Force Multiplier: Your most scalable impact comes from making other engineers better.
- Create Space for Others: Empower your colleagues by stepping back and providing opportunities for them to lead.
- Use Design Docs as a Teaching Tool: Guide engineers by asking probing questions about their design narrative, focusing on trade-offs and alternatives.
- The Review is a Learning Opportunity: Prepare your mentees for architecture reviews and use them as a forum for collaborative problem-solving, not a judgment.
- Develop a Personal Framework: Be intentional about your mentoring. Define your philosophy, process, and tactics.
You have now explored the full spectrum of skills required for the role you are targeting—from the deep technical details of consensus and storage to the high-level strategic thinking of a technical leader. Your path forward is to apply these frameworks consistently, to seek out opportunities to both design and to mentor, and to continue learning with the same curiosity that brought you here. Congratulations on completing this journey.