Building and Scaling High-Performing Teams

Building a high-performing team is the ultimate test of an Engineering Manager. Interviewers want to see that you understand the stages of team development, can create the conditions for exceptional work, and know how to structure teams for long-term success. This lesson covers the frameworks and research that define modern team building.

Tuckman's Stages of Team Development

Bruce Tuckman introduced his model in 1965, identifying four stages that every team moves through. He added a fifth stage, "adjourning," in 1977. Understanding these stages helps you diagnose team issues and apply the right leadership style at the right time.

Stage	What Happens	Your Role as EM
Forming	Team members are polite and cautious; roles are unclear; people look to the leader for direction	Provide clear structure, define roles, set expectations, and establish team norms
Storming	Conflicts emerge as people push boundaries; disagreements on approach, style, and priorities surface	Mediate conflicts, normalize healthy disagreement, do not suppress tension -- channel it productively
Norming	The team establishes working agreements; trust builds; processes solidify; collaboration improves	Reinforce positive patterns, delegate more, let the team self-organize where possible
Performing	The team operates at high efficiency; members anticipate each other's needs; output quality is consistently high	Step back from daily operations, focus on strategic growth, remove external blockers, protect the team
Adjourning	The team disbands after a project ends or a reorg occurs; members transition to new teams	Celebrate achievements, conduct retrospectives, help members transition smoothly

Interview application: When asked "How do you build a team?", map your answer to these stages. Show awareness that teams do not jump straight to performing -- the storming phase is necessary and healthy.

Psychological Safety: Amy Edmondson's Research

Amy Edmondson, a professor at Harvard Business School, pioneered the research on psychological safety -- the shared belief that a team is safe for interpersonal risk-taking. Her work, widely cited after Google's Project Aristotle identified it as the number-one factor in team effectiveness, is essential knowledge for EM interviews.

What psychological safety looks like in practice:

Engineers speak up about risks without fear of blame
Team members admit mistakes early so problems are caught when they are small
Junior engineers challenge senior engineers' ideas respectfully, and the ideas improve as a result
People ask for help without being seen as incompetent

How to build it as an EM:

Model vulnerability. Share your own mistakes openly. "I made a bad call on that architecture decision last quarter. Here is what I learned."
Respond to failure with curiosity, not punishment. When an incident happens, ask "What can we learn?" before "Who caused this?"
Reward candor. Publicly thank people who raise concerns or dissent, even when the news is uncomfortable.
Create structured opportunities for input. Blameless postmortems, anonymous retrospective tools, and round-robin brainstorming ensure quieter voices are heard.

What psychological safety is NOT:

It is not about avoiding conflict or lowering the performance bar
It is not about making everyone comfortable all the time
It is about creating an environment where people can take the interpersonal risks required to do excellent work

Team Topologies

Team Topologies, a book by Matthew Skelton and Manuel Pais published in 2019, provides a modern framework for organizing engineering teams. It defines four fundamental team types:

1. Stream-Aligned Teams

The primary team type. Aligned to a single stream of work -- a product, a feature set, or a user journey. They have end-to-end ownership from development through production. Most of your engineers should be on stream-aligned teams.

2. Enabling Teams

Specialists who help stream-aligned teams adopt new capabilities. Examples: a DevOps enablement team that helps product teams adopt CI/CD, or a machine learning team that helps product teams integrate ML features. They work with teams temporarily, not for them permanently.

3. Platform Teams

They build and maintain internal platforms that reduce cognitive load for stream-aligned teams. Examples: an internal developer platform, a shared authentication service, or a data pipeline infrastructure. Their customers are other engineering teams.

4. Complicated Subsystem Teams

Teams responsible for components that require deep specialist knowledge. Examples: a video codec team, a real-time trading engine, or a compiler team. These exist only when the subsystem is complex enough that a stream-aligned team cannot reasonably own it.

Interview application: When asked about team structure or reorgs, reference these topologies. Show that you think about team design as an architectural decision, not just an org chart exercise.

On-Call Ownership and Operational Excellence

High-performing teams own their systems end-to-end, including production operations:

"You build it, you run it" -- Teams that own on-call for their services write more reliable code because they feel the pain of outages directly
Sustainable on-call rotations -- At least 6-8 engineers in a rotation to avoid burnout; clear escalation paths; compensated or offset with time off
Incident response culture -- Blameless postmortems, published learnings, and tracked action items that actually get prioritized

Culture Building in Remote and Hybrid Teams

With distributed teams now standard, culture building requires intentional effort:

Over-communicate in writing. Decisions made in hallway conversations must be documented in shared channels.
Create structured social time. Virtual coffee chats, team retrospectives, and occasional offsites build the trust that remote work erodes.
Default to asynchronous. Respect time zones. Use meetings for discussion and debate, not status updates.
Measure outcomes, not hours. Remote work makes it impossible to judge by presence. Focus on sprint deliverables, code quality, and peer feedback.

When you complete the quiz for this module, you will have a solid foundation in the people management and team building dimensions that EM interviewers evaluate most heavily. :::