How to explain lean teams.

Through our work with clients, we’ve had quite a few reps on how to explain the idea of small, autonomous teams.

Ground Rules

If you attempt to explain all of the principles and practices, it’s like describing football with a referee rule book. No one will play your game.

Less is better — focus on the general idea and explain the minutia while you’re doing the work or in retrospectives. The cognitive load of our theory has severe diminishing returns. For example, do not attempt to explain all the benefits of Trello, sprint-planning, integrated decision-making, etc. Every practice should be grounded in, at most, one principle.

Preamble

Your organization is still built around the principles from decades ago: i.e., a hierarchy, codified roles, and centralized decision-making.

This made sense, pre-Internet. Keeping a 100,000 person organization aligned was really fucking hard.

Of course, this approach was never perfect. But today, we feel its weaknesses more acutely than ever, in the form of bureaucracy, slowness, meeting/email culture.

Over the past 10 years, we’ve observed dramatic divergence in how new organizations approach big and complex. As technology companies have grown from 10 to 10,000 people (or more), time and time again, we see a new fundamental unit for organizing a company’s activities.

Across companies such as Facebook, Google, Amazon, Uber, and Spotify, this unit is a small team (<9) who has autonomy, self-organizes, and has multidisciplinary resources. It has everything that it needs to put something into production (i.e., the opposite of a matrix).

For shits, we’ve acronymized this organizational unit as a SLAM team: self-organizing, lean, autonomous, and multi-disciplinary.

Ways of working

When it comes to doing the work, we have two goals: make the small team as fast and as autonomous as possible. There’s hundreds of ways to get there, with some practices working better for organizations vs. others.

But the SLAM team is non-negotiable. Without a small team, we’re playing football without a quarterback.

Through our work with other clients, we have a library of practices to experiment with. Here’s where we recommend each lean team starting:

• Meeting Types. We limit the types of meetings with which we fill our calendars in order to combat meeting culture. (1) We replace status meetings with a once a week stand-up to plan a 5-day sprint. (2) We replace presentations with a facilitated decision-making process. (3) We replace generic meetings with explicit collaboration.
• Real-time Task Management. We encourage lean teams to, at all times, know who’s go what and what’s been completed. In combination with weekly sprints, we replace long-term project planning with Trello or other collaborative task management tools.
• Working in Public. The benefit of small teams is that we can collaborate on everything. We don’t do hand-offs or send email requests for data – everything is available to anyone. We replace email attachments and Office with Google Drive/Dropbox for file management and use multi-player software, such as Google Docs, for synthesizing everything.
• Lean Team Communication. In most of our communication, the way we use email isn’t all that different than paper memos from mid-20th-century. We need to get out of our inbox and use a communication tool that is built for small teams who work in tight collaboration. Finally, the communication tools used by developers for decades (i.e., IRC) are finally permeating corporate culture in the form of HipChat and Slack. We replace email with an open, collaborative communication tool that can manage file-transfer and text.

Emergence

Once we assemble this new SLAM team, we’re not sure what will work until we try it. We’ll be careful to not experiment with too many new practices at once, for fear that big change leads to big failure. By taking small steps on a bi-weekly basis, we’re more likely to understand what works for the needs of the team, all the common goal of autonomy and speed.