Chapter 5: How to Lead a Team
seg leadership management tech-lead engineering-manager
Status: Notes complete
Overview
Chapter 5 addresses one of the most significant transitions in an engineer’s career: moving from individual contributor (IC) to leadership. The chapter argues that engineering leadership is fundamentally different from management as traditionally practiced in non-technical organizations, and that the most effective engineering leaders adopt a posture of servant leadership — removing obstacles so their team can do its best work — rather than command-and-control management.
The chapter is structured around three roles (Manager, Tech Lead, Tech Lead Manager), a set of anti-patterns to avoid, and a set of positive patterns to adopt. It draws heavily on Google’s internal experience — including the historical stigma attached to the “manager” title at Google in the company’s early years — to ground its advice in real organizational context.
A key insight is that leadership is not about having all the answers or being the smartest person in the room. It is about creating the conditions under which a team can consistently produce great outcomes. The chapter frames this through the metaphor of people as plants: different people need different conditions to thrive, and a leader’s job is to understand and provide those conditions.
Core Concepts
Servant leadership: A leadership philosophy in which the leader’s primary role is to serve the needs of the team — removing obstacles, providing resources, and creating the conditions for the team to do its best work — rather than directing and controlling.
Engineering Manager (EM): A role focused on the people side of engineering: hiring, performance management, career development, team health, and creating psychological safety. An EM is responsible for the team, not directly for the technical output.
Tech Lead (TL): A role focused on the technical direction of a project or team. A TL sets technical standards, makes key design decisions, drives technical consensus, and represents the team’s technical work to stakeholders. A TL is still an IC but with leadership responsibilities.
Tech Lead Manager (TLM): A hybrid role in which a single person holds both the EM and TL functions simultaneously. Common at Google for smaller teams. High cognitive load; requires careful attention to avoid neglecting one role at the expense of the other.
Intrinsic motivation: Motivation arising from within — doing work because it is interesting, meaningful, or personally fulfilling. Associated with long-term engagement and high-quality work.
Extrinsic motivation: Motivation arising from external rewards or pressures — salary, recognition, fear of consequences. Effective short-term but does not sustain high performance or creativity.
Manager vs. Tech Lead vs. Tech Lead Manager
These three roles are often confused, and the confusion causes real organizational harm. The chapter draws the distinctions clearly.
The Engineering Manager
The EM role is about people, not technology. An EM’s primary responsibilities are:
- Hiring and growing engineers on the team
- Managing performance and giving feedback
- Running processes (team rituals, planning, retrospectives)
- Managing team health and psychological safety
- Advocating for the team’s needs to the organization
An EM does not need to be the best technical person on the team. In fact, the authors note that at Google, the “manager” title was historically stigmatized — seen as a step away from real engineering work, taken only by those who could no longer compete technically. This was a mistake. A great EM is not a failed engineer; it is a different, equally demanding skill set.
The Tech Lead
The TL role is about technical direction, not people management. A TL’s primary responsibilities are:
- Setting the technical vision for a project or area
- Making and documenting key technical decisions
- Driving technical consensus across the team
- Unblocking other engineers on technical problems
- Representing the team’s technical work to stakeholders
A TL remains an IC — they still write code. But they spend a significant fraction of their time on coordination, communication, and decision-making. The TL role is appropriate for engineers who want to grow their impact without moving into people management.
The Tech Lead Manager
The TLM holds both roles simultaneously. This is common in practice for small teams where organizational overhead doesn’t justify separate EM and TL headcount. The dual role is cognitively demanding: the TLM must context-switch between people concerns (performance, morale, career development) and technical concerns (design decisions, code review, architecture). Without deliberate time management, one role inevitably crowds out the other.
Role | Focus | Still writes code? | Manages people?
-------------|-------------------|--------------------|-----------------
IC | Technical output | Yes | No
Tech Lead | Technical direction| Yes (reduced) | No
Eng Manager | People/process | Rarely | Yes
TLM | Both | Sometimes | Yes
Moving from IC to Leadership
The transition from IC to leadership is genuinely difficult, and the chapter acknowledges the fears engineers commonly face:
- “I’ll lose my technical skills”: Time spent on coordination and people means less time for hands-on coding. Many engineers fear becoming technically obsolete.
- “I don’t know how to manage people”: Technical training does not prepare engineers for the ambiguity of people management.
- “I’ll be responsible for others’ mistakes”: Leaders are accountable for team outcomes, not just their own work.
- “My reports will resent me”: The power differential in a manager-report relationship changes social dynamics.
The chapter’s response to these fears is to reframe the goal of leadership: you are not trying to do more work yourself — you are trying to multiply the impact of the entire team. A senior IC might produce 10x the output of a junior engineer. A leader who effectively grows and unblocks five engineers can produce 50x the output of working alone.
Servant Leadership in Practice
Servant leadership is not weakness or passivity. It requires:
- Active obstacle removal: Identifying what is slowing the team down and eliminating it
- Shielding the team: Filtering organizational noise and politics so the team can focus
- Providing context: Ensuring the team understands the “why” behind their work
- Growing people: Investing in each team member’s development
The servant leader’s question is always: “What can I do to help my team be more effective?” rather than “What should my team do for me?”
Anti-Patterns of Leadership
The chapter identifies six anti-patterns — behaviors that engineering leaders commonly fall into, often with good intentions, that reliably produce bad outcomes.
1. Hire Pushovers
What it looks like: Deliberately hiring people who are less experienced, less opinionated, or less capable than necessary — people who are unlikely to challenge the leader’s decisions or create friction.
Why it happens: Leaders with fragile egos or poor self-confidence fear being shown up by subordinates. Hiring weaker engineers feels safer.
Why it’s harmful: The team’s ceiling is determined by its weakest members. A team of pushovers cannot produce great work. It also signals to strong candidates that the team is not worth joining — creating a self-reinforcing downward spiral.
Google perspective: Hiring is one of the highest-leverage activities a leader has. Every hire either raises or lowers the team’s average. Leaders should hire people who are stronger than themselves in at least some meaningful dimension.
2. Ignore Low Performers
What it looks like: Tolerating persistently underperforming team members — hoping the problem will resolve itself, avoiding the difficult conversation, or convincing oneself that the person is “improving” without evidence.
Why it happens: Performance management conversations are uncomfortable. Managers avoid them to preserve social harmony in the short term.
Why it’s harmful: Low performers harm the team in two ways. First, directly: their output is below what the team needs. Second, indirectly: high performers notice that underperformance is tolerated and conclude that standards don’t matter. This erodes morale and can drive top performers out of the team.
The right approach: Address underperformance early, directly, and with specific feedback. Give the person a genuine opportunity to improve with clear expectations. If improvement does not occur, act — move the person to a better-fit role, or exit them from the team.
3. Ignore Human Issues
What it looks like: Treating engineering management as purely a technical or process coordination role, ignoring the emotional and interpersonal dimensions of team life — conflict between team members, personal crises affecting work, burnout, disengagement.
Why it happens: Engineers are often trained to value objectivity and rationality; human issues feel messy and outside their domain.
Why it’s harmful: Teams are made of humans. Unresolved interpersonal conflict festers and produces dysfunction. A team member going through a personal crisis who receives no support becomes disengaged and eventually leaves. Burnout is both a human harm and a productivity loss.
The right approach: Acknowledge the human dimension of your role explicitly. Ask about your team members’ wellbeing. Create space for people to share when they are struggling.
4. Be Everyone’s Friend
What it looks like: Prioritizing personal friendships and social approval over honest, sometimes uncomfortable leadership — avoiding difficult feedback, making exceptions for friends, letting relationships color performance assessments.
Why it happens: Leaders want to be liked. Being a friend to reports is emotionally comfortable. The transition from peer to manager is socially awkward; some leaders cope by refusing to fully make it.
Why it’s harmful: The most important thing a leader can do for a team member is give them honest, accurate feedback that helps them grow. Friends tell you what you want to hear. Managers who are friends first tell people what they want to hear, and those people miss the feedback that would have made them better.
The right approach: Be kind but not necessarily a friend. Kindness means treating people with respect, empathy, and care. It does not mean avoiding difficult conversations. Honest feedback delivered with genuine care for the recipient is the highest expression of respect.
5. Compromise the Hiring Bar
What it looks like: Lowering hiring standards when pressed by organizational timelines, headcount pressure, or simple fatigue — approving “good enough” candidates rather than waiting for strong ones.
Why it happens: Hiring takes time and energy. Empty seats on a team create real productivity problems. The short-term pressure to fill seats overrides the long-term cost of a weak hire.
Why it’s harmful: A weak hire is rarely a neutral event. At best, they produce below-expectation output and require significant management overhead. At worst, they create technical debt, interpersonal friction, and ultimately need to be exited from the team — consuming far more resources than the original vacancy did.
Google’s rule: It is better to have a seat empty for six months and hire a strong candidate than to fill it in two months with a weak one.
6. Treat Team Members Like Children
What it looks like: Micromanaging — requiring approval for trivial decisions, not trusting engineers to own their work, prescribing solutions rather than goals, treating reports as incapable of judgment.
Why it happens: Leaders who cannot let go of the IC role, or who have deep anxiety about outcomes, compensate by maintaining control over everything.
Why it’s harmful: Micromanagement is corrosive to motivation. Engineers who are not trusted to make decisions do not develop decision-making judgment. They become dependent, lose initiative, and ultimately leave for environments where they have more autonomy.
The right approach: Provide clear goals and context, then step back. Trust engineers to solve problems in their own way. Review outcomes, not process. Reserve intervention for situations where the engineer is genuinely stuck or moving in a clearly wrong direction.
Positive Patterns of Leadership
The chapter pairs each anti-pattern with a set of positive practices that effective engineering leaders cultivate.
Lose the Ego
Effective leaders subordinate their ego to the team’s needs. This means:
- Crediting others: Publicly attribute good ideas and good work to the people who produced them.
- Accepting feedback: Demonstrate that you are open to being wrong, that you take feedback seriously, and that you change behavior when feedback warrants it.
- Admitting uncertainty: Saying “I don’t know” is more useful than pretending to certainty you don’t have. It models intellectual honesty for the team.
The leader who needs to be the smartest person in the room, or who needs personal credit for team successes, creates a team culture that mirrors those needs — producing a competitive, low-trust environment.
Be a Zen Master
A leader’s emotional state is visible to the team and affects team morale. If the leader panics under pressure, the team panics. If the leader responds to setbacks with equanimity, the team learns to do the same.
Be calm under pressure: When a production incident, a major deadline, or an unexpected setback occurs, the team needs a leader who can assess the situation clearly and make decisions without being destabilized. This does not mean suppressing genuine concern — it means not amplifying it.
Ask questions rather than issuing directives: “What do you think we should do?” is often more valuable than “Do X.” It develops judgment in the team, gets better information to the surface, and makes the team member feel trusted.
Be a Catalyst
Leaders facilitate progress rather than producing it directly. A catalyst:
- Identifies when a team or project is stuck and intervenes to unblock it
- Facilitates decision-making when the team cannot reach consensus
- Creates the conditions for collaboration — clear goals, shared context, removal of structural obstacles
- Drives toward outcomes rather than activities
The catalyst metaphor is deliberate: a catalyst enables a reaction without being consumed by it. The leader who is a catalyst does not need to be the hero of every story.
Remove Roadblocks
One of the highest-leverage activities of any leader is eliminating the obstacles that slow the team down. Roadblocks include:
- Organizational dependencies (waiting for approvals, waiting for other teams)
- Missing resources (tools, access, information)
- Unclear requirements or priorities
- Interpersonal friction between team members
The Unexpected Question: The chapter highlights a specific technique — simply asking each team member “What is the one thing that is blocking your progress right now?” on a regular basis. This question surfaces problems that engineers often do not surface proactively (because they believe the obstacle is their own problem to solve, or because they do not want to appear incompetent). It is a simple but powerful instrument for roadblock detection.
Be a Teacher and Mentor
Leadership is a vehicle for developing the people on the team. A leader who hoards knowledge or makes themselves the bottleneck for decisions stifles team growth. A leader who teaches and mentors creates a team that becomes more capable over time.
Teaching means:
- Explaining why, not just what or how
- Pairing on hard problems rather than just solving them
- Giving feedback that is specific, behavioral, and growth-oriented
- Asking “What would you do?” before providing your own answer
Mentoring extends beyond immediate work — it includes career advice, connecting team members with opportunities, and advocating for their growth to the broader organization.
Set Clear Goals
A team without clear goals produces unfocused effort. Engineers optimize locally — they work on what seems important to them — unless they understand the team’s actual priorities. Clear goal-setting includes:
- A specific, shared understanding of what success looks like
- Explicit prioritization of competing objectives
- Regular reinforcement of goals (goals stated once are not goals — they are wishes)
The leader’s job is not to set goals once and move on. It is to continuously reorient the team toward the goals, particularly when distracting priorities arise.
Be Honest
Honest leadership is harder than it appears, because honesty often requires delivering information people do not want to hear:
- Performance feedback that is specific and critical
- Assessments of a project’s health that acknowledge problems
- Candid answers to “Am I on track for promotion?” that may be disappointing
The chapter frames honesty as a form of respect: treating team members as adults who can handle true information and make good use of it. Dishonest leadership — avoiding hard truths, softening feedback into meaninglessness, maintaining false optimism about project trajectories — is a form of condescension.
Track Happiness
A team that is burned out, disengaged, or demoralized cannot perform at its best. Leaders should actively monitor team health and individual wellbeing:
- Regular 1:1s that include genuine questions about how the person is doing (not just status updates)
- Attention to signals of disengagement (decreased participation, shorter responses, missed meetings)
- Acting on what you learn — if someone raises a concern, address it visibly
The people as plants metaphor is central here: just as different plants need different amounts of water, sunlight, and soil nutrients, different people need different kinds of motivation, recognition, autonomy, and support to thrive. Some people are intrinsically motivated and need space and interesting problems. Others need more external recognition and clear structures. The leader’s job is to understand what each person needs and provide it.
Intrinsic vs. extrinsic motivation:
- Intrinsic: The work itself is engaging, meaningful, or intellectually stimulating. This is the more sustainable motivation for high-quality creative work.
- Extrinsic: Salary, bonuses, performance ratings, public recognition. These are necessary but not sufficient. An engineer who is only extrinsically motivated will optimize for the metrics, not the outcomes.
Effective leaders identify what drives each team member and structure work to provide that. This is not manipulation — it is alignment between the person’s needs and the team’s work.
The Unexpected Question
The chapter gives special attention to a deceptively simple leadership tool: asking each person “What is blocking you right now?” or “What is one thing I could do to make your work easier?”
This question is powerful for several reasons:
- Engineers rarely volunteer information about blockers — doing so can feel like admitting weakness or demanding special treatment.
- Many blockers are organizational (process, dependencies, unclear requirements) that the engineer accepts as fixed but that a leader actually has the ability to change.
- The act of asking signals that the leader’s job is to serve the team, not the reverse.
- It surfaces systemic problems: if the same blocker appears across multiple team members, it indicates a structural issue.
Leaders should ask this question regularly — in 1:1s, in team retrospectives, and informally. The follow-through is what makes it valuable: leaders who ask but never act on the answers quickly learn that the question produces resentment rather than trust.
People Are Like Plants: Intrinsic vs. Extrinsic Motivation
The authors use the plant metaphor to make a deep point about motivation: there is no single condition that causes all people to flourish. A leadership approach that works for one engineer may harm another.
Identifying What People Need
| Signal | What the person may need |
|---|---|
| Does extra work voluntarily, talks about interesting problems | Challenging, intellectually stimulating work; autonomy |
| Asks frequently for feedback and recognition | Explicit recognition; clear signals of progress |
| Struggles when tasks are ambiguous | More structure; clearer goals and priorities |
| Works best when collaborating | Pairing opportunities; team-oriented projects |
| Produces excellent work but seems disengaged | Better alignment between work and personal interests |
Intrinsic Motivation at Google
Google’s approach to motivation has historically leaned heavily on intrinsic motivators: interesting problems, autonomy, a sense of mission, and the respect of talented peers. This works well for engineers who are primarily intrinsically motivated. For engineers who are more extrinsically motivated, leaders must supplement Google’s default approach with explicit recognition, clear feedback on progress, and structured career growth conversations.
The Risk of Ignoring Motivation Type
A leader who treats all engineers as intrinsically motivated will under-invest in recognition and feedback for those who need it. A leader who treats all engineers as extrinsically motivated will create a culture where gaming metrics is rational behavior — producing the appearance of performance rather than performance itself.
TL;DRs
(From the book’s TL;DRs section)
- Don’t “manage” in the traditional sense; focus on servant leadership, and treat your team members as adults.
- If you are new to a leadership role, the most important thing you can do in the first couple of months is listen.
- The six anti-patterns are: hiring pushovers, ignoring low performers, ignoring human issues, being everyone’s friend, compromising the hiring bar, and treating team members like children.
- People are like plants: different people are motivated by different things. It’s your job to figure out the needs of each person on your team and provide for them.
- A leader should always try to hire people who are smarter than themselves.
- There are many signals that a team isn’t happy: high turnover rate, low morale, interpersonal conflicts, or a feeling of stagnation.
- Track happiness — watch for signs of unhappiness and act on them.
- Be honest, even when it is uncomfortable. Honesty is a form of respect.
Key Takeaways
- Servant leadership is the core philosophy: a leader’s job is to create the conditions for the team to do its best work, not to direct every decision or claim credit for outcomes.
- The three leadership roles — Engineering Manager, Tech Lead, and Tech Lead Manager — are distinct. Conflating them creates confusion; understanding them allows deliberate role design.
- Moving from IC to leadership is a genuine transition requiring a new mental model: impact is now measured through the team’s output, not your own.
- The six anti-patterns (hire pushovers, ignore low performers, ignore human issues, be everyone’s friend, compromise the hiring bar, treat team like children) are the most common failure modes of new engineering leaders.
- Lose the ego: the best leaders credit others, admit uncertainty, and create cultures of intellectual honesty.
- The Unexpected Question (“What is blocking you?”) is a high-leverage leadership tool that surfaces problems engineers don’t volunteer and signals that the leader’s job is to serve the team.
- People are like plants: intrinsic vs. extrinsic motivation varies by individual, and effective leaders identify and provide what each person needs to thrive.
- Honest, direct feedback — even when uncomfortable — is one of the highest expressions of respect a leader can offer a team member.
- Tracking happiness is not a soft concern: team morale is a leading indicator of performance, retention, and quality.
- The best time to address underperformance is early and directly — delay consistently makes the problem worse and signals that the leader lacks the conviction to maintain standards.
Related Resources
- ch06-leading-at-scale — Extends Chapter 5’s leadership foundations to the challenge of leading at scale: the 3 Always framework (Always Be Deciding, Always Be Leaving, Always Be Scaling)
- ch04-engineering-for-equity — Organizational context for team composition and inclusion
- FSA-Notes ch06 — Engineering culture and team dynamics from a software architecture lens
- TSEP-Notes — The Staff Engineer’s Path covers the IC leadership track (TL equivalent) in depth
Last Updated: 2026-06-02