cote · January 24, 2023 09:55
diff --git a/gistfile1.txt b/gistfile1.txt
 Many of the high-performing teams I’ve seen pair across each role. There are always two people working on the same thing from product managers, designers, and developers. This practice increases work quality, educates and level-sets knowledge across the team, and builds trust and collaboration. Later on, pairing is used to spread your transformation throughout the rest of the organization by seeding new teams with people from paired teams.
 Pairing might seem ridiculous at first: you’ve just halved production and doubled costs. However, almost 20 years of study and results from enterprises that practice pairing prove that it’s an effective technique. For example, DBS Bank’s CEO, Piyush Gupta, describes the bank’s pairing policy, motivation, and strategic benefits:
 Mostly, we believe in pairing employees who need to be trained with others who are native to those capabilities; we have found this to be one of the most effective methods of transforming people. We hire people with the required capabilities and pair them up with the incumbents, and the result is that those capabilities are multiplied across the organization. This is rooted in the simple belief that in order to learn something, you must experience and practice it rather than hear about it in a classroom setting.
 To take a look at pairing, let’s use developers as an example. With rare exception, when programming, two developers always work together, following the maxim that two heads are better than one. Developers regularly rotate to a new partner, usually at least once a day. With two sets of eyes, quality rises and writing unit tests goes faster: one developer might write a unit test first followed by the other writing the corresponding code.
 Knowledge spreads quickly and developers end up teaching each other, not only senior to junior, but from junior to senior, as well. In fact, after a while, the team’s skills tend to level. Spreading knowledge across the team also improves risk management. A lone developer can’t build specializations, becoming the only one who knows how “their” part of the system works. This means that staff churn has less negative effect. It also reduces the type of “hero culture” that can lead to staff burnout and mistakes.
 “Part of the goal is to not have siloed knowledge,” says Matt Curry (then at Allstate), “So we’re kind of getting away from this world of optimizing for one person to show up on the scene and make everything okay.” Instead, he goes on, “Anybody on the team can make it okay or can get us over this barrier.” That’s a much more reliable team than a set of heroes with unique knowledge that only they can deploy to solve problems.
 As you begin to spread change across your organization, you rotate key developers out of existing teams into new teams. These developers seed the new team with knowledge, skills, and trust in the new process. As we discuss later, this is one of the key methods for scaling change beyond the initial teams.
	Many of the high-performing teams I’ve seen pair across each role. There are always two people working on the same thing from product managers, designers, and developers. This practice increases work quality, educates and level-sets knowledge across the team, and builds trust and collaboration. Later on, pairing is used to spread your transformation throughout the rest of the organization by seeding new teams with people from paired teams.
	Pairing might seem ridiculous at first: you’ve just halved production and doubled costs. However, almost 20 years of study and results from enterprises that practice pairing prove that it’s an effective technique. For example, DBS Bank’s CEO, Piyush Gupta, describes the bank’s pairing policy, motivation, and strategic benefits:
	Mostly, we believe in pairing employees who need to be trained with others who are native to those capabilities; we have found this to be one of the most effective methods of transforming people. We hire people with the required capabilities and pair them up with the incumbents, and the result is that those capabilities are multiplied across the organization. This is rooted in the simple belief that in order to learn something, you must experience and practice it rather than hear about it in a classroom setting.
	To take a look at pairing, let’s use developers as an example. With rare exception, when programming, two developers always work together, following the maxim that two heads are better than one. Developers regularly rotate to a new partner, usually at least once a day. With two sets of eyes, quality rises and writing unit tests goes faster: one developer might write a unit test first followed by the other writing the corresponding code.
	Knowledge spreads quickly and developers end up teaching each other, not only senior to junior, but from junior to senior, as well. In fact, after a while, the team’s skills tend to level. Spreading knowledge across the team also improves risk management. A lone developer can’t build specializations, becoming the only one who knows how “their” part of the system works. This means that staff churn has less negative effect. It also reduces the type of “hero culture” that can lead to staff burnout and mistakes.
	“Part of the goal is to not have siloed knowledge,” says Matt Curry (then at Allstate), “So we’re kind of getting away from this world of optimizing for one person to show up on the scene and make everything okay.” Instead, he goes on, “Anybody on the team can make it okay or can get us over this barrier.” That’s a much more reliable team than a set of heroes with unique knowledge that only they can deploy to solve problems.
	As you begin to spread change across your organization, you rotate key developers out of existing teams into new teams. These developers seed the new team with knowledge, skills, and trust in the new process. As we discuss later, this is one of the key methods for scaling change beyond the initial teams.