Every team I have watched succeed had the same unglamorous thing in common: a plan they believed in, roles they understood, and enough trust in each other to execute without looking over their shoulder. Everything else — the rituals, the metrics, the org chart — is scaffolding around those three.
A team is a system, not a collection of people
Start here, because almost every mistake downstream comes from getting this wrong. A team is not a group of individuals who happen to share a repository; it is a system whose output depends more on the connections between people than on the people themselves.
Three things have to be true at once for that system to work:
- Vision — a picture of where this is going that is specific enough to disagree with. "Be the best" is not a vision. "In eighteen months a customer can self-serve everything they currently email us about" is.
- Roles — not job titles, but a shared understanding of who decides what. Ambiguity about ownership is the single cheapest way to make smart people slow.
- Purpose — the answer to why this particular person should care about this particular work. Purpose is individual; vision is collective.
Notice the dotted line. Trust is not an input you can install at the start — it is produced by executing together and then fed back in. Which is why new teams feel slow and mature teams feel telepathic.
Tom DeMarco and Timothy Lister named the end state in Peopleware back in 1987: the jelled team, a group that has become greater than the sum of its parts — shared identity, joint ownership, low turnover, and people who genuinely like showing up. Their most useful claim is a negative one. You cannot make a team jell. You can only create the conditions that permit it, and stop doing the things that kill it.
Business is not like sports. It is like healthcare.
The sports metaphor is everywhere in management, and it is mostly wrong. It smuggles in assumptions that do not survive contact with a real company: a season with a defined end, a scoreboard everyone agrees on, a bench full of substitutes, and the freedom to trade anyone who underperforms.
A better analogy comes from medicine. In 2011 the surgeon Atul Gawande gave a Harvard Medical School commencement address published as Cowboys and Pit Crews. His argument: medical training was designed for a world where knowledge was scarce, and it produced the autonomous, self-sufficient expert — the cowboy. But medicine's complexity long ago outgrew any individual, so outcomes now depend on coordination rather than brilliance. His line is blunt: "We train, hire, and pay doctors to be cowboys. But it's pit crews people need."
Software has exactly the same problem: we recruit, interview, promote and mythologise the individual, then hand the work to a system that only rewards the collective.| Sports | Healthcare | Software | |
|---|---|---|---|
| Time horizon | A season that ends | Continuous, no off-season | Continuous, no off-season |
| Scoreboard | Unambiguous and public | Contested, lagging, partial | Contested, lagging, partial |
| Roster | Fixed squad, bench, transfers | Whoever is on shift tonight | Whoever is on the team this quarter |
| Failure mode | You lose a match | Someone is quietly harmed | Something quietly rots |
| Best practitioner | Wins the game | Makes the system work | Makes the system work |
Gawande also concedes something worth sitting with: the values that make pit crews work "are the opposite of autonomy, independency, self-sufficiency" — the very traits our hiring processes select for.
You adjust the strategy to the players, not the players to the strategy
Every coach worth anything does the same thing: they look at who they actually have and build a plan those people can execute. The reverse — designing the perfect strategy and then complaining the team cannot run it — is not leadership, it is wishful thinking with a deadline.
This runs headlong into the most popular doctrine in tech management: hire only A-players, and remove everyone else. The trouble is that it defines "A-player" as a fixed property of a person, when in practice it is a property of a person in a context. The same engineer is a star in a system that plays to their strengths and a liability in one that does not. Fred Brooks's The Mythical Man-Month made this structural in 1975 with the surgical team — an idea he credits to Harlan Mills — where roughly ten people are organised so that one does the cutting and the rest exist to multiply that person's output. The insight is not "find a genius." It is "shape the roles around the people you have."
A coach does not get better players; a coach gets more out of the players they already have.Software makes this harder than most fields because of three idiosyncrasies:
- The work is invisible. You cannot watch someone think. Managers who need to see effort end up rewarding its performance instead.
- Output is not proportional to input. A well-placed deletion can be worth more than a month of features, and nothing in a spreadsheet will tell you that.
- There is no bench and no off-season. You improve the team while it is running in production, with the same people, this quarter.
You always get the behaviour you reward
In 1975 Steven Kerr published On the Folly of Rewarding A, While Hoping for B in the Academy of Management Journal, and it remains the most useful twelve pages in management. His examples are brutal: orphanages whose stated goal is placing children in homes, but whose eligibility rules make placement nearly impossible; universities that say teaching is their purpose while awarding tenure for publication; vocational rehabilitation programmes paid per placement, which therefore compete for the easiest clients and avoid the people who need help most.
Kerr's diagnosis is that organisations gravitate toward criteria that are objective and easy to count, while the goals that actually matter are subjective and hard to measure. So they measure the countable thing and quietly get it.
| What we say we want | What we actually reward | What we reliably get |
|---|---|---|
| Quality software | Shipping by the date | Features that ship and then bleed |
| Knowledge sharing | Individual heroics in incidents | Heroes who are indispensable and exhausted |
| Sustainable pace | Visible late-night effort | Performative overwork |
| Honest estimates | Estimates that come in low | Estimates that come in low, and are wrong |
| Code ownership | Volume of pull requests merged | Small, safe, low-value changes |
This is where the practical rule comes from. You cannot incentivise performance — performance is an outcome, and outcomes have too many authors — but you can absolutely incentivise behaviour, and behaviour is what produces performance. "Ship 20% faster" is a wish. "We celebrate the person who wrote the test that caught this" is a lever.
The corollary is uncomfortable: if a team is behaving badly, look at what the reward system is actually paying for before you look at the people. The Deming Institute traces to a 1993 seminar the line that a bad system will beat a good person every time — a recollection of spoken remarks rather than a published quote, but the point stands on its own merits.
What they need, not what they do wrong
Most feedback is a list of deviations from an imagined ideal. It is accurate, it is fair, and it changes almost nothing, because "here is where you fell short" gives someone a gap without giving them a route.
The reframe is small and costs nothing: instead of asking what is this person doing wrong, ask what does this person need in order to do this well. Sometimes the answer is a skill. More often it is context they were never given, a decision nobody made, or an obstacle they do not have the standing to remove — and all three of those are the leader's job, not theirs.
There is a distinction worth holding onto here: like is rational, love is emotional. You can reason your way into respecting a colleague — their work is good, their judgment is sound, the evidence is there. You cannot reason your way into caring whether the team succeeds. That part is emotional, it is built out of accumulated moments where someone had your back, and it is the part that determines whether people give the work their discretionary effort or merely their contracted hours.
Trust is what happens between the meetings
Here is the sentence this whole post is named after. Meetings are where a team performs its coordination; trust is built in all the hours nobody scheduled — the aside in a thread, the question asked without fear, the colleague who rewrites your paragraph instead of pointing out that it is bad.
The most important thing to understand about trust is that it is not the same axis as performance. Treating them as one variable — "good team / bad team" — hides the two failure modes that actually matter.
A brilliant and brittle team ships impressively and loses a key person catastrophically. A warm and adrift team is pleasant to be in and slowly becomes irrelevant. Both look fine on the metric you happen to be watching.
The best evidence here is Google's Project Aristotle, published as a re:Work guide on team effectiveness and popularised in Charles Duhigg's 2016 New York Times Magazine piece. Google expected to find that the right mix of individuals made great teams. It found instead that who is on the team matters less than how the team works together, and it ranked five dynamics in order of importance:
- Psychological safety — whether you can take an interpersonal risk without it costing you
- Dependability — members reliably deliver quality work on time
- Structure and clarity — clear expectations, process, and consequences
- Meaning — the work matters to you personally
- Impact — you believe the work makes a difference
Psychological safety was not merely first; it was the foundation the others rested on. The term comes from Amy Edmondson, whose 1999 study in Administrative Science Quarterly showed that psychological safety predicts learning behaviour, which in turn mediates team performance.
Her earlier hospital research produced the finding I think about most. Studying medical teams, Edmondson hypothesised that better teams would make fewer errors and found the opposite: units that agreed with the statement "if you make a mistake in this unit, it won't be held against you" reported more errors. Her explanation matters more than the headline — "better teams probably don't make more mistakes, but they are more able to discuss mistakes." The difference was in detection and reporting, not in the underlying error rate.
Which means a team with no reported incidents is not necessarily safe. It might just be quiet.
The rituals that manufacture trust
Trust may be emotional, but you do not build it by asking people to feel differently. You build it by creating repeated, low-stakes situations where being honest turns out to be safe. That is all a good ritual is.
| Ritual | Builds trust | Builds performance | Dies when |
|---|---|---|---|
| Peer review | it becomes a gate for assigning blame | ||
| Daily huddles | it turns into a status report to the manager | ||
| Hackathons | the output is expected to ship | ||
| Blameless postmortems | someone is quietly punished afterwards | ||
| One-to-ones | they are cancelled whenever things get busy |
Peer review deserves a specific warning. It is the highest-leverage ritual in software and the easiest to poison. A review culture where comments are about the code builds trust every single day; one where comments are about the author destroys it just as fast, and no process document will tell you which one you have. Read your team's last fifty review comments and you will know.
Data settles arguments about systems, not about people
The "data versus opinions" debate is usually framed badly. The question is not whether to measure, it is what measurement is legitimately for.
The DevOps Research and Assessment programme, known as DORA, is the strongest work here. Its classic four metrics — deployment frequency, lead time for changes, change failure rate, and time to restore service — pair two throughput measures with two stability ones, which is the whole trick: neither can be gamed without wrecking the other. (DORA has since evolved the set, renaming time-to-restore to failed deployment recovery time and adding a fifth, deployment rework rate.)
The finding relevant to this post is not about metrics at all. DORA reports that a high-trust, generative culture predicts software delivery and organisational performance, drawing on the sociologist Ron Westrum's typology from aviation and healthcare safety research, which sorts organisations into three types:
Culture is not the soft complement to the hard numbers. In this research it is the thing predicting the numbers.
The counterweight is SPACE — Satisfaction and well-being, Performance, Activity, Communication and collaboration, and Efficiency and flow — a 2021 framework in ACM Queue from Nicole Forsgren and colleagues, whose central claim is that developer productivity "cannot be measured by a single metric or dimension." Any framework reduced to one number becomes a target, and Kerr already told us what happens next.
So: use data to interrogate the system, and use conversation to understand the people. Measuring individuals with system metrics is how you get a team that optimises the dashboard and stops telling you the truth.
Teams that actually worked
Teams are not a management invention. Militaries and sports have organised them for centuries, and software has its own short, well-documented history of small groups that produced wildly disproportionate results.
The details are worth more than the legend:
- Unix. Dennis Ritchie's The Evolution of the Unix Time-sharing System names four people at the beginning — Ken Thompson, Ritchie, Doug McIlroy and Joe Ossanna. Management refused to fund them: "we were asking the Labs to spend too much money on too few people with too vague a plan." They got a machine by promising the Patent department a text-processing system. And Ritchie states the goal in social terms, which is the part everyone forgets — they wanted "not just a good programming environment in which to do programming, but a system around which a fellowship could form."
- Skunk Works. Kelly Johnson's 14 rules, still published by Lockheed Martin, are a management document disguised as an engineering one. Rule 1 gives the manager "practically complete control of his program in all aspects." Rule 3 insists the number of people be "restricted in an almost vicious manner." Rule 14 rewards good performance with pay "not based on the number of personnel supervised" — an explicit refusal of the incentive Kerr would warn about two decades later.
- Xerox PARC. The Computer History Museum records that Bob Taylor, running the Computer Science Laboratory, held informal meetings in a beanbag-furnished room where staff presented new ideas and received "frank and sometimes brutal feedback from their colleagues." Brutal critique and psychological safety are not opposites — the safety is what makes the critique survivable, and therefore useful.
- Apollo. Margaret Hamilton led the Software Engineering Division at MIT's Instrumentation Laboratory, which built the onboard flight software for the Apollo Guidance Computer. Her priority-scheduling design is the reason the 1202 alarms during the Apollo 11 descent did not end the landing: the computer shed lower-priority work and kept the guidance running. She received the Presidential Medal of Freedom in 2016.
Be the leader you never had
Most people learn leadership by inheriting it. You get promoted, you copy whoever managed you, and if you were unlucky that means transmitting the same damage down another generation.
The alternative is to treat it as a discipline you study rather than a rank you receive. Read the research. Notice what worked on you and what merely happened to you. Write down what you believe about how people should be treated at work, then check your calendar and your last round of promotions against it — the gap between the two is your actual leadership philosophy, whatever the document says.
I am aware this is idealistic. I think that is the correct posture. The cynical position — people are interchangeable, culture is decoration, only output counts — is not more realistic; it is just cheaper to hold, and it reliably produces the teams it predicts.
You cannot make a team trust each other, but you can decide what gets rewarded, what gets protected, and what happens in the hours between the meetings — and that turns out to be most of the job.References
- Ritchie, Dennis M. — The Evolution of the Unix Time-sharing System (1979/1984)
- Johnson, Kelly — Kelly's 14 Rules & Practices, Lockheed Martin Skunk Works
- Computer History Museum — Xerox PARC and the Alto
- Brooks, Fred — The Mythical Man-Month, ch. 3 "The Surgical Team" (1975)
- MIT News — Apollo code developer Margaret Hamilton receives Presidential Medal of Freedom (2016)
- Kerr, Steven — On the Folly of Rewarding A, While Hoping for B, Academy of Management Journal 18(4), 1975
- Gawande, Atul — Cowboys and Pit Crews, The New Yorker, 2011
- Google re:Work — Guide: Understand team effectiveness (Project Aristotle)
- Duhigg, Charles — What Google Learned From Its Quest to Build the Perfect Team, NYT Magazine, 2016
- Edmondson, Amy C. — Psychological Safety and Learning Behavior in Work Teams, Administrative Science Quarterly 44(2), 1999
- Edmondson, Amy C. — The Intelligent Failure That Led to the Discovery of Psychological Safety, Behavioral Scientist
- DeMarco, Tom & Lister, Timothy — Peopleware: Productive Projects and Teams (1987)
- DORA — DORA metrics and Generative organizational culture
- Forsgren, Nicole et al. — The SPACE of Developer Productivity, ACM Queue 19(1), 2021
- The W. Edwards Deming Institute — A bad system will beat a good person every time