A Company Based on Joy: My Review of Joy, Inc

I decided to try something new this week and do a review of the book Joy, Inc.: How We Built a Workplace People Love. Have you read other books related to happiness at work? Email me. I'd love to read them too!

The very first line of the book intrigued me: "Joy in business sounds ridiculous." It does sound ridiculous, right? Who uses the word joy to describe their office? And yet throughout the book, the author Richard Sheridan does an excellent job explaining how joy is at the root of everything done at his company, Menlo Innovations. 

Richard defines joy as "Joy is designing and building something that actually sees the light of day and is enjoyably used and widely adopted by the people for whom it was intended.” One thing I really like about this definition is how it counters the second scale of burnout: depersonalization. Being able to create things that are actually loved by people seems like a great way to counter cynicism and avoid burnout. 

I really appreciated how Richard explained the 'why' behind the processes at his company. Many chapters begin with anecdotes from Richard's working life at other companies and how they led to the processes at Menlo. Starting with why is one of my core principals and I liked reading the thought processes that led to the choices the company made.

One of the key practices at Menlo is that nearly everything is done in pairs or groups of people rather than individually. Every program is written with two people sitting in front of one computer, working together. Menlo explicitly does not want to have 'superstars' or 'towers of knowledge' in their company. If one person goes on vacation or leaves the company, there's no concern over losing knowledge or having to call an expert on vacation. Their paired partner can continue the work. 

I also find the project management system they use is fascinating. They track every project using physical index cards. Each task takes up a certain amount of physical space on the card depending on how long the programmers think the task will take. I thought this was a clever way to combat scope creep - you can't add more tasks to a project because there physically isn't enough space on an index card to keep adding tasks. 

I enjoyed reading this book and recommend it to others that are interested in a different take on how a software company can be run or those interested in a behind-the-scenes look at what a company based on “joy” can look like.