How We Evaluate Teams
Over my time as a senior leader, I inherited a lot of teams. These teams came in various states of health. It was important for me to do some forensics and determine a path to either keep teams thriving or find a way to get them there. I needed a framework for evaluating teams.
In reality, this framework started coming together in a much more mundane way. Every year we had to outline a set of goals for our teams. The goals fell into categories that were always passed down from the top. Being a reductionist, I started seeing patterns in the categories that got handed down from year to year. They had different names of course. And different wording. But I began to see that there were only so many dimensions that a team can organize goals around and on the flip side only so many ways a team can be evaluated on their progress toward those goals.
One time the categories were: Technology, Talent, Craftsmanship. Another time the categories were People, Team Practices, Budget, Quality. To me these categories seemed a bit arbitrary. Obviously we couldn’t focus on all dimensions of team dynamics, but I started asking myself “what is the superset of these categories?” For one it would make easier for me to create sensible goals since I had already put thought into a master set of performance categories.
Having led product, design and engineering teams, I could see that the same framework would to any of these disciplines and more. It applied to any team that is producing outcomes that touch a customer. Over time, this framework became my go-to way to perform a forensic evaluation of new teams and determine a path forward. I taught it to my leadership team and they also found it extremely helpful.
Amanda Schwartz and I have continued to refine this framework as a key cornerstone of our Leadership That Thrives Coaching Practice.
Since we want it to be memorable, we chose to articulate the framework by using the letter ‘P’ as an alliteration. What follows is a summary of each of these dimensions. This is a first in a series of seven posts. The following six posts go intod greater detail on each area.
1. People
It probably seems a bit obvious that a framework for healthy teams starts with people. I am sure you already know that. But I think like me, there are a lot of things that I know, but I probably don’t know them as well as I should. Usually when something is so obvious, it also really hard to be good at.
I like to say, “every software problem is a people problem.” I think this is what trips up most people that work their way up from the ranks of maker to manager. When you are a maker, you can focus on the thing you are making. But even as a maker you will notice from time to time that the pesky problem of people often get in the way of the making. And when you become a manager, this becomes even more obvious. People become your focus. In fact, people are the way you multiply making. You are no longer judged on making, but multiplying. You begin to see is that most of your problems are people related.
But how do we get the People dimension right? Clearly we have to have the right hiring practices to find and bring the right talent on board. It needs to include a diverse set of candidates in order to bring together a team that represents many backgrounds and viewpoints that more closely represent the customer. The team needs their freedom to be acknowledged and be held accountable. This is what we called freedom & responsibility at Netflix. Trust needs to run deep in the team in order to bring out the best aspects of the team.
2. Purpose
Even the best teams with the best people will often have their moments of drama. But one thing we have learned along the way is “customer drama trumps team drama”. Meaning that if the purpose of the team is rooted deeply in customer problems you will discover that it pushes aside internal politics. The purpose of a team gives it the energy to thrive. It is essential that your team knows who its customers are and what their pressing problems are. You need to find ways to bring customer stories and customer experiences before your team’s eyes.
There is a reason that the world’s major religions have tenants that point out happiness and purpose is best found in the service of others. I was struck by the story Scott Thompson and the founding of Charity: Water. Scott had grown up in a strict religious home. He had loving parents but as he reached his teenage years he sought to break free of all that. The next decade found him as one of the most successful club promoters in NYC. For him this meant he fed his every desire, nights were filled with drugs, sex and ego. While I am not attempting to moralize too much about this, it was apparent that Scott felt empty. Was this all there was to life? He faced a crisis and left the NYC scene, lived a year on a Mercy Ship documenting the surgeries performed to save lives. He then went on to found Charity: Water one of the largest (if not the largest) charities for clean water. This new purpose ignited him and brought a like minded team together to do what others thought not possible. What happened? The purpose had real meaning in saving the lives of others. It required a team effort as no one individual could solve these major issues. While most of the time we aren’t building teams around such a high and noble purpose, we should be building teams around serving customers. Customers become the proxy for “others” and get our teams outside of ourselves. It pulls the team to a higher calling resulting in outsized performance.
In many ways you are trying to turn your team into an empathy machine.
3. Process
Leaders often make the mistake of starting with process. Process is a static snapshot of a way the team has over time learned to work. Thus process is a tool and not an end in itself.
The beauty of process is that it automates certain practices and removes the need to reinvent the wheel constantly. The danger of process is that the snapshot cannot capture the “why”. It is based on certain assumptions and when those assumptions change, we often end up with an onerous process that no longer produces the results it should.
When the underlying assumptions change for a process, then the process must change itself. However, process heavy organizations tend to drive out first principle thinkers. To paraphrase my former-CEO, Reed Hastings of Netflix:
“The more talent you have, the less process you need; the more process you have, the less talent you will keep.”
There is a delicate balance between having just the right amount of process vs. having too much. And the funny thing is you can even have an agile process, one that is iterative by nature, become lifeless and completely restrictive. I have provocatively said “Agile doesn’t have a brain.” I mean by that we must inform our processes by the people we have, the purpose we aspire to, the products we are creating. In order to do that we must have some first principle thinkers in our midst as well as those with a strong process muscle.
4. Problems
I have heard the first three articulated before. People, Purpose, Process. In the past I have said that the secret to great teams is getting the Who (people), the What (purpose) and the How (process) right. But this fourth ‘P’ became more evident when I took on an organization of close to 500 people with over 25 legacy products that were constantly breaking. It seemed all I dealt with was problem after problem. It put the team in a reactive mode. The Purpose drives us to be proactive. Problems can push us back on our heels and make us reactive. At one point I felt like I was drowning and had to find a way to switch from being reactive to proactive. I also realized it was hurting the health of the team. Problems show up at the most inconvenient times. They disrupt family life. They wreak havoc on schedules. They are pests.
The switch I flipped in my brain was to think of problems as opportunities to get better What if we could flip common problems into a proactive solution that solves the problem before it arises again? What if we developed heuristics to employ when we see a common problem set show up? Healthy teams need the skills to categorize their common problems, treat them as event triggers and attach a set of rules (heuristics) or a set of tools to each event. Tools and rules are the way to tame problems and turn them into systemic solutions.
5. Product
The simplest definition for product is something being produced.
The definition for thrive is to make progress toward or accomplish a goal in spite of or because of circumstances. The purpose powers the creation of products. So in a real sense, to thrive means to make progress toward or complete a solution or a product for their customers.
A good question to ponder is, “is the team just producing endless features or is it creating leverage by turning to system thinking instead of just feature production?” In the engineering world, platforms are the system architecture or hardware on which the rest of the systems are built. The beauty of platforms is you build them once and you are able to use them over and over in different ways. Creating an abstraction that captures repeatable systems is the hallmark of a team that thinks strategically rather than just tactically. A healthy design organization creates design systems that function as a platform for product creation. A healthy product organization creates a set of hypotheses that help simplify product design. Platforms are one of the ways that Problems can be moved from reactive to proactive state.
6. Pennies
You can understand a lot about a family or a business by the way they spend their money. The same goes for a team. A helpful forensic tool is to analyze the budget and the cost structure of a team. Does the budget actually support the people, purpose, process, problem handling and product creation? Or is there anomalies in the spending that point to a deeper problems?
I once took over an organization that had many issues. As part of the evaluation we dug deep into the finances. Because of the way money was tracked (or not tracked at department level) we determined that we were actually going in the red by $40k/month. This caused us to look at every dollar spent. We found highly paid contractors (simple engineering at over $200/hr). We found licenses for products that we didn’t need and actually tied up team members on items that didn’t need to be addressed. We found a whole team of 30 people being funded for redundant work and were able to give them more meaningful work. The budget wasn’t the only aspect of the team’s troubles, but it certainly pointed us to places we needed to correct and in the process save the company a lot of money. By the next quarter we were able to forecast a surplus of over $1M for the following year. We were able to re-direct the savings into better tools, free up travel budget for higher collaboration, give more control to the teams on smaller budget items thus creating an atmosphere of freedom & responsibility.
Also check out the post on The Who, Why, How & What of Thriving Teams for an updated framework on evaluating teams.