In the last post, I wrote about the Law of the Network as explained by Steve Denning. You can read that post here or go into more detail here. In this post, I’m going to explain the Law of Small Teams. By the title alone, it doesn’t seem complicated, but I will explain why this is a law in the first place from several considerations.
But first, a question: Have you ever been on a real team? Not just a group of people that happen to work together, but a team. A group of people that collaborates, solves problems, delivers results; people that connect and help even before the need for help is known?
I’ve been there
I have been on one such team in my career and it was an amazing experience. As a team, we had all the tools and skills that we needed. We had the autonomy and trust to make important technical decisions. Priorities were clear (for the most part) and we truly hit an agile flow state. At that time, coming to work was a pleasure. Things were getting done. Our end users were ecstatic with our results. Problems, when they occurred, were quickly resolved.
But, for reasons outside of our control, the effort we were working on ended and instead of maintaining all the synergy and knowledge gained on our small agile team, we were disbanded. Everyone was reassigned to some other work.
Nothing about this is new. Work will always come and go, but the real tragedy was the team disbanding. The future potential value that we could deliver as a performing team was lost, but few even realized it. Work became work again. Results were mediocre.
Unfortunately, real teams are hard to come by. Some are self-organized, others are put together and people form into a team. But, leadership often overlook the value of a self-sufficient and value-producing team.
Defining the Law of Small Teams
Steve Denning provides this insight into for team size:
Agile practitioners share a mindset that work should in principle be done in small autonomous cross-functional teams working in short cycles on relatively small tasks and getting continuous feedback from the ultimate customer or end user.
Note that it doesn’t say how many people comprise a small team, it’s not that prescriptive. But, your team should have all the knowledge, skills, and abilities to put something in front of your customer or end user. Various branded agile frameworks will be a bit more specific. For example, scrum establishes that a small team consists of 7 people (plus or minus two). Aside from actual frameworks, other businesses have their own rules for team sizes. Jeff Bezos described his team sizes, in the early days of Amazon, in terms of pizza consumption. At Amazon, a team should be small enough that it can be fed with two pizzas.
What is important here is not the exact number of people, but that you have just enough people to get things done. By doing this, you ensure the other half of the Law of Small Teams works in your favor — working on small cycles and small tasks in order to gain continuous feedback.
Why this matters
Overall Agility
Small teams accommodate for change and discovery. Businesses have to be able to change to continuously deliver value for their customers. A small team that is close to the customer to gather and incorporate feedback will be much more responsive to change. Additionally, the small team concept ensures that each team member is working at their optimized capacity. Small teams enable each member to know when another is struggling or needs help. Responding to that need quickly also contributes to enhanced business agility.
Overall Satisfaction
There are two views that you can have with people: 1. People are essentially lazy and will only do the minimum to get by. 2. People are essentially hard-working and will go above and beyond normal results when given the environment to do so.
Working on small teams reinforces belief number 2. Traditional work and organizations carried over from earlier times were structured based on belief number 1. To make an impact, you have to subscribe to the notion that people will perform in the right circumstances. The right circumstances occur when people are working on small teams.
Small teams optimizes individuals time and effort. A majority of people out there abhor boredom. They want to produce results that serve and help others. When you are working on a small team, you get to see that result. On a large team, you may never see the results of your labor and how it helps someone else. Seeing those results are a key to creating circumstances for an optimized person.
Solve complexity with simplicity
Another key feature to small teams is that enhances the flow or output of a team by keeping things simple. With a small team, interactions are simple, less politics, and less friction for key decisions. Just as a small team optimizes the performance of people, a small team optimizes the time of the people involved. A small team is able to flow through work easier than a large group of people. Moreover, a small team is better able to experiment with new ideas and technology. With this experimentation, complexity and simplicity is usually the output. Consensus and decisions comes sooner.
Making small teams work for you
Perhaps you are in management and want to slim down your teams. Where do you go from here? Figure out the roles you need. Scrum is pretty specific on this as a baseline. It advocates for a scrum master, product owner, and a development team. The development team can be a number of people including business analysts, developers, UI/UX professionals, etc as long as it doesn’t break the 7 people rule (give or take two people). But the key is that within the scrum team, you have a built-in feedback mechanism via the product owner and various scrum ceremonies. Even if you don’t practice scrum, these roles are key for most agile teams.
One of the key qualities within an agile team is a mentoring capacity. Since the small team is self-sufficient, there is an expectation for the team to be learning and pushing their limits. You need to have a key technical expert that can mentor others. You also need to have other team members that are willing to learn. This is a winning combination for small teams.
The final point to keep in mind is to leverage the law of small teams for your particular business context. This law is for business agility not just software development. Therefore, you should be looking to make this a part of your company culture. You can have a back office small team of cross functional experts to address operation challenges as an example. You will be much more successful if you build your entire organization with cross-functional teams and keep them together. They should be a permanent fixture of your organization, not a project-based solution.
Thanks for reading!
