A colleague and I had a conversation about moving developers between teams, and associated worries about causing disruption and losing knowledge / expertise.

I told the colleague about the book I was reading – Joy, Inc by Richard Sheridan, about a company in America called Menlo Innovations. Richard describes how at Menlo, they can easily move engineers between projects with minimum disruption. This is because they are used to pairing and knowledge sharing, they all adopt the same working practices, and no one person has code-base knowledge that isn’t shared by others.

Below are some extracts from the book that I think are relevant to this conversation. The basic premise is that pairing, a culture of learning and a focus on joy in the workplace all help to ensure that there are no towers of knowledge or lone genuises, and everyone can easily switch from one team to another.

I should add that I emailed Richard to ask for his permission to post these extracts, and he was extremely helpful.

Joy, Inc. excerpts are Copyright 2013, 2015 by Richard Sheridan. Used with permission. All Rights Reserved.

Chapter 12, Scalability (starts p194):

Brooks’s law is the motto of a broken hero-based culture that still largely exists in software development today. It states that the onboarding cost of a new person, particularly to a late project, far exceeds the potential contribution of that new person within the first few weeks or months of joining an effort. If a project is already late, then adding someone to it will make it later. The only alternative to a missed deadline then is an eight-hour-per-week death march for the current team.

… If you have no systematic means of transferring knowledge in a way that can quickly lead to mastery and autonomy for the new person, Brooks’s law applies to you, too.

…At Menlo, we have defeated Brooks’s law so many times that its premise is but a faint reminder of a quaint time in our industry’s history. Our entire process is focused on breaking this law. Pairing, switching the pairs, automated unit testing, code stewardship, non-hero-based hiring, constant conversation, open work environment, and visible artifacts all topple Brooks’s assertion with ease.

…Our pairing system, particularly the part where we switch the pairs every week, gives us a chance to practice scalability even when we don’t need it. We borrowed this concept from the airline industry (there it is called cockpit resource management). By switching pairs every week, we practise onboarding a new team member into a project even if the project stays the same size. We also practise onboarding new team members by bringing in four to six international interns annually.

…As the basic planning and coding practices are consistent across all projects, there is no need to train these new team members in any project-localized or personality-based methodology. The fact that everyone on the team has a shared belief system in our approach ensures there is no friction around these shifts in project assignment.

…Because the team is not based on towers of knowledge, because no one developer owns part of the code, because everyone has been working in all sections of the code, and because the people who have moved to another project are still in the same room and within eyeshot and earshot of one another, there is no meaningful loss of information about the project.

…How does a team get back up to speed when the project has been placed on the back burner for months at a time? … This falls back to documentation and standard work process. The automated tests provide the first foundation. They catch misunderstandings as new coding changes happen. If a programming pair returns to the project, makes a change they believe is okay, and one or more of the unit tests fail, the automated tests inform the programmers immediately that a mistake was made. This begins to refresh their memory of decisions made in the past. Code stewardship is also a big part of this, as the code has been viewed and adapted by so many different people over time that it has evolved into a body of work that reflects a commonly understood expression of intent, not a convoluted expression understood only by the hero originator and no one else.

…At Menlo, we measure cost against the final product: joy. We want the end users of our work product to thank us someday and tell us they love what we created for them. Most software teams never even get close to this effect. Can you measure something as intangible as joy? Perhaps not exactly, but you can measure usage, long-term quality, market share, customer satisfaction, market dominance, end user delight (at least anecdotally), and a lack of support calls. If we establish the team’s accountability to get these kinds of results every time, we get to joy.

Chapter 3, Freedom to Learn:

p52:

Assigning pairs and switching them each week helps avoid a variety of typical team ills that could interfere with learning outcomes. For example, it prevents team members from feeling alienated by another team member who may not have a particularly outgoing personality. It may not be a personality problem at all, just normal human shyness. We avoid cliques forming, as everyone gets a chance to work with one another.

We’ve found that people are more likely to engage in a casual pop-up conversation with others whom they’ve previously paired with for forty hours. This time spent together dispels a lot of misconceptions about one’s fellow teammates. Once you spend forty hours in conversation with another human being, you are going to get to know that person in a deeper way than a general impression could ever accomplish.

Working in pairs also provides an emotional safety net for our employees. As much as they are stretching the boundaries of what they know, they are also testing the edges of what is ‘safe’ in a work environment. When a new technology or process or domain is introduced, there’s always the prospect of fear creeping in, a natural human response to the unknown.

Imagine a six-year-old child on an unfamiliar walk near the edge of a deep, dark forest. The child will stand frozen and frightened, unable to move forward. But place an equally frightened six-year-old friend beside him and together they may confidently travel this unknown space together, hand in hand. Just like the buddy system we learned in childhood swim classes, pairing helps us move into the unknown with confidence and courage, comforted by the safety such a system provides.

p58:

We don’t tolerate towers of knowledge or lone geniuses at Menlo

p59:

The hidden benefit of giving your team members the freedom to learn is that, eventually, they will embrace the idea of taking the time to teach. Knowledge isn’t kept away in secret personal vaults like the crown jewels of little kingdoms. The workers on your team become more valuable as they learn new practices; they also become more flexible. Some conclude that this diminishes each team member’s unique value and turns each one into a cog in our little software factory machine. Usually, in the very next breath they tell us how amazingly valuable each of our team members is because of his or her mastery of so many different technologies and domains. This can happen only when you truly believe your team members are equally valuable and equally able to learn and carry certain knowledge.

Pairing is the atomic element of our learning organization. It produces a joy in learning that most of us haven’t experienced in years, perhaps since elementary school, when everything was new and all we had to do was absorb it.

Joy, Inc. excerpts are Copyright 2013, 2015 by Richard Sheridan. Used with permission. All Rights Reserved.

• Agile
• Pairing