Feedback, Pairing & Knowledge Sharing

Strong teams actively spread skill and knowledge so that no single person is irreplaceable. They give feedback well — in code review and beyond — pair up to solve hard problems together, and deliberately avoid the bus factor: too much critical knowledge trapped in one person's head.

The thread running through all of these is resilience and growth. A team that shares freely gets better together and doesn't collapse when one person is out.

Picture a kitchen where every cook can run every station. If one calls in sick, dinner still ships. A team that has spread its knowledge has that same resilience; one where only one person knows the critical part does not.

Healthy Feedback

Good feedback — the code-review culture of Chapter 8, generalized — is specific, kind, and about the work rather than the person. It also includes catching and naming the good, not just the problems. Feedback isn't a synonym for criticism; it's information that helps someone improve, given in a way they can actually hear. Teams that give feedback well get steadily better; teams where feedback feels like an attack go quiet and stagnate.

Pair & Mob Programming

Pair programming is two developers working together on one problem at one screen — one typing, one thinking ahead, swapping often. Mob programming extends that to a small group. It looks like "two people doing one person's job", but it trades short-term speed for fewer bugs, better solutions, and — crucially — shared knowledge, since two people now understand the code. It's teaching and building at the same time, especially valuable on the hard or risky parts.

Knowledge Sharing

Beyond pairing, teams share knowledge deliberately: writing things down (the documentation covered earlier in this chapter), giving informal talks, mentoring newer members, and rotating who works on what so expertise spreads. The aim is that no critical area is understood by only one person. Knowledge that lives only in one head is fragile; knowledge that's been shared, written, and taught is durable.

Bus Factor

The risk all of this guards against has a darkly memorable name: the bus factor — how many people would have to be "hit by a bus" (or, less dramatically, quit or go on vacation) before a project is in serious trouble. A bus factor of one means a single person holds critical knowledge nobody else has: a glaring single point of failure. Raising the bus factor — making sure at least two people understand everything important — is exactly what feedback, pairing, and knowledge sharing achieve.

On Cadence, only Marcus truly understood the reminder scheduler — a bus factor of one, and a real risk. So he pairs with Lena for a week, building and explaining as they go. Now two people can fix it, and the key parts are written down. The scheduler isn't a landmine anymore: if Marcus is on vacation when it breaks, Lena can handle it. That's the whole point of sharing knowledge.