Teamwork for Engineers

Create conditions where people can do extraordinary work together.

Software is a team sport. The myth of the lone genius programmer - coding through the night, emerging with a perfect solution - makes for compelling cinema but terrible engineering. The reality is that every significant software system is built by groups of people who must coordinate their efforts, share knowledge, resolve conflicts, and amplify each other's capabilities.

Google's two-year study on team performance (Project Aristotle) found that the highest-performing teams have one thing in common: psychological safety - the belief that you won't be punished when you make a mistake. Not technical skill. Not individual brilliance. Not even experience. The ability to take interpersonal risks without fear.

This finding reshapes how we think about teamwork. It's not about hiring the smartest people and putting them in a room. It's about creating conditions where ordinary people can do extraordinary work together.

Why Teamwork Matters More Than Individual Brilliance

The economics of software development favor collaboration. Consider:

Knowledge distribution: No single person can hold an entire modern system in their head. The engineer who understands the payment integration doesn't understand the recommendation engine. Teams distribute cognitive load.
Error detection: Pair programming catches defects as they're introduced. Code review catches what pairs miss. Multiple perspectives reduce blind spots.
Resilience: When knowledge lives in one person's head, that person becomes a single point of failure. Teams that share knowledge survive departures.
Velocity: A team of five engineers working well together will outperform five isolated engineers every time. Coordination costs are real, but they're dwarfed by the benefits of collaboration.

As Kent Beck wrote in the original Extreme Programming book: "Write all production programs with two people sitting at one machine." This wasn't about doubling labor costs - it was about recognizing that software quality and team capability compound when people work together.

The Foundation: Psychological Safety

What It Is

Psychological safety is "a shared belief held by members of a team that the team is safe for interpersonal risk-taking." It means you can:

Ask questions without looking stupid
Admit mistakes without being punished
Propose ideas without being ridiculed
Challenge the status quo without retaliation
Be yourself without social penalty

Paul Santagata, Head of Industry at Google, puts it simply: "There's no team without trust."

What It Isn't

Psychological safety is not:

Niceness: Teams with high psychological safety have robust debates. They just debate ideas, not people.
Lowered standards: Safe teams can have high expectations. Safety enables honest feedback about performance.
Consensus requirement: You can disagree and commit. Safety means the disagreement doesn't become personal.
Absence of conflict: Healthy teams have conflict. They just handle it constructively.

Disagree and Commit

"Disagree and commit" is a principle that enables teams to move forward even when they can't reach consensus. It works like this:

Voice your concerns fully: Before a decision is made, share your perspective openly. Explain your reasoning, raise your objections, and ensure you've been heard.
Listen to understand: Others may have information or perspectives you lack. The goal is the best decision, not winning the argument.
Once decided, commit fully: After the team makes a decision\u2014even if it wasn't your preference\u2014support it as if it were your own idea. Don't undermine it, don't say "I told you so" if it fails, and don't half-commit.

Why this matters:

Teams that can't commit are slow and indecisive
Relitigating decisions drains energy and erodes trust
Half-hearted execution often causes decisions to fail\u2014creating false evidence that the decision was wrong
Commitment signals respect for the team process

What it doesn't mean:

Blindly agreeing with everything
Never raising concerns
Pretending you agreed all along
Suppressing dissent permanently (you can revisit decisions with new data)

The key insight: You can disagree with a decision while still committing to make it succeed. Commitment is about action, not about changing your mind.

Communicating Personal Challenges

Sometimes personal difficulties affect your work. How much to share with your team is a personal decision, but some transparency often helps.

Why sharing can help:

Teammates can provide support or cover for you
Unexplained performance changes create confusion and speculation
Honesty builds trust and deepens relationships
Others may be going through similar things silently

What to share:

Enough for people to understand and help: "I'm dealing with a family situation that may affect my availability this month"
You don't need to share details: "I'd rather not go into specifics, but I wanted you to know"
Clear requests: "What would help is [flexibility on deadlines / someone to cover on-call / space to work quietly]"

What boundaries to maintain:

Share what you're comfortable with\u2014not more
You don't owe anyone details about your personal life
Different relationships warrant different levels of disclosure
Consider who the information might reach

For teammates:

Receive disclosures with empathy and discretion
Don't push for details
Ask "How can I help?" rather than offering unsolicited advice
Follow up later\u2014check-ins after the initial crisis matter

How Engineers Build It

Model vulnerability: Share when you don't know something. Admit mistakes publicly. "I was wrong about that approach" from a senior engineer gives permission for everyone to be wrong.

Respond to risk-taking with curiosity: When someone asks a "basic" question or proposes an unconventional idea, respond with genuine interest rather than dismissal.

Separate ideas from identity: Critique the design, not the designer. "This approach has some scaling concerns" rather than "You didn't think about scaling."

Make failure learning, not blame: Post-incident reviews should ask "How did our system allow this?" not "Who did this?"

Pair Programming: Real-Time Collaboration

The Practice

Pair programming puts two engineers at one workstation, working on the same code simultaneously. It's not about having someone watch over your shoulder - it's about combining two minds in real-time collaboration.

Martin Fowler describes several pairing styles:

Driver/Navigator: One person types (driver) while the other reviews, thinks ahead, and provides direction (navigator). Roles switch frequently.

Ping Pong: Used with TDD - one person writes a test, the other makes it pass, then writes the next test. Roles alternate with each cycle.

Strong-Style: "For an idea to go from your head to the computer, it must go through someone else's hands." The navigator has the ideas; the driver implements them. This forces explicit communication of intent.

Pair Development: Extends beyond code to include design, documentation, and other activities. The pair tackles whatever the work requires together.

Why It Works

Two modes of thinking: The driver focuses on syntax, implementation details, and the immediate problem. The navigator thinks about edge cases, design implications, and what comes next. This division of attention catches issues that either perspective alone would miss.

Knowledge sharing: Pairing is the fastest way to transfer knowledge. A new team member pairing with an experienced one learns the codebase, conventions, and tribal knowledge simultaneously.

Code review on-the-go: When you pair, code is reviewed as it's written. The feedback loop is immediate rather than delayed by hours or days.

Collective code ownership: When multiple people write code together, ownership becomes shared. No one is precious about "their" code. Anyone can improve anything.

Focus maintenance: It's hard to check Twitter when someone is sitting next to you. Pairs keep each other honest about focus.

Reduced WIP: Pairing naturally limits work-in-progress. Two people working on one thing means fewer things are partially done.

Balancing with async culture: While Communication recommends async as the default, pair programming is a deliberate exception - it's intensive synchronous collaboration during active code creation. Most discussions and reviews can still be async; pairing is for when two minds working together in real-time adds clear value.

The Challenges

Exhaustion: Pairing is intense. Eight hours of continuous pairing is too much. Most teams find 4-6 hours sustainable with breaks.

Different skill levels: When expertise gaps are large, the more experienced person may dominate or the less experienced may feel useless. Strong-style pairing can help - the junior drives while the senior navigates.

Power dynamics: Existing social dynamics affect pairing. Women and minorities may find their contributions dismissed. Pairs need to actively monitor for balanced participation.

Introversion and alone time: Some engineers need solitary work to recharge. Mandatory all-day pairing ignores this need. Balance pairing with solo time.

Context switching: If one pair member gets pulled into a meeting, the other is stranded. Protect pairing time from interruptions.

Vulnerability requirement: Pairing exposes your thought process to another person. You can't hide confusion or mistakes. This requires trust and psychological safety.

As Dave Farley notes: "Pairing unlocks the potential of individuals and teams to learn." The discomfort is part of the growth.

Code Review as Team Practice

Review as Gift, Not Gatekeeping

Thoughtful code review is a gift to your team. It's not about proving you're smarter than the author or finding as many issues as possible to demonstrate thoroughness. It's about:

Sharing knowledge across the team
Catching issues before they reach production
Ensuring code is maintainable by others
Learning from each other's approaches

Making Reviews Constructive

Understand context first: Before commenting, understand what the author is trying to accomplish and what constraints they faced.

Ask questions before making demands: "Could you help me understand why this approach?" opens dialogue. "Change this to X" closes it.

Distinguish preferences from requirements: "This would be cleaner as..." is a suggestion. "This will cause a memory leak because..." is a requirement. Label them clearly.

Acknowledge good work: Reviews shouldn't only identify problems. "This is a clever solution" or "Thanks for adding these tests" builds relationship.

Consider batch size: Reviewing 50 lines carefully is better than skimming 500. Small, frequent PRs enable better reviews.

The Comparison with Pairing

Martin Fowler observes: "The advantage of pair programming is its gripping immediacy: you apply review right at the moment that the code is created."

Code review has a delay - hours or days between writing and feedback. Pairing provides immediate course correction. But code review brings fresh eyes that weren't part of the original thought process.

High-performing teams often use both: pairing for complex work, code review as a safety net, and solo work with review for well-understood tasks.

Glue Work: The Invisible Teamwork

What Is Glue Work?

Tanya Reilly defines glue work as the essential work that makes teams successful but often goes unrecognized:

Noticing when teammates are blocked and helping them
Reviewing design documents and asking clarifying questions
Onboarding new team members
Documenting processes and decisions
Setting up meetings between teams that need to align
Noticing when the team is building the wrong thing and raising concerns
Taking notes and sharing them to create shared understanding
Introducing coding standards and testing guidelines
Fielding questions from customers and stakeholders

This work is technical leadership - it requires deep understanding of systems, people, and processes. But because it doesn't produce visible artifacts like code, it's often undervalued.

The Glue Work Trap

Reilly describes a pattern where engineers who are good at glue work get trapped by it:

An engineer notices gaps and fills them - helping teammates, improving processes, keeping projects on track
They receive positive feedback: "You're so helpful! The team couldn't function without you!"
They believe they're on track for promotion
Promotion time comes. The people who wrote a lot of code get promoted. The glue person hears: "You didn't have enough technical contribution."
The suggestion: "Maybe you should become a project manager instead?"

This is particularly damaging because the glue work was often the highest-impact work available. The project succeeded because of it. But the reward system didn't recognize it.

Distributing Glue Work Fairly

Research shows that when non-promotable work needs doing, women volunteer 48% more often than men. Even more concerning: when managers need someone for "thankless work," they ask women 44% more than men.

This creates systematic career disadvantage. The solution isn't for individuals to stop doing glue work - it's for teams and managers to:

Track glue work explicitly: Put it on the board like any other work. Make it visible.

Distribute it deliberately: Don't let it fall to whoever volunteers. Rotate it or assign it fairly.

Value it in promotions: If your promotion criteria only reward code, you're incentivizing people to let important work fall through cracks.

Recognize it publicly: When a project ships, acknowledge who did the coordination, documentation, and relationship-building - not just who wrote the code.

This is still leadership: Despite the career risks, glue work is genuine leadership work. See the "Glue Work of Leadership" section in Leadership for why this matters. The key is making it visible, ensuring fair distribution, and balancing it with technical contributions.

Learning to Be Good at Everything

Reilly's colleague Polina offers this response when pushed toward more glue work: "Yes, I'm good at communication. I'm good at everything I put effort into. You should see me doing systems design."

This reframes the conversation. Being good at communication doesn't mean you should only do communication. It means you can be good at whatever you invest in. And the people who aren't doing glue work? They need to develop those skills too. They should be putting effort into communication, coordination, and collaboration - not offloading it to others.

Asynchronous Teamwork

The Distributed Reality

Many engineering teams are distributed across time zones. Even co-located teams often work asynchronously - different schedules, meeting loads, and focus preferences mean you can't assume real-time availability.

37signals, the company behind Basecamp, has developed principles for asynchronous teamwork that enable collaboration without constant interruption:

Principles for Async Collaboration

Writing over talking: "Writing solidifies, chat dissolves. Substantial decisions start and end with an exchange of complete thoughts, not one-line-at-a-time jousts."

Writing has advantages over synchronous communication:

It reaches people who couldn't attend the meeting
It serves future employees who join later
It forces clarity of thought
It creates a record for reference

Real-time as exception, not default: "Real-time sometimes, asynchronous most of the time." Synchronous communication has a place, but it shouldn't be the default. Most work doesn't require immediate response.

Protect attention: "The expectation of immediate response is toxic." When you expect instant replies, you force people to monitor channels constantly. This fragments attention and prevents deep work.

Give ideas time to develop: "Rushing to judgment, or demanding immediate responses, only serves to increase the odds of poor decision making." Complex problems deserve time for reflection.

Context matters: "Saying the right thing in the wrong place might as well not exist at all." Where you communicate is as important as what you communicate. Attach discussions to the relevant work item, document, or decision.

Meetings are last resort: "Five people in a room for an hour isn't a one-hour meeting, it's a five-hour meeting." The cost of synchronous communication multiplies with participants. Reserve it for when it's truly needed.

Building Async Team Culture

Daily check-ins: Brief written updates on what you worked on. Not for surveillance - for visibility and reflection.

Weekly intentions: Share what you plan to accomplish. Not a commitment to exact deliverables - a signal of direction.

Reduce channel noise: Don't expect everyone to follow every channel. Summarize important discussions for broader audiences.

Practice good writing: Your written words often represent you. Invest in clarity, structure, and consideration for readers.

Team Rituals That Build Cohesion

Retrospectives

Regular retrospectives create space to improve how the team works together. Effective retros:

Are psychologically safe (what's said in retro stays in retro)
Focus on systems, not blame
Generate concrete actions, not just discussion
Follow up on previous actions

Blameless Post-Mortems

When things go wrong, how you respond shapes team culture. Blameless post-mortems:

Focus on "How did our system allow this?" not "Who did this?"
Assume everyone was doing their best with available information
Look for systemic improvements, not individual accountability
Document learnings for future reference

Knowledge Sharing

Regular knowledge sharing builds collective capability:

Tech talks: Team members present on technologies, techniques, or interesting problems
Lunch and learns: Informal sessions over food
Documentation days: Protected time to write down tribal knowledge
Pair rotation: Systematic pairing across different parts of the codebase

Celebrations

Acknowledging wins builds team identity:

Ship parties for major releases
Shoutouts for helpful behaviors
Milestone recognition
Learning celebrations (not just success celebrations)

Who Engineers Work With

Product Managers

Product managers define what to build; engineers define how to build it. Effective collaboration requires:

Shared context: Engineers need to understand user problems, not just feature requirements
Technical input on roadmaps: Engineers can identify opportunities and constraints PM may not see
Negotiation on scope: "We can do A or B in this sprint, not both. Which is more important?"
Respect for different expertise: PMs aren't failed engineers; engineers aren't failed PMs

Designers

Designers shape user experience; engineers make it real. Bridges to build:

Early involvement: Include engineers in design discussions before handoff
Technical constraints as input: Engineers can identify where designs will be expensive or impossible
Iteration after implementation: Real products often reveal design issues that mockups don't
Appreciation for craft: Engineering craft and design craft are both valuable

QA Engineers

Quality is a team responsibility, but QA brings specialized expertise:

Shift left: Involve QA early in design and implementation, not just at the end
Test automation partnership: Developers and QA can collaborate on automation strategy
Bug triage together: Understanding severity and priority benefits from multiple perspectives
Respect the role: QA isn't about finding developer mistakes; it's about ensuring product quality

Operations/SRE

Operations keeps systems running; developers keep systems changing. Bridges:

You build it, you run it: Developers should understand operational reality
Runbooks and documentation: Make systems operable by people who didn't build them
Incident response together: Developers and ops working together resolve incidents faster
Feedback loops: Production insights should influence development priorities

Stakeholders

Non-technical stakeholders fund and use what engineers build:

Translate, don't condescend: Explain technical concepts without jargon or patronizing
Manage expectations honestly: Under-promise and over-deliver
Surface risks early: Bad news doesn't improve with age
Understand business context: Technical decisions exist within business constraints

Common Teamwork Anti-Patterns

The Hero Complex

One person saves the day through heroic individual effort. This feels good in the moment but:

Creates single points of failure
Prevents knowledge sharing
Burns out the hero
Teaches the team to wait for rescue

Fix: Celebrate team wins over individual heroics. Distribute responsibility.

Siloed Expertise

"Only Sarah understands the payment system." This is a team failure, not Sarah's achievement. Silos:

Create bottlenecks
Concentrate risk
Prevent vacation
Block collaboration

Fix: Deliberate knowledge sharing through pairing, rotation, and documentation.

Meeting Overload

When everything requires a meeting, nothing gets built. Signs of trouble:

Engineers have less than 4 hours of uninterrupted time per day
Meetings about meetings
Status updates that could be written
Everyone attends everything "just in case"

Fix: Default to async. Make meetings opt-in rather than opt-out. Record for those who can't attend.

Artificial Harmony

The team never disagrees - at least not openly. Beneath the surface:

Real opinions go unexpressed
Problems fester
Bad decisions go unchallenged
Resentment builds

Fix: Encourage constructive conflict. Model disagreement. Create safe spaces for dissent.

Blame Culture

When something goes wrong, the first question is "who did this?" rather than "how did this happen?" Blame:

Discourages risk-taking
Encourages hiding mistakes
Prevents learning
Erodes psychological safety

Fix: Blameless post-mortems. Assume good intent. Focus on systems, not individuals.

Building Teamwork Skills

For Individual Contributors

Practice vulnerability: Admit what you don't know. Ask for help before you're desperate. Share your mistakes and learnings.

Give credit generously: Use "we" language. Highlight teammate contributions. Attribute ideas to their originators.

Make space for others: In meetings, pause before speaking. Ask quiet people for their thoughts. Don't dominate discussions.

Volunteer for glue work occasionally: Onboard a new person. Write documentation. Facilitate a retrospective. Just don't let it become your only work.

Learn to pair effectively: Be a generous navigator who explains thinking. Be a responsive driver who implements well. Switch roles regularly.

For Tech Leads

Model the behaviors you want: If you want psychological safety, show vulnerability. If you want good code reviews, write exemplary ones.

Distribute opportunities fairly: Interesting projects, visible work, and growth opportunities should rotate, not go to the same people.

Track and value glue work: Make it visible. Recognize it publicly. Consider it in performance discussions.

Protect team focus: Absorb interrupt work. Batch status requests. Shield the team from organizational chaos.

Create learning opportunities: Pair senior with junior. Rotate people across domains. Fund training.

For Managers

Hire for collaboration: Technical skill matters, but so does the ability to work with others. Check references specifically about teamwork.

Build psychological safety deliberately: It doesn't happen automatically. Create conditions, model behavior, and address violations.

Reward team outcomes, not just individual output: If your incentive systems encourage competition over collaboration, you'll get competition.

Address collaboration failures: When someone consistently undermines psychological safety or refuses to share knowledge, that's a performance issue.

Enable team rituals: Protect retrospective time. Fund team events. Support knowledge sharing activities.

TL;DR

Psychological safety is the #1 predictor of high-performing teams - (Google's Project Aristotle) it means people can ask questions, admit mistakes, and challenge ideas without fear
"Disagree and commit" requires both parts - voice concerns fully before decisions, then support outcomes 100%; half-hearted execution causes decisions to fail regardless of merit
Pair programming catches defects as they're introduced - it transfers knowledge fastest and reduces WIP, but 4-6 hours is sustainable, not 8, and introverts need solo time
Watch for and fairly distribute "glue work" - onboarding, documentation, coordination is essential but often undervalued; track it explicitly and recognize it publicly
Default to async, use sync intentionally - writing reaches people who can't attend, creates records, and forces clarity; use synchronous for relationship-building, emotional topics, and breaking deadlocks