Last year I met Rich Sheridan, CEO and Chief Story Teller of Menlo Innovations and author of Joy, Inc. I heard him speak at Agile Singapore and got to interview him and Linda Rising together after that conference.
Both of their presentations from that conference can be viewed here. Linda’s interview of her visit to Menlo can be found here.
I found his story inspiring and wanted to hear more – does the company really operate that way, is there really a culture of joy in the workplace, are teams really that empowered and are management really that transparent?
If they are then what makes it work, what is the secret sauce that allows the organisation to function like that, can other people learn it and will it take in other organisations?
To try and answer these questions, and to see what I could learn and bring into my own classes SoftEd paid for me to attend the Menlo Innovations Deep Dive class in September 2015. Five days of deep immersion into the culture, working practices and skills that it takes to be a Menlonian.
Day 1 – The Menlo Way™
This day is an overview of what Menlo is all about, the blurb describes it as “brain buzzing” and I certainly found it to be so. Rich’s partner and cofounder James Goebel, the COO of the company, led the day – how many other organisations would have one of the two most senior executives take a whole day out to lead a class on how they work?
The training class is delivered in a section of the Menlo office – the participants experienced the Menlo way first hand with pairing activities and safe to fail exercises.
James started the day by introducing us to the Menlo mission – “to end human suffering in the world as it relates to technology™”. He then discussed what that means in terms of their clients and for the people who work at Menlo. Menlo’s primary business is designing and building software for other organisations, and they start with the ultimate end user in mind. For their customers that means understanding what their customers/users real needs are and designing the product from the ground up to be truly usable by the target audience. For Menlonians it means working in a way that is the result of intentionally choosing to create a culture founded on the Business Value of Joy™.
The strong end user focus means they have to really get into the minds of the ultimate recipient of any product they are designing and identify what problems the technology solution needs to address, understanding the problems the users have with the technology and having the fortitude to actually tackle the problems.
Menlo works on a strictly time & materials basis with their clients, and have a creative approach to risk sharing: they will take up to 50% of the development costs in either equity in the customer or royalties from the revenue earned by the product – if their customer doesn’t do well from selling the product then neither will Menlo.
He talked about the Menlo engagement model for people who work there. Most of the workforce are contractors but you wouldn’t be able to tell that from looking around the office. There is no difference in the way employees and contractors are treated, no difference in where they sit or how they interact. Employees have a fairly small basic salary and the bulk of their income is paid based around the stories they work on. Contractors don’t get the basic salary – all their pay comes from stories worked on.
For a story to be worked on someone (normally an external customer representative but internal work has internal customers) must have chosen it and included it in the plan for the current week. If you have a story card to work on then you get paid, work without a story card doesn’t get paid for. This makes it simple – all work has to be funded and the team members simply don’t work on things that they aren’t going to get paid for. A story card is a work package and is something that is estimated to be 32 hours of work or less. The 32 hour limit is because they strictly limit work time to 40 hours per week and there are about 8 hours of overhead activities built into each iteration. These overhead activities have their own cards and are paid work time.
He discussed the simple ideas behind the Menlo way of working:
- No card – no work
- All work is done in pairs at the team level (project management and some support roles are not paired, but all team activities are paired)
- Pairs are rotated at least weekly, often more frequently
- All development is done using strong technical practices – TDD, CI and pairing, design patterns, code design and implementation is reviewed and checked by another pair before checkin
- Iterations are five days long
- While team members have preferred skills and tools (including programming languages), they are expected to be flexible in support of the team’s goal and able to pick up tasks which require a different skillset. This is safe because of the pairing and learning environment. Full stack, multi-language programmers, able to write documentation and do other tasks needed to deliver value
- Team members are rotated around projects regularly – at least one person from each team will rotate to a different project each week
- Teams sit together, all furniture is easy to move and when you move from one team to another you go and sit with the new team
- The office space is open and noisy – collaboration is enhanced by being able to overhear each other. Interruptions are in the context of the work being done. What Alistair Cockburn calls the “convection currents of information” that surround a healthy agile team
- The end of an iteration is the END of the iteration – all work checked into the repository and a production-ready product increment delivered to the customer
- All work is estimated (the expectation is that the estimates will be correct only 2% of the time) in hours, with estimation granularity of 1, 2, 4, 8, 16 and 32 hours per pair
- Actual work time is recorded against the card
- As soon as a pair discovers that they are likely to exceed their estimate they must let the project manager know as soon as possible. The project management response is to smile and say “thanks for letting me know” – there is no subtle pressure to “work harder”
- If the change will have an impact on the stories to be delivered on the current iteration or will have an impact on the project’s projected value then the project manager will discuss it with the customer and make decisions regarding the sequence of work for the team
- Estimates and actuals are simply data points to be used, not weapons to coerce behaviours from team members
He equated the simple rules to knowing the rules of a team sport such as soccer – team members don’t carry the rule book in their pocket, they know the important behaviours and how to play together. A group of children playing a casual soccer game in a field will have less rigor than a world cup squad but the behaviours of both will be recognisable.
Menlonians learn the rules by being immersed in them from their very first day, by being paired with someone who has been there longer. (In some cases only a week longer). Because the teams are sitting together even a novice pair has a safety net around them with the other team members able to overhear and contribute to their (task related) conversations if needed. This safety was strongly emphasised and was visible in the interactions we saw in the team. As James said “everybody teaches, everybody learns” and this teaching and learning is going on constantly.
James discussed the difference between efficiency and effectiveness and stated that the Menlo approach leans heavily towards effectiveness and they are comfortable to sacrifice individual efficiency (maximum utilisation, for example) for team effectiveness. He used the metaphor of a rowing crew – 8 people who have to work in a steady rhythm together rather than working at the individuals’ peak pace. To be effective there needs to be some slack in the system. Working at maximum efficiency results in bottlenecks and wasted work.
He addressed two of the traditional challenges of software engineering: Brooks Law (adding people to a late project only makes it later) and the optimum team size (7 plus or minus two) and explained why the Menlo approach allows them to effectively overcome both of these. They can put people on an off projects rapidly and teams are as large as 30 people. The first is overcome by the constant rotation – from a quick poll (he shouted out “Hey, Menlo” then asked for a show of hands of how many people had worked on some named projects, most people had worked on at least four of the named projects, no one had only worked on one) it was clear that knowledge of the different projects was widely spread across the team. The second he maintains is overcome by the way teams do sit very closely together – they are able to overhear one another and can talk across the tables easily. He stated that it is not the number of communications channels but the combination of number and length of the channels that causes the productivity reduction as teams get larger.
The other advantage that the rotating of team members has is that no one becomes stuck in a particular technology. He talked about the COBOL programmers in many organisations who are unable to move into new technologies because their skills are considered too rare to lose. In Menlo being in a team building a COBOL system would not be a case of being locked in, but that you will rotate regularly into other projects. The same thinking applies to the tasks that team members traditionally try to avoid (eg documentation) – because it is shared around everyone will get a turn and no one gets locked in to the task. This results in better quality of work, as one way to avoid having to do the “unpleasant” tasks has traditionally been to do them badly. At Menlo a lot of the work they do is for customers in the health care area where FDA regulations require extensive documentation, where this is needed it has a card allocated and it is assigned as part of the planning activity in the iteration.
Another agile practice that Menlo have adapted is the daily standup. This is an important ceremony that reinforces the one-team culture. 50 people standing around a circle, telling each other what they are working on, identifying any areas they need help with and sharing any social events, AND the meeting finishes in less than 15 minutes. As course participants we were included in the standup and had to briefly say who we were and what we were doing.
It was fascinating to see the daily standup writ so large and achieving the collaborative outcome it is designed for. Where people were working on something in a pair or larger group (the largest I saw was 5 people working together on a single activity) they all touched the talking token (a plastic Viking helmet) together and one person said what they were working on and any challenges they were having. Then if any of the individuals in the group had something to say about a different piece of work or activity they mentioned that separately. While we were there a charity fund raising event was being organised and a few people mentioned activities for it in the standup. Immediately after the standup small groups clustered together to either address specific challenges which were raised or identify actions needed.
An aspect of the culture which is written about in the book is the family friendly approach that Menlo takes. Parents with young babies are welcome to bring them into the office and the work carries on around the children. They have won an award for their support of breastfeeding mothers, with a baby room kitted out for the comfort of both mother and child.
A number of people made the point that everyone seems to be subconsciously nicer when there is a baby on premises, including visiting clients.
They are also well known for being pet-friendly, and there was a dog in house while we were there. The dog wandered around quietly, obviously enjoying the company (and hoping for a share of the lunchtime goodies) and not bothering anyone. Seeing the dog wandering around brought a smile to everyone’s face.
Culture is at the core of Menlo’s success – without a collaborative, supportive and joyous culture it simply couldn’t work. The practices and their very rigorous process build on the foundation of the healthy culture, and everyone is cognoscente of the importance of the need to protect the culture.
James referred to Patrick Lenncioni’s book The Five Dysfunctions of a Team and how important creating a foundation of trust is to preventing the dysfunctions from emerging. Trust is a multi-dimensional set of relationships at Menlo. Team members trust that the leadership have their best interests at heart, customers trust that the teams are doing their best to deliver products which people will love to use, leaders trust that the teams are constantly working on the next most important thing in the backlog, team members trust that project management understands the client’s priorities and can express them clearly through the planning activities…
James stated that “culture is the sum of all the relationships in the group” and because these relationships are based on that deep sense of trust they are able to work together effectively; even if two team members don’t particularly like each other they are able to collaborate on the work – even pairing up to work very closely together for a week at a time.
Their interviewing process is an example of the culture at work. CV’s don’t matter – what matters are the candidates “kindergarten skills” – do they play well with others.
Their Extreme Interview is designed to show the presence or absence of collaboration and teamwork skills. Following the first round (a group interview with up to 40 people pairing over two hours collaboratively solving problems, or not), a limited number are invited back for the second round, during which they will pair with members of the team who they will be working with. The team decides who they want to invite back after that for a three week trial, during which time they work on real projects in the team and pair with most, if not all, of their potential team mates to see if they want to work together.
The makeup of teams is fairly straightforward – there are only four roles and seniority is defined by your level of knowledge/skill not by tenure in the role.
The four roles are:
Project manager – a true servant leader role, responsible for coordinating the work, ensuring the planning activities are undertaken and getting the customer to engage with the rest of the team as needed.
Developers – whole-stack, multi-language programming professionals who write the code using strong technical practices (pair programming, test driven development, continuous integration, design patterns, etc) design the architecture, review other developer’s code, unit test the code and test that the code they’ve written works (quality control is a developer responsibility)
Quality Advocate – pairs who perform end to end and system level tests on the delivered story cards. With a quality mindset they are able to find the obscure bugs and creatively exercise the product to expose where there may be problems.
High Tech Anthropologists® – to quote one of the HTA’s when she described the role – “what you would get if a Business Analyst and a User Experience expert had a child, with consultants as grandparents.”
The makeup of the teams is roughly 50% developers, 25% HTA’s, 15% QA and 10% project management. All work is done in pairs except for project management.
Project Management and High Tech Anthropology are explained in detail in the sections that follow as they were the focus of the remainder of the week.
Information about the projects underway is made visible through the use of wallspace for planning at many levels. Each team has a Work Authorisation board which shows the set of stories the customer has prioritised and authorised for this sprint (no story – no work is a strict rule, and working on something without a card is a fireable offence, all work is tracked in 15 minute chunks and timesheets used to bill clients and pay people). This means they have a deep knowledgebase of previous projects with their estimate and actual time taken. This is a boon for forecasting upcoming work or providing estimates for a new initiative. Another Menlo difference is that timesheeting is not a burden, it is safe to tell the truth and nobody is second guessing your estimates (estimates are expected to be correct only 2% of the time).
There is an overall forecasting wall showing work across all projects over the next 6+ months, and another wall showing the financial performance of the company – again this is visible to everyone and is in a very public space.
Everyone attending the class received a copy of the book Joy, Inc which is the Menlo story.
About the Author
Shane Hastie is the Chief Knowledge Engineer for Software Education a training and consulting company working in Australia, New Zealand and around the world. Since first using XP in 2000 Shane's been passionate about helping organisations and teams adopt Agile practices. Shane leads Software Education's Agile Practice, offering training, consulting, mentoring and support for organisations and teams working to improve their project outcomes.In 2011 Shane was elected as a Director of the Agile Alliance.