‘Ma’ is a Japanese boundary, but it isn’t a line. It is a void, an expanse. The literal translation is “space between,” but rather than a static gap, it is the distance that exists between objects as well as between time. It is the silent pause between …the interactions between people

A good team creates magic. In “The Science of Teamwork”, Goodwin, Blacksmith and Coats analyse 60 years of research into team dynamics in the military. One of their key findings shows that a good team, a team with strong bonds between its members, can achieve more than the sum of its parts:

Teams can be more effective than the sum of individual team members. Cohesive teams (i.e., strong bonds among members) perform better and stay together longer than do noncohesive teams. Teams can absorb more task demands, perform with fewer errors, and exceed performance based on linear composites of individual performance

The bulk of my career was shaped serving in, building and growing product teams in technology companies around the world. Sometimes the teams worked out really well, and produced “magic”, and sometimes they imploded. When things imploded, it was always tempting to look for what caused the failure. Over time, I discovered that it was often what was not there that caused the failures. The failures were in the space between. The failure points were in the “ma”.

What does a good product team look like?

In general, we’ll probably all agree that a good product team looks something like this:

A good product team will likely have a UX Designer, a few Developers, and ideally (although most often forgotten) a QA Engineer. Depending on the stage of the project, your product team may also include a Product Manager, Project Manager, and lean on the services of a Marketing/Content Strategist and Graphic Designer. The role descriptions of all of these positions are reasonably well defined, so if you are in charge of product teams, your challenge lies in filling each of these slots with “good people”.

Let’s assume that you have access to great talent, and ample budget, and can fill all the roles. You hire the people, and now your product team looks like this:

After a few months, your product team starts to hit their stride and are out performing. In fact, things are going so well that you need to stand up a second product team. So, you rinse and repeat, and after a while you have a second team, that looks just like the first:

The second team looks like the first, and should be just like the first, but you know, and I know, that even if you are hiring the best, each team will be a little different.

The difference is in The Hum

Intuitively, you know The Hum when you experience it. You can point to teams that have had it, and teams that have not. You see evidence of The Hum in all kids of teams: teams like New Zealand’s All Blacks, regarded as one of the world’s best rugby teams, attribute their 87% win record to their culture of cleaning locker rooms. Other teams point to all star players, like Cameron Smith, who anchor the team and provide consistency across seasons. And we know that somehow, both culture and individual talent are important, but they are not the whole of The Hum, because only some teams that have both culture and star players are really high performing.

And we definitely know that a team that has The Hum produces results, has high creativity, and respect and flow and people love coming to work and the products that the team creates are frankly nothing short of magic… and we suspect that The Hum is a quality that belongs to the team, not to the individuals themselves.

We know this, and when it comes to building product teams, we ignore it. We go back to laboriously matching capabilities with role descriptions, burning at least 6 months each time a person transitions between roles; more if we got the hire wrong. Each time, holding our breath that the new hire will be a net positive, as we write the cheque for a big chunk of the annual salary to the recruiter who placed that talent in the slot for us, and write off the costs of lost productivity.

We are not alone in our product centric world. We see evidence of choosing talent over teamwork in sports too: a team will have an excellent season, all the commentators and journalists speak in flowery terms about teamwork, and then individual players get poached and dropped into different teams at the end of the season… and The Hum that was there is lost.

The Hum is what is not there

Even though the structure of our high performing teams remains fairly static, and we follow the same process, and fill the roles with people of high calibre and talent, the vibe and performance of each team is different. We tend to miss The Hum, as we are trained to see things that are there, and ignore the things that are not there — and The Hum is what is not there. It is not the skills or experience of your people. It is the negative space, the space in-between the people. The magic of The Hum is in the “ma”.

Even when you stand up teams of equal capability and experience, The Hum in each team will be different. If a person leaves your team, and a new one joins, The Hum in your team will change. Sometimes, if a pivotal person leaves your team, it can damage The Hum so badly that your entire team implodes. If you have been in the trenches for a while, you will have your own stories and examples of this… I know I do.

The Hum is based on trust

In 1965, psychologist Bruce Tuckman came up with the “forming, storming, norming and performing” model for how teams grow and bond. His model has been leaned on by performance coaches since then, Patrick Lencioni being one of them. In his book on the dysfunctions of teams, Lencioni turns Tuckman’s theories into a pyramid.

The base of the pyramid is made up of a few layers. At the top are results: high performing teams are all focussed on the same goal. Accountability, commitment and conflict are also present in high performing teams. Most importantly however, the pyramid of high perfroming teams is based on a foundation of trust. One of the reasons why it takes around six months for a new team to bond is that it takes a while to build trust between team members.

Imagine this scenario: you are sitting in a conference room — or given our current situation, on a zoom call with 100 strangers. The presenter asks you to unlock your phone, or computer screen, go to your camera roll and share it with the total stranger next to you. Gulp 😱 (you can see how this goes down live in this video, start at 10:44 😁📲).

Trust is something that can’t be seen. Trust exists between specific people — trust does not exist between roles, or job descriptions. Each time a person leaves a team, and a new person joins the team, trust needs to get rebuilt. Trust is what makes The Hum in high performance teams.

Scaling high performance teams

We now know that The Hum is a necessary ingredient in high performing product teams. The Hum, by it’s nature, is a property that exists between specific people, not between roles. As a consequence, The Hum cannot be scaled.

Ho-Hum.

We can scale the structure, we can scale the hiring process, we can scale the onboarding and team bonding process. We can scale making individuals more capable and more talented. We can analyse the science and optimise the strategies for how to grow the spaces around a team, and scale an organisation. What we cannot scale however, is the space that exists between actual people inside a team, The Hum.

SEALS do not hang around to hand out parking tickets

Military do teams better than most organisations. Their systems and structures are complex, but if you distill their workings to the very core, there are two fundamental rules they adhere to:

1. Teams are small, normally 3–7 people
2. Teams specialise, and these specialties are known, and trusted, by other teams

As an example, the US Navy SEALS are an elite, special forces division of the military. The small teams of operatives get dropped into situations, they execute, and they get out. They do not stick around to hand out parking tickets.

When we build products, we ask our teams to stick around for too long.

The product lifecycle: chaos to order

Imagine a spectrum like the one below: on the left you have chaos — the absence of a plan, the absence of rules, the freedom to create. On the right you have order — systems, processes, predictability.

Think about those two extremes, and place a mark on that spectrum where you feel most comfortable. Do you draw your energy from having the freedom to explore and create, or does the lack of structure and process make you feel uncomfortable? Regardless of where you sit, you know that you have a stronger preference for a place between those endpoints.

When we build products, we start at the chaos end (ideation) and progress through execution, systemisation (order), and eventually hit optimisation. Startups dominate the chaos end, some progress through execution to systemisation (e.g. Trello, Slack) and a few grow large enough that their focus turns from growth to optimisation (e.g. eBay, Amazon, Google). Through this product life cycle, the product teams progress with the product: a team may start with a company in the ideation phase, and still be working on the product 15 years later in the systemisation phase. That means that you, a person on that loyal team, would have started out working in chaos, and over time, transitioned to working in order.

Think back to your mark on the chaos to order spectrum. You have a point where you are most comfortable. When you work on a product in this phase, you will perform at your best — you will be energised, you will feel safe, you will be buoyed by the right amount of freedom and process.

When we move a single team through the product life cycle, we inadvertently are shifting the individuals on that team to a phase where they will not perform at their best. Effectively, we are asking the Navy SEALS to stick around and hand out parking tickets after their mission is complete.

What if we optimised for The Hum?

Let’s return to The Hum. We build a team, they are a great team, they create magic. They have The Hum, and they are humming. What if, instead of asking that team to shift to working on a new phase of the product lifecycle, we allowed them to specialise: the ideation product team would work on greenfields projects only; the execution product team would take MVP’s through to production; the systems product team would scale production. The teams would not grow with the product, they would hand the product off to the next specialised team.

Imagine a system of specialised product teams optimised for The Hum. The product is handed to the next specialist team at pre-defined stages of growth

Anecdotally, based on my observations and leadership of product teams, I would wager that the employee turnover on specialised product teams would be significantly reduced. Sure, people move and priorities change, but most often, a team that has The Hum falls apart when people start to leave… and capable people start to leave when they are pushed into a phase of the product lifecycle that they are less comfortable in.

You can see the Webdirections 2019 presentation of this post here.