[Book review] Joy, Inc.: How We Built a Workplace People Love

I was thinking of the way to make the working environment joyful and I was looking for books for that too. Then I read a book. The title is "Joy, inc." (English version / Japanese version). The reason why I chose this book is I just liked the title.

I was lucky because this book includes lots of practical hints. In this blog, I'd like to introduce the summary of this book I want to try in our company.

My impressions of this book

This book is totally about Agile best practice. It was translated into Japanese the last year so I read it recently but it was published in 2015. So the practices that it introduces are so so old, but it's still practical. And interesting as a novel.

There is one difficult point. I understand this author tried to introduce with as common way for any industries as possible (doesn't clarify it's Agile so to adapt to any industries) but I'm not sure these practices can work in the other industries than IT, especially "Pair work".

Summary of the practices for Joy

Firstly, he defines the joy like this. As far as we work in the industry to produce something, I strongly agreed with his opinion.

Creating compelling products that are used and appreciated by those for whom they are intended, while elevating the spirits and well-being of a hard-working team.

In summary, I think this book says these points in order to give the joy in the working environment. (It introduces more practices but they were just the Agile practices and I didn't think the practices for Joy.)

• Pairing (pair programming)
• Remove walls physically
• Keep learning
• Frequent conversation and communication
• Put the right person on the bus and drop the incorrect person from the bus

I introduce more detail and what I want to try in our company next.

Pairing (pair programming)

The company of the author, Menlo Innovations, is the software company so "Pairing" is obviously talking about pair programming. In pair programming, 2 programmers use one keyboard and one PC. For me, this is the method that we sometimes do (only the afternoon of Wednesdays for example).

But in Menlo, surprisingly, they always work with pair programming. Not only programming but also, all works are done by a partner. And they change the partner every week. This looks like making the productivity half but he shows many advantages for joy.

• Can learn something new from the partner
• Can know well each other (and causes good teamwork)
• Make it easy for new members to get accustomed to the environment
• No knowledge that only one person knows
• Can challenge aggressively (because the partner can help if a trouble happens)

Remove walls physically

In America, if they promote to "higher" position, they can get the private room at the office generally. This book strongly denies. It says all members of the same project should work in the same space.

Of course, this is for communication. If they work physically closely, they can make the conversation easily and frequently. So it can make the good teamwork. But one more purpose is that this kind of environment can occur the serendipity encouraging the unexpected conversation. And it may occur the new idea. They don't want to lose its chance.

Keep learning

The biggest leaning engine here is Pairing. They can learn from the partner and they must learn for the partner.

One more interesting activity for learning is "learning lunch session". They hold this event at least once a week. There is one teacher for each session. A teacher decides the theme related to the actual projects and talk using a whiteboard or something. The other members can listen to them eating lunch (I don't know when a teacher can eat lunch though).

They choose many types of topics such as very specific technology, brainstorming, how to give an attractive presentation, how to make a logical document, project management and so on.

Sometimes, they invite external people including students! Then they contribute to the community as well.

Frequent conversation and communication

Like I wrote till here, they have some system to encourage the frequent conversation or communication. Pairing, all project members work in the same space and learning lunch session.

But they have more opportunities for further communication.

• Daily standup
• Show & tell
• The work authorization board

Daily standup

This is very simple. All members gather in one place standing up and each pair shares what they are doing and informs if they need the help. This is finished within 13 mins. The sign that a pair speaks is to receive Viking helmet from someone. Our company also has the habit of daily standup but I thought it's also a good way to have such playfulness.

Show & tell

This is a so-called demo in the Scrum process. A development team shows the things they developed to a customer. But the interesting point is that a customer explains and development team members listen. In this way, development team members can know how a customer use their product and what a customer understands. Of course, our company also does a demo at the end of a sprint but I thought this is interesting.

The work authorization board

This is a so-called Kanban method. This is the board to show ToDo, Doing and Done of each task of each pair. An interesting way is they show it on the wall of their office and anybody (including customers) can understand who is doing what and delaying or not.

It is a difficult point for a company to choose a manual or a digital way. In our company we use Trello. This is a digital way. The advantage is anybody can see it anywhere anytime. They didn't choose its way and chose a manual way. The advantage of their way is they can know the current situation very quickly. If we choose a digital way, we need to open PC, make it online and open an app or website. But if the information on the wall shows everything, we don't need to do them all. Ummm, the best way for me is to show Kanban on Trello on the big screen?

Put the right person on the bus and drop the incorrect person from the bus

This sentence looks like it doesn't make sense but it's about recruitment. Recruitment affects the culture directly so they are very careful to define the process. And I thought their process is very different from the general companies.

Their main concept for the recruitment is like this.

• They don't need lone genius but want excellent team players.
• The culture matching is the most important.

For them, recruitment is not a continuous event but they hold the group interview about 2, 3 times a year collecting 30 - 50 candidates. Their process is like this.

1. Send the document and the detailed white paper about Menlo to candidates in advance.
2. In the first round of the group interview, candidates make pairs with members of Menlo.
3. Each pair works together, mainly they make the estimation of the dummy application. At that time, an existing member is in charge of MC and the other members are checking their activities.
4. They repeat the similar things 3 times with different partners.
5. After the first round, they email to inform the feedback and send their recommending book.
6. In the second round, candidates work the whole day (of course with a partner). What they have to do is to work on the actual project of a customer. At that time candidates make a contract to get the salary for one day. And a customer knows that candidates work at that time. It should be difficult for candidates to show the actual result but the point they evaluate is if they can ask or learn with curiosity or not.
7. Passed candidates are invited to the trial term of 3 weeks.
8. If they pass it, they will be the official member of Menlo

The reason why they choose a group interview style is the existing members don't need to spend a long time on the selection process.

What I thought interesting is they focus on "working" in the actual style with the existing members. This way is specialized to check the culture matching, I think.

If you liked this article

Let's subscribe the updates of Scuti!

Share on Google Plus

About Tomohide Kakeya

This is a short description in the author block about the author. You edit it by entering text in the "Biographical Info" field in the user admin panel.