At Menlo Innovations, everything is about pair working. That’s right: if you were working at Menlo, you would be assigned to a new partner every Monday, and you would spend the whole week with that partner. And you guys would share everything: the PC, the keyboard, the mouse, the lunch breaks… So how does that work exactly? And how is it profitable?
How did it all start?
Menlo was founded by Rich Sheridan and James Goebel. Both cofounders had already worked together as a pair, and they just loved this way of working. So when they founded Menlo in 2001, they decided to take it to the next level, and systemize it company-wide. Today, about 60 employees, called Menlonian, work as pairs.
So how does it work? A typical day at Menlo
Let’s say you just got hired at Menlo (their hiring process is pretty unusual too, we’ll write about that soon). You get in on Monday at, say, 8am. The first thing you do is head to the schedule board and find out what project you will be working on and who your partner for the week will be. This schedule has been thought out by the project managers and any other person wanting to participate to that meeting on Friday: the schedule is built by hand on Friday afternoon and emailed out to everyone once it’s done. Anyone who wishes to be a part of that can join in the meeting, anytime.
Because you’re the new guy, chances are someone will come up to you and introduce him-herself as your partner. Your partner shows you the pod where you will be working from. A pod is a group of table offices that are meant to be close to each other so that a pair working on one desk overhears what’s going on at another desk on the same pod. This makes room for spontaneous communication on different parts of one same project or on different projects for one client.
Your partner and yourself both settle at the same desk, where there is only one computer screen, one keyboard, one mouse. Don’t worry, that’s totally normal: while one of you does the coding, the other one discusses the plan, keeps track of where they are… There are different ways to make it interactive. Some pairs use the “ping pong method”: person A writes the test and person B codes. And then, you switch: not one person types all day while the other one is merely looking over the partner’s shoulder. There aren’t really any standards, the main idea is that both partners have to be engaged.
It’s a natural flow that kind of works out between you and your partner - Nathan, developer at Menlo
What if one morning you get stuck in traffic and turn up late? Even in this case, your partner does not work without you. Your partner will find chores to do until you’re at work: bits and pieces of IT work to do here and there, bookkeeping, entering timesheets, kitchen cleaning...
And if you call in sick for a couple of days? You’ll tell your partner you can’t make it, and your partner will work out with the project managers what he/she can do on other projects until you’re back on your feet.
Developers not only program in pairs, they do everything else with another coworker. The rest of the staff works in pairs too: designers, quality advocates… Even project managers, who usually work alone, can pair strategically for certain tasks.
This involves a thorough company-wide organization that relies on the agile method and the role of the project manager.
Let me guess your next question: how do project managers make sure the knowledge developed by one pair during one week on a specific project doesn’t go away when a new pair is assigned to take on the following tasks? This is where the project manager intervenes. On their Friday meeting, when building the schedule, they can keep one developer, let’s call him person A, who worked on the previous week with partner B on the project, on this same project, and assign a new partner, partner C, for the next week. This way, person A can explain the context, what was done, and keep track of the developments to make sure the work done from one week to the next is consistent.
As for specific task management, the agile method is used. Within an average of 32-hour weeks, daily 15-minute standups are organized company-wide. A bell rings and the whole company attends. You’ll give out your name, the project you’re working on, the task you’re doing, and you can ask for some extra help if you need it. Projects are paced by weekly sprints.
Let’s take a month-long project as an example. A pair composed of developer A and developer B launch the project, meaning that they will break it down into storycards. This breakdown has to be validated by the client via a Work Authorization Board, as well as all the other weekly adjustments that can be foreseen during the retrospectives and planned during the sprint planning.
The benefits for Menlo as a whole
A huge benefit that comes from this specific way of working is knowledge transfer. For example, a new project just started for a client who wants an IOS app . This means developers working on the project will have to code using the Swift language. Project managers identified a pool of developers who already have that skill, and partner them up with a developer who doesn’t. As partners rotate on the project, knowledge spreads. This means that it also avoids the operational risk of concentrating knowledge on just one person.
It also saves time: if person A worked on the project last week, there is no need for documentation. Person A just passes along the information that needs to be passed on for the project to develop.
Pairing enables the firm to be more responsive. You can easily scale a project by splitting one pair (A and B) that has worked on a project into two pairs (A and C, B and D) in case the client needs a delivery earlier than expected for instance.
The benefits for coworkers
The pairing process is used to spread knowledge and experience, by pairing someone who has been there for a while with a newcomer.
it was very refreshing, you don’t get stuck when you’re paired with somebody like you do when you’re developing alone […] I was tired of googling stuff - Helen, programmer at Menlo
But one of the major benefits is the fact that being systematically paired forces you to be able to work with anybody. It’s a way of growing this skill. Let’s say you want to grow a specific skill: learn to code in a new language. You can request to be paired with someone who has that expertise. This means that you’re constantly switching between learning and teaching.
We keep people on their first date behaviors - A Menlo saying
Of course, this can be tiring. Helen, whom we interviewed for this article, was exhausted during the first month. But through time, she noticed that she got used to working with different people until it became natural.
And if you’re having a bad day, or even a bad week (that’s just part of being a human), it’s a relief to know that you can rely on a partner. If you’re both having a bad week, well at least you’re not alone and you can figure out a way to make it work better together. All in all it holds you accountable and gives you support.
Is it profitable? The benefits for the client
And of course, for the client, having two brains and an extra set of hands working on a project instead of one increases the quality of the code. Less mistakes are made. Pairing means higher quality code. This comes with a higher price tag for project development. On the other hand, they save time by avoiding mistakes and by usually getting it right on the first try. They also avoid mistakes not being found for months: a pair taking over makes a check of the work done the previous week.
But that’s not all. Menlo developers also pair with their clients! One programmer from Menlo and one programmer from the client firm can pair together: this fosters close connections with their clients as well as knowledge transfer. Some clients wanted to learn from Menlo how to test before coding for example.
Menlo managed to make it a proper business model: their clients are partners, who can buddy up with Menlo programmers to gain knowledge and who know how Menlo works. A lot of clients come from referrals and there are often repeat clients.
