When visiting the Menlo office, one of the first things you’ll notice is that almost every computer is shared by two Menlonians working in pairs. This is how we do our best work. However, what’s less obvious is how we also pair with our clients. There are many reasons clients may choose to have us pair with their team. Some want to adopt Menlo processes like paired programming or visual management. Others use pairing as a way to prepare their team to take over long-term software support after a project ends. And in some cases, clients want to extend their budget while building capability within their own organization.
We recently completed a project with a client in the healthcare space that had a small team of developers that we paired with. This meant that our Menlo developers paired with the client developers daily. This client was local, so the developers were able to work with our team in-person. As we finished up the project, I sat down with one of the client developers over lunch (we got Ginger Deli, a great Vietnamese restaurant just down the street from Menlo!) to talk about their experience doing paired work with us. There were four main themes that came out of our discussion: The flexibility and seamlessness of working with Menlo, the quality of Menlo’s work, the emphasis on leading with joy instead of fear, and the value of Menlo’s processes.
Previous to working with Menlo, the client developer hadn’t experienced full time pair programming, so there was definitely a learning curve. However, once they got the hang of it, the benefits became clear. You always have another person looking over and discussing your work, resulting in much higher quality code (it’s like rubber duck debugging, but the duck can talk back!). Complex problems can be broken down and thoroughly discussed, meaning the best solution emerges more easily.
One idea that stood out was the value of communicating technical concepts out loud. Creating diagrams and drawing pictures to share technical problems with a pair partner is vital for ensuring both developers are on the same page. While taking the time to do this can initially feel slower, the shared understanding and collaboration pays off significantly in the long run.
Another idea that stood out to the client developer was Menlo’s philosophy of leading with joy, rather than fear. One example they gave of this was in how we estimate our work. At a previous job, developers were encouraged to estimate their work as low as possible. This was because they were assessed based on how quickly they could complete tasks. Famously, being forced to go as fast as possible to complete work does not give the best results. This resulted in lots of bad quality code that they frequently had to revisit and fix, as well as a glaring lack of documentation or testing.
At Menlo, they experienced the opposite. Developers are encouraged to give realistic estimates for their work, and if they’re wrong, there is no punishment. On the flip side, there is no “reward” for completing work ahead of an estimate, aside from being given more work. Developers are also encouraged to think about not just the code, but also how long it will take to do documentation, testing, and anything else that may go into that storycard. This helps the estimates to be more accurate. Taking the fear out of the room means better quality work, more accurate estimates, and an overall more joyful workplace culture.
One of the top things they felt Menlo brought to the table was our visual management processes, especially our weekly work prioritization tool called the Planning Game. The Planning Game (shown below) consists of 11x17 pieces of paper that each represent one pair of resources for the week, and all of the project storycards, folded based on their estimates. The client can physically plan out the work they want to authorize for the week, and clearly see when they have reached capacity for each pair.
.jpg)
They described how having everything on paper and so out in the open meant there was “no cheating”. No giant backlog of tickets where work always vanishes to, and no added scope without making tradeoffs. “You can see it, you can touch it, it doesn’t shift. If someone wants to make a change, you see that change.” Similar sentiments were shared about the Work Authorization Boards, our way of visualizing an iteration of project work. All the work that needs to be done during that iteration is displayed on a board on our walls, and nothing is hidden. Menlo’s visual management and well-practiced processes meant that they felt working with us was a seamless experience.
Daily rituals and meetings also felt meaningful. One “meeting” they experienced every day was our daily standup, a 15 minute, company wide meeting where everyone gathers in the kitchen and shares what they’re working on for the day. They felt this was really valuable for team building and staying aware of what’s going on around the company. You get a great sense of how other projects are doing and how you may be able to help. There’s also the added bonus of everyone introducing themselves every morning, allowing you to learn names easier.
I found getting an outsider’s perspective on how we do work at Menlo to be very valuable. It brings me a sense of joy to see how our work makes a difference to our clients—both to their end users and their team. Hearing about this developer’s experience was a great reminder that when a project ends, our clients walk away with more than just high-quality code. For this project, the client team was able to take the skills they learned, and continue pairing once the project ended!