Teams Thrive

The Who, Why, How, and What of Thriving Teams

As Amanda & I thought about forming Teams Thrive, we had to ask ourselves is there something unique about our approach that we think the industry needs? There are a lot of fantastic executive coaches out there. What we came away with is that coaches are often focused on the leader of a team with a strong emphasis on the person in context of leadership & communication principles. We believe the fuller context of success is how do their teams function as a team (the Who), with a purpose (the What), with just enough process (the How) and still produce a great product (the What). 

Over and over we have seen that the right people with the right purpose working with the right processes create the best products. And leaders are only as good as the teams they produce. And teams are only as good as how they work together to solve real customer problems. We use these four dimensions as a “forensics” tool to evaluate where a team is. By looking at all four aspects we get a fuller picture of what needs to be done to move the team to a high functioning and thriving level.

The Who: Common Traits

A team is more than just a collection of individuals. It is a group of people that have come together to do work in service of a common mission (the Why). They do this work in an agreed upon fashion (the How) in order to produce a product (the What) for customers that hopefully achieve the financial aims of the business.

The best teams are built on common traits. I once did a survey with 30-40 people from all walks of life on what they thought were the traits of a healthy team. As you can imagine there were almost as many traits mentioned as there were participants in the survey! It felt a bit overwhelming as no single team could possibly demonstrate all these characteristics and their subsequent behaviors.

However, on closer examination, there were certain characteristics that it seemed teams had to have in order to thrive. The top traits included (but are not limited to) trust, empathy, humility, ownership, commitment, communication, and collaboration. And as I reflected on my own experience guiding teams, I could see an over-arching theme that give these traits meaning. They believe and behave in these ways in service of the customer in the context of the business. 

The Why: the Customer

It is a long held belief by religious and non-religious traditions that happiness is not found in the pursuit of selfish ambitions, but in the pursuit of helping others. The Customer becomes a proxy for “others”.

It is fairly common for teams to say they are customer obsessed. But in reality it is really hard to keep the customer’s needs in focus and not fall in love with our ideas or get wrapped up in petty team politics. Just talk with individuals and have them describe the customer and tell the stories of how their customers use or will use their product. Many times you will find that the “team” is actually individuals with wildly different views of the customer. It is just hard to stay focused on what is really important and not get lost in the day to day of team dynamics. Everything about organizations pull you away from the customer.

A few years ago, I was asked to take a team that the whole organization acknowledged was in terrible shape. In fact, it had been a bane to our product teams over the previous five years. I had observed the team move from leader to leader without ever moving beyond what would be classified as a struggling team. When I interviewed various people in the team, it was obvious that the current leadership (it seems like previous leadership) had made the problem much worse by restricting who in the team could interact with their customers. In a misguided attempt at not distracting the team, they only allowed customer requests & feedback to funnel through one person – the project manager. While the project manager was talented, he couldn’t have enough context to do much more than run the process. Instead he & the leaders filtered the information to just a handful of people on the team. These in turn filtered information to the rest of the team. By the time this information got to the team it had become just a series of tasks and no longer had any context. There could be no dialog with the team. Just simply assignments.

So how did I fix this?

I immediately opened the chain of communication. I had the team meet with their internal customers (this was a platform technology team so its teams were internal). They finally heard first hand the frustrations of their customers. They got to ask questions which gave them the customer context they were starving for. I jokingly told one of the leaders of the team that from now on if someone on the team even sneezed I wanted to hear that all of the customers knew about it and had issued their health blessings back to the team! What I meant by this was don’t hide your failures. Overshare. Be transparent. Build trust. Create a collaboration model. Make sure everyone in the team has customer context and it is as evenly distributed as possible.

When I took the team, there was a crisis several times a day. Within a month, it only required a half hour update once a week. The team had turned around by simply talking to their customer. They had found their “why”.

Lesson? Customer drama always trumps team drama.

The team began to have confidence in themselves. They had a common purpose. They started getting positive customer feedback. The customers saw the change in attitude and began to trust them. The team would find creative solutions that would half the time it took to get a task done. But on the flip side if something was harder than originally anticipated, the team could tell the customer and since there was trust, the team was given the space to do things right. It began to thrive. It became a healthy team and the product improved dramatically.

The How: Just Enough Process

There are certain people in every organization that think every problem can be fixed if we just have enough process. It is similar to thinking that if a society has a problem then certainly a new law is the solution. So just a society needs laws and teams need process, healthy societies need fewer laws and healthy teams need less process.

When I was at Netflix, I remember our CEO/founder Reed Hastings saying something about people & process that has stuck with me these many years later. I will paraphrase but in essence this is what Reed said:

The more talent you have the less process you need. The more process you have the less talent you will retain.

Later I heard Reed on a Masters of Scale podcast explain this further. In his first startup, Pure Software, he and the leadership had continued to institute more and more processes to address the challenges of a growing startup. Over time they had so many processes in place that they drove out most of the first principle thinkers. The people who were always are asking why we do something. The people who are not slavishly devoted to a way of working, but devoted to solving the core problems. And when the market changed, the processes couldn’t adapt fast enough (processes resist change for a good reason) and the people who understood why a process was in place were gone. 

It is important though to understand that process is important. Without process there is total chaos. But with too much process there is no freedom to create & respond to customer needs as they change.

The best processes are iterative. But they are not just made up of iterative mechanisms. They themselves are iterative. Good processes must be expected to evolve and change.

I have often said that engineering should be a learning machine. It should be set up in a way that the product organization (I mean this in the broadest business sense) should be able to count on the engineering systems to enable rapid learning. That means they should approach prototyping and production in very similar manners. That means that their processes should be highly adaptable and flexible expecting change. 

At Netflix I learned quickly that because we were constantly learning and evolving the product, that the bigger challenge was to design for change, for learning, for volatility, for throw-away-ability. 

This is why processes can’t be set in stone. The How is always in service of the Who & the Why. The How is in place to create a great product (what). Just enough process and no more. And no religious devotion to process methodology should be allowed. Once again I find teams can derive too much comfort in process. It is natural. With process you don’t have to think about the way something gets done. And that can be wonderful. It frees the brain to solve other problems. However, some teams get a false sense of comfort from process itself. And the process begins to move them further and further from the customer. But they feel like they are successful because the machine is humming and whirring and stuff is being produced. 

How do you solve this? Once again it has to be in the service of the customer. It has to be informed by a purpose. It can’t be machinery for machinery sake.

The What: The Outcome of All of This

When you compare our approach to the standard coaching model, this is probably where our method is unique.

You can have a great group of people that have trust, empathy, collaboration and a host of other wonderful traits. But if the product misses the mark and doesn’t meet customer needs or drive the business forward, then you just have a neat social club.

If the team has a wonderfully written vision and well crafted mission statement but at the end of the day doesn’t meet the customer and business needs then you don’t have the right purpose and the team will start exhibiting problems of cohesion and purpose. A purpose is more than a poster on the wall. It has to be fueled by the real needs that come from our customers and our businesses.

It the team has developed amazing processes and can deliver everything that is assigned to them, yet they find the work uninspiring or the work doesn’t meet the needs of the customer and business, then you just built a process machine. And you can turn the crank and pat yourself on the back, but you just have a dumb machine that cranks out stuff. I once said that Agile doesn’t have a brain. This is what I meant. An agile process without the “brain” or the purpose driven by the customer is just a machine. 

And if the product misses the mark and doesn’t solve customer and business needs then what is the point of the team & processes anyway? A happy team with the right purpose & processes should be producing happy products.

Summary

No single framework or pithy phrase can capture everything needed to create healthy, thriving teams. People & the problems of our customers and business are much more complex than that. However, Amanda & I have seen teams in just about every state possible, and we can assure you that forming a team (the Who) around a common purpose (the Why) with just the right amount of process (the How) that is tuned to solving (the What) real problems will create the healthiest teams.