It’s difficult to imagine a more oxymoronic scene: software developers, the quintessential standard bearers of introversion and of being most content working in isolation, joyfully thriving in an environment in which they work in pairs, each pair at one computer—two people engaged in one task, constantly interacting with each other.
Yet that’s precisely the scene that’s played out every day at Menlo Innovations, a software company in Ann Arbor, Mich. I wrote about Menlo last week, following an interview with Richard Sheridan, Menlo’s CEO and “Chief Storyteller,” and author of the forthcoming book, “Joy, Inc.: How We Built a Workplace People Love.” In that post, I focused on the unorthodox nature of the workplace at Menlo, one in which everybody works in a big room together, and no employee reports to any other employee. But there’s more to the story, and it has to do with this whole idea of working in pairs.
It’s probably not too much of a stretch to say that software developers are generally seen as having a personality type that thrives in a lone, nose-down working situation, one where interaction with other people isn’t needed. Is all of that just a myth? Sheridan addressed the stereotype:
I’m going to throw out a couple of facts about Menlo to make sure they’re clear. Only about 50 percent of our team are software developers. Just like building a house requires a lot more than carpenters, plumbers, and electricians, building great software requires more than programming. It requires design, quality assurance, project management, and so on. So everybody on our team who’s doing project work, works in pairs—not just our programmers.
The other thing is, just through pure self-identification, this question of introversion vs. extroversion comes up all the time. The tradition, history, and even mythology of our industry is that programmers love to work in what I call “sensory deprivation chambers,” with ear buds in their ears, silently clicking away on keyboards at three in the morning. That’s kind of the stereotype of our industry. Unfortunately, that stereotype leads many in our profession to great loneliness, great isolation, great separation from understanding what the larger goals are for the project. It leads to big problems in a lot of software companies, because of this isolation, separation and loneliness. And we don’t have that. Everyone’s working together as a team. What we are not, interestingly, is we are not a team of extroverts. In fact, most of our team will self-identify as introverts. What I’ve come to learn, and I’m not a student of extroversion vs. introversion—there are a lot smarter people than me on this subject—is that just looking at human nature and the anecdotal evidence that I’ve collected over 14 years of watching this work, introverts actually make a system like this work, because introverts prefer fewer deeper relationships with other people, and in our world, they don’t have those. You and I are working side-by-side, together, trying to achieve a common goal, discussing that goal together.
Sheridan noted that although it’s rare, Menlo isn’t the only software company that pairs programmers. He also said that although Menlo has very few rules, one of the strongest is that no one can write one line of production code unless his pair partner is sitting at the computer with him:
So you and I are almost isolated in our pair, because we’re heads-down, we’re focused on the work together, we can dive in, we can think deep thoughts. Perhaps the biggest difference at Menlo is that when we’re thinking those deep thoughts, we are encouraged to think them out loud, to talk them through, so our pair partner can hear what’s on our mind. That, intriguingly, crafts some very interesting debates, explorations of different approaches, greater innovation, creativity, imagination, and much higher quality. The quality goes through the roof in an environment like this. There are a whole bunch of people with theories on quality practices that look at what we’re doing, and they’re just blown away by its efficacy and its simplicity.
I asked Sheridan how Menlo’s retention rate compares to that of other software companies. He said it’s not something he’s focused on:
We’re not building dependence on individual heroes—that’s not a goal, nor something we tout, in terms of hey, we have an incredibly low attrition rate. People do come and go, for a variety of reasons. You can imagine this isn’t the right environment for everybody, so they’ll leave because of that. We aren’t the best payer in town, so someone who is focused strictly on wanting to make the highest amount of money may leave. That said, we have a lot of people who leave and come back. We have a lot of boomerangers, so it would be hard for us to measure retention, because we have people who, for whatever life reason, have decided to leave Menlo, and then one day they decide to come back. And we embrace both directions.
Finally, I asked Sheridan if there are any other myths that need to be dispelled. His response:
One of the grandest misconceptions in my industry is that software development requires library quiet in order for it to be effective. I can tell you, I’ve been in this industry now for about 42 years, in one form or another. For two-thirds of it, I worked either as a programmer, or was leading teams of programmers in that more traditional, quiet environment with private offices and doors that close; and then the last 14 years in this environment. I can tell you that I have witnessed for 14 years direct evidence that, with a wide range of people and projects, software development thrives in an energized, noisy atmosphere like we have at Menlo. And it’s because the focus is on the work, and the noise is about the work. So there is this element of serendipity that occurs in our noisy, energized environment that leads to greater results because people are actually overhearing the ideas of others while they’re working together.
Sheridan stressed that the team works shoulder-to-shoulder by choice:
If you’ve seen pictures of our space, you see the tables are pushed together, and the team is not only working in pairs, but they’re working shoulder-to-shoulder, together. What’s really important to understand is the team has total control of how the space is laid out. They decide where they want the tables to be—there’s no permission to ask, there are no facilities people to check in with. The team has total autonomy over the space. Throughout our existence, they have chosen to push the tables that close together. They want to be that close to one another.