EN
Back to the archive

The archive · Work & Ways of Doing · Operational decision · 2001-2020

Menlo Innovations runs a software firm on pair programming: new partner every week

Since 2001 every Menlo employee works in pairs with a new partner each week - one keyboard, shared context, and a culture built on joy instead of fear.

Menlo Innovations

The ideaMake paired programming the company-wide default - two people, one workstation, partners rotated weekly - so knowledge never lives in one person.substantial

What it had to solve

Menlo Innovations was founded in 2001 by Richard Sheridan and James Goebel, who had both loved working as a pair and decided to systematize it across the whole company. Their mission became 'to return joy and end human suffering in the world as it relates to teams and technology', on the belief that fear kills joy.

How it works

Menlo Innovations was founded in 2001 by Richard Sheridan and James Goebel, who had previously worked together as a pair and loved it so much that they decided to make pairing the entire operating model of their software company. The stated mission became 'to return joy and end human suffering in the world as it relates to teams and technology', and the culture was deliberately built to make people feel safe - as the company puts it, fear kills joy.

Mechanically, everyone at Menlo works in pairs at a single desk with one keyboard and mouse. Partners are re-assigned at an open scheduling meeting each Friday, and project managers keep one developer on a project across weeks so context passes on without documentation. The office is organized into open 'pods' so adjacent pairs overhear each other, and the whole company attends daily 15-minute standups with weekly sprints.

The pairing extends beyond programming: designers and quality advocates pair as well, and Menlo developers pair with client developers on joint projects. When a client needs faster delivery, a pair can be split into two pairs instead of scaling headcount. One developer described the effect as never getting stuck alone, and the company keeps newcomers on 'first date behaviors' - constantly learning to work with anyone.

Menlo argues the model pays for itself in quality: two brains and an extra set of hands produce fewer mistakes, get things right on the first try, and catch errors early. Knowledge spreads by rotating partners, so a project never depends on a single person, and the practice has been exported through tours, workshops and Richard Sheridan's book 'Joy, Inc.'

Why it lands

  • Weekly pair rotation forces knowledge transfer, so no project depends on one person.
  • Sharing one keyboard keeps both partners engaged instead of one doing all the work.
  • Open pods and shared standups turn accidental overhearing into structured communication.
  • Pairing deliberately makes people able to work with anyone, which scales without drama.
  • Framing it as joy and safety, not surveillance, keeps people willing to work in the open.

What it did

The model spreads knowledge without documentation, removes the risk of knowledge living in one person, and lets teams scale by splitting a pair into two instead of onboarding. Around 60 Menlonians work this way, and the practice is taught through tours, workshops and Sheridan's book 'Joy, Inc.'

Their siteThe Menlo Way, on Menlo's site

What you can take

When quality depends on knowledge in one head, redesign the work so knowledge is shared by default: rotate partners, keep work visible, make psychological safety a design goal, not a slogan.

Since then

Menlo has run this model for over two decades with roughly 60 employees, and Richard Sheridan's 2013 book 'Joy, Inc.' turned the experiment into a widely discussed blueprint for humane software workplaces. The company teaches The Menlo Way through tours and workshops, and its ideas - pair programming by default, weekly rotation, open space - have been borrowed by agile teams worldwide. While full-company pairing remains rare, Menlo's claim that pairing pays for itself through quality is now a standard argument in software methodology debates.

Sources

spotted an error? The archive wants to know.

Your turn

You just read one. Describe the brief you are staring at, and see who has been given the same problem.

Free account · 3 free questions · no card

Related cases