This is a superficially easy question to answer, but when you really get down to it, it can become quite difficult to understand why certain teams completely outperform others.
In my study of this, I have come to the conclusion that great teamwork is far less about each individual and far more about the structure of how these individuals work together.
This means that you can build a team made up of people who perform on average at 70%–80%, can outperform a team of rockstars that individually perform at 90%+, if the correct structure is in place.
So, the team trumps the individual, and then there is a synergistic tendency in great teamwork, the whole becomes greater than the sum of its parts.
But why is this?
It’s quite simple — if a group of individuals has put little to no thought in how to work together as a cohesive whole, the overheads of running a team become greater and greater over time, which actually makes the team less and less productive, because there is a shift of focus from real work to something called meta-work.
What is Meta Work?
While you may not have heard of the term meta work, you most probably have heard, or at least experienced using, metadata.
A set of data that describes and gives information about other data.
So for instance, your music library is made up files that contain bits and bytes that instruct a music player on how to emit certain sounds so your favourite song can play. This is real data.
In this example, metadata would be the data that doesn’t contain the music, but contains the information about the music. Album name, recording date, artist, date of publication, etc.
So, going back to Meta Work, we can take a simple example like this:
Writing a to-do list is meta work. Reporting to superiors is meta work. It’s the work that goes behind the real work that creates real products and services.
Generally speaking, your customers or users don’t care about the meta work, they just care about the output of the real work that your team produces.
Now, that’s not to say that meta work is bad or useless. Quite the opposite. If managed correctly, it allows greater efficiencies when spending time doing real work, to ensure that the right thing is being done.
The biggest risk to any organization is not that someone doesn’t do enough real work, but that the real work they do in wasted in doing something that doesn’t add any value.
Eric Ries, the author of the seminal Lean Startup, wrote:
Lean thinking defines value as providing benefit to the customer; anything else is waste.
Whatever goes to the customer is valuable. It is tangible. However, meta work is not necessarily a bad thing, but some tweaks are necessary.
The right way to approach Meta Work
Meta work should always be viewed with suspicion, and constantly questioned, because it is often the case that by following certain guiding principles (more on this later), lots of meta work can be reduced or eliminated.
For instance, the need for reports can be reduced if team members give simple status updates at the end of each day, which are transparent and available for all to see.
I recently relooked at how we do designs and mockups, because, if you think about it, designs and mockups are also meta work!
The real work at our company is building great web applications and sets of mobile applications, which is done in code. The design process is there for us, internally, to make the best possible product. However, this isn’t the product in itself, and thus it is meta work.
So, the aim is to try and get the best possible product, while reducing the design process as much as possible. This is a careful balance, because of course great ideas need to be fleshed out and they need time to gestate, but there are times when certain phases can be skipped.
For instance, our iOS app “Home” and “You” screens use default iOS components, and thus we don’t need to design it for the developers. We can just describe it with a few short paragraphs and bullet points, and follow up with some whiteboard drawings, and be done with it. This takes a fraction of the time required to do mockups in Sketch, and still gets the same results.
Small is Good.
There is a great book by Fred Brooks on software engineering called the Mythical Man-Month.
One of the basic principles in this book is that after a project grows to a certain size of people, the amount of energy required to add one more person and communicate and collaborate with them is actually greater than their net contribution to the project, and so the whole project slows down.
And so, while there are lots of guiding principles for great teamwork:
- Understanding Meta Work
- Intentional Speed
- High Quality Decision Making
- A system for assigning responsibilities and maintaining accountability.
- A focus on craftsmanship
It all really sums up to one thing:
Keep teams small.
This will essentially prove that all the above guiding principles will (almost) fall into place, without too much attention.
So, what’s the magic number? Jeff Bezos has his famous “two pizza” rule — that no team should be bigger than the number of people that can be fed by two pizzas, which is normally accepted to be at around 6 or 7 people.
Personally, I’ve had a similar experience when we started Mäd.
Until the point where we were at 10 people, it didn’t really feel like work. It just felt like a group of friends working together, and I didn’t feel like I was managing anything, but things got done.
We quickly grew to the dreaded 25+ people mark, and suddenly we weren’t as efficient, and things started to break down, when one particularly troublesome team reached 15 people in size.
The issues happen because communicating with increasingly larger amounts of people gets harder and harder. I discussed this in our “Hello World” post, and I’ll just quote straight from there:
It is just a fact that as you scale past a non-trivial number of people (say, 10), teamwork becomes increasingly more difficult.
That’s because team communication does not scale in a linear fashion compared to the number of people on the team.
For instance, if you have a team of 2 people, there is one communication thread (between the two individuals). Throw another person into the mix, and now you have three communication threads. So, while the team size has increased by 50%, the communication threads have increased by 300%.
Let’s see how this grows:
- 2 team members = 1 communication thread
- 3 team members = 3 communication threads
- 5 team members = 10 communication threads
- 8 team members = 28 communication threads
- 10 team members = 45 communication threads
- 15 team members = 105 communication threads
- 20 team members = 190 communication threads
- 30 team members = 435 communication threads
- 50 team members = 1,225 communication threads
- 100 team members = 4,950 communication threads
This can actually be expressed by the following equation:
Where “n” is the number of people that need to be involved in the project.
If you want further insight on this tendency for communication to become more difficult, continue reading the “Hello World” article.
Strategies for Keeping Teams Small.
- Assign one manager per 7–10 people
- Split growing teams
Cross Team Communication
Obviously, small teams cannot exist in their own little universe, especially when trying to achieve big things. So it is natural for cross-team communication to happen, and in fact, it will happen more with lots of small teams than just a few giant teams.
However, this needs to be structured in a sensible way, so that managers do not become glorified messengers, and that communication does not slow down or start to hit into the problems of scalability that inevitably happens.
The first thing to realize is that the strategy of having managers control cross-team communication is really dumb, because it creates bottlenecks in the communication system, and also wastes time that could be spent better elsewhere.
Elon Musk wrote a brilliant email to all employees at Tesla, and I’ll present it here:
Subject: Communication Within Tesla
There are two schools of thought about how information should flow within companies. By far the most common way is chain of command, which means that you always flow communication through your manager. The problem with this approach is that, while it serves to enhance the power of the manager, it fails to serve the company.
Instead of a problem getting solved quickly, where a person in one dept talks to a person in another dept and makes the right thing happen, people are forced to talk to their manager who talks to their manager who talks to the manager in the other dept who talks to someone on his team. Then the info has to flow back the other way again. This is incredibly dumb. Any manager who allows this to happen, let alone encourages it, will soon find themselves working at another company. No kidding.
Anyone at Tesla can and should email/talk to anyone else according to what they think is the fastest way to solve a problem for the benefit of the whole company. You can talk to your manager’s manager without his permission, you can talk directly to a VP in another dept, you can talk to me, you can talk to anyone without anyone else’s permission. Moreover, you should consider yourself obligated to do so until the right thing happens. The point here is not random chitchat, but rather ensuring that we execute ultra-fast and well. We obviously cannot compete with the big car companies in size, so we must do so with intelligence and agility.
One final point is that managers should work hard to ensure that they are not creating silos within the company that create an us vs. them mentality or impede communication in any way. This is unfortunately a natural tendency and needs to be actively fought. How can it possibly help Tesla for depts to erect barriers between themselves or see their success as relative within the company instead of collective? We are all in the same boat. Always view yourself as working for the good of the company and never your dept.
This leads us into an interesting area of thought:
What is the role of a manager?
I’ve got some strong opinions on this, and it mostly goes like this:
Managers are there to communicate the company vision and high level goals, and provide support and help team members remove roadblocks.
They should be taking care of things that normally have entire departments assigned to them such as People Operations and Recruitment/Talent.
They should not try to control their small team, but actually try and get out of the way to let them do good work that’s not a waste of time (i.e. aligned with the overall objectives).
In this context, it makes complete sense to allow a member of a team to communicate directly with another member of a different team, without going through their respective managers, because it allows the real work to be done faster and with the least amount of meta work as possible.
Principles for Great Teamwork
All the principles stated below are linked, and many of them are simply not possible in isolation.
Transparency is great for various reasons, but the main reasons are that it allows for better decision making, stops people accumulating power by holding knowledge, and drastically reduces the amount of communication and reporting required.
Understanding Meta Work
As discussed earlier, Meta Work is important and valuable, but should be viewed with suspicion, and the team should be on constant alert in regards to how much meta work they are engaging in vs real work.
Respect between team members is crucial, because there will inevitably be times when there are disagreements, and a high level of respect between individuals allows the criticism of ideas to be had, without criticizing the person *behind *the ideas.
This is an important distinction to make, because a room full of yes-men deploying the infamous group-think technique will get you nowhere fast.
Google has a moto:
Fast is better than slow.
While this might be true for website loading times, or finding search results for a query, it’s not applicable universally across everything.
In fact, taking it to the extreme, we can see life as a journey from being born to the grave, but that doesn’t mean that it is best to do this as quickly as possible!
So, great teams work with intentional speed, which means they know when they need to work quickly, and they know when things require a more careful, studied approach.
Guess what this requires?
High Quality Decision Making
It’s important that teams make consistent high quality decisions, but also know how much time to spend making decisions vs just going for it.
A corollary of this, is developing a strong bias towards action, both in decision making and in simply getting sh*t done.
However, this requires people to take…
Ownership of results comes from a clear understanding of who does what. In small teams, this comes naturally as often it’s just one or two people.
In larger teams and organizations, ownership is often not there, and that is how office politics start coming into play, with people looking to get more recognition for a result that they were responsible for, and the responsible parties sometimes not even being congratulated.
Ownership is a two-sided coin:
- Recognizing and praising success.
- Understanding and learning from failure.
These can be easily achieved when there is only one or two faces for a given task, which means that projects need to be split into small enough chunks, so that each chunk is doable by one or two people.
A system for assigning responsibilities and maintaining accountability.
While this can be done on something as simple as a piece of paper or a whiteboard, it can be handy to have an online system where things can be reviewed without being in the same physical location at all times. This is where software like Bloo comes in.
I’ve spoken before about the three simple things that are required to move things forwards:
- A list of things that need to get done.
- People assigned to each thing.
- Timelines for each thing.
And that’s really it. Of course, how you estimate timelines for each thing is an art in and by itself, but these are details.
If you have the these three things in place, you're already way ahead of the curve for your projects compared to most organizations out there.
This is a controversial topic about the workplace, and while it might be true that, in corporate environments where office politics play a large role, it’s best not to be friends with your colleagues, in small teams, it’s almost a must.
The issue here is that we spend a lot of time working, and we spend a lot of time with co-workers, and it’s much nicer to work with a group of people that you can consider friends and have shared experiences outside of work.
Of course, this does create problems, especially if certain team members need to be let go for a certain reason, but then nobody said that life is easy!
My gut feeling here is that the pros significantly outweigh the cons.
A focus on craftsmanship
There is an inherent satisfaction in working on something with the focus of a craftsman.
While few of us now create physical things by hand, we can still apply the principles of craftsmanship to whatever else it is we do as knowledge workers.
Taking pride in the output of your work is always a good thing, as long as you can stay objective about the quality.
Taking the time to cut yourself off from other people and work deeply is a large advantage is this distracted world, where social media is omnipresent, always looking to capture our attention. Take a read of Cal Newport’s book Deep Work, it’s quite fascinating.
Craftsmanship is also equivalent to quality, and there are serious advantages to having a focus on product or service quality.
Take Apple and Samsung, both large smartphone manufacturers. Apple has the edge in terms of profitability per unit sold and also in terms of how the software and hardware components interplay with each other, largely due to the obsessiveness of their leadership in this regard.
The results also speak for themselves. Samsung spends about 15x more on marketing than Apple, to try and convince the public to buy their products, while Apple can largely rely on brand loyalty, because many people value the craftsmanship that goes into making their products.