What Tuckman Missed And A Better Way To Think About Teams Getting Better

High-Performing Teams Take Time

There’s a mistake we make when looking at teams within software and game development.

We tend to make the assumption that a team can be broken down into a list of “Role - Seniority” dev spots and then as long as all the matching “Role - Seniority” devs exist on the team, it will function somewhat similarly to any other combination sharing those same roles and seniorities.

An example: let’s say I knew I wanted a content pipeline that could produce NPCs for an open world game. There were a lot of NPCs and they had a lot of unique stuff about them to make the world feel immersive.

I might create a rough guess that what I’d need is something like...

OK, so there’s almost 30 people you’ve got on this team. Depending on the game, you might need more or less animators, VFX, QA, Character Artists, or you might need different specializations, but let’s just assume this is right for the game I was trying to make.

When we look at a team like this before it exists, it makes sense to break it down by expertise and level. Unfortunately, we fail to adapt our thinking once a team starts working together.

Because the exact same team (from a role/seniority angle) may produce dramatically different results.

Intuitively, we understand this. We know that not all groups of 4 engineers or whatever put together on a project will perform the same, even if they have identical experience levels.

A huge factor in understanding team effectiveness is how well a team works together. And if a team hasn’t worked together, that means their effectiveness is a bit of a giant question mark and likely much lower than you’d like. Because some teams can struggle for long periods of time to “find their feet” as a group and really start getting anywhere, while others will more quickly mesh.

Part of the job of leaders both in and around the team (so this includes stakeholders or senior managers and the like) is to help teams become more and more effective over time. It’s also to recognize that some people may be more or less important to the team for reasons that don’t show up on the roles spreadsheet.

I’ve seen associates that were quite gifted at encouraging the right conversations, or filling in when a key leader wasn’t around to guide a meeting. I’ve seen leaders who didn’t just lead but also inspired. There are people who others trust more and are willing to talk to that can become, for lack of a better term, the “heart” of the team.

You can try to design around some of these things, and sometimes there is wisdom in that so you avoid getting too many analytical types and not enough “let’s try something” types into a space. A balance of personalities and strengths is good!

But honestly, a lot of the time the groups that become high performing seem to get there in an emergent (rather than designed) way. Sometimes on paper it even seems like it SHOULDN’T work, but it does.

Now, some of you may be thinking in your head, “This sounds like the Tuckman model!” and I hate to disappoint you, but I am not a fan of the modern interpretations of Tuckman’s model.

The Trouble with Tuckman

For those unfamiliar, Tuckman is often interpreted to mean that teams go through a set of predictable stages of team development, starting at Forming, then moving through Storming, Norming, and Performing. Some add in Mourning or Adjourning when a team gets shut down. The idea is often expressed that teams must go through these phases, and there are different ways for leaders to show up and lead in each one to help the teams navigate to the next stage.

The valuable part of that interpretation of Tuckman is how leaders show up at each stage. It recognizes that a leader on a “performing” team may have the identical responsibilities to a leader working with a “forming” team, but use very different sets of skills in order to be effective because of where each team is at.

The less valuable (read: wrong) part is the idea that all teams must go through all the phases in order. Because in reality teams often skip, stall, or regress in a way that is much more chaotic than the model would suggest.

The other marked mistake of modern interpretations of Tuckman is the belief that every time a team changes, it resets progress back to Forming.

I have just not found the model as predictive as people want it to be in reality. Sometimes I’ve had someone leave or join a team and it has seemed to improve. Sometimes our goal or whatever has changed and the team has rolled right on unaffected. Sometimes a team regresses for no reason, or doesn’t seem to hit “storming” at all despite regular shifts to how they needed to operate.

When it comes to teams and developing high performance, I much prefer a different model I've been using for some time. I call it "midpoint theory."

Midpoint Theory

Midpoint theory is a different model of understanding how teams improve over time. The basic idea: as teams work together, they eventually hit “midpoints” or challenges/crises the team either overcomes or fails to overcome together. Each time one of these is hit, the team either rises to the occasion and accomplishes the goal, or fails. Those that succeed tend to be stronger teams and better able to handle the next “midpoint,” while those that fail tend to become more fragile.

A single failure doesn’t necessarily doom a team, nor do a few successes guarantee high performance, but the broad idea is that as teams overcome difficult obstacles together, their ability to do so again rises. They’ve learned, grown, and are now more capable.

While not perfect, I find this to be a stronger model of how teams improve based on my experience. And it’s one that challenges the idea that all I need is a bunch of the right people according to their role/seniority and I will get a stable output (perhaps with some allowance for Tuckman's stages).

People need to learn how to work with each other. But teams that never face challenges never have to really lean on each other. In the absence of meaningful obstacles, some teams will likely stall in their development, or even potentially decay (I’ve seen both). But when a team is faced with challenges that force them to band together and figure out how to overcome those challenges, they don’t just solve the individual problem, they learn that together they can solve difficult problems in general.

Leaders play a significant role in this. Because they provide the direction and ask (sometimes dumb) questions and encourage and support but also hold people accountable and maintain the bar for what’s acceptable, they create the space for teams to take on difficulties while simultaneously helping them overcome them.

And this is what I’ve seen. The teams that you can get tackling hard problems as a collaborative unit rather than a group of individuals are the teams that become the most effective. Often, it’s in a way they hardly realize is happening. But I’ve led and observed teams over time, and the vast difference in performance between the same team with nearly identical personnel just 12 months apart almost boggles the mind. The first team could do basic tasks but struggled to provide real value. The second team exceeded expectations across every angle you could imagine. Outperformance went from a pipe dream to standard operating procedure. Yet it was the same team. And I’ll note: this wasn’t because they all started working longer hours or sacrificing their lives and health. Because they didn’t.

They learned how to work with each other effectively, and it created more positive outcomes than anyone expected.

The Best Teams Are More Than The Individuals They Contain

I watched a video recently by Chet Faliszek talking about the reason so many game teams fail that no one talks about. It’s what got me thinking about this subject. At one point, Chet says something like, “When I worked at Valve, the thing I learned most was ... Valve.” He described realizing what the people around him were and weren’t capable of, who to trust, who knew different parts of the engine or code, how to get stuff when he needed it, etc.

Teams and organizations are not entities of fixed-value based on the number of people in various roles/seniorities. When someone watches a very small team outperform expectations to an insane degree despite them being arguably worse craftspeople than many devs working at the “best” companies in a space, it’s often chalked up to something like grit, or hard work, or whatever. And that plays a role, I won’t deny it.

But a bigger factor is this: a team of people - perhaps all of whom the broader industry might consider “junior” - spending time together, overcoming challenges, and figuring out who each other are can reach unexpectedly high levels of performance. Despite having less experience from an industry lens, they have gotten lots of experience with each other in a very practical way. And it unlocks performance that seems unreasonable if you can only see role/seniority.

I think this is how smaller teams, whether in indie dev or internal to larger studios, sometimes blow away expectations and leave everyone wondering, “How the heck did they do that?” But it makes sense. Often, those outside are looking at the product of years spent learning not just the work, but each other.

The trick though, and this one is really tough, is that a lot of what they’ve learned is how to work as a specific unit together.

Yes, some of their skills and grit and attitude, etc. may transfer to their next role. But if you take that team apart, they are unlikely to be as successful as individuals on other teams. I’ve seen this tried. A team that had spent years becoming high performing was broken apart to “spread the goodness” around. Well, it didn’t work. And it frustrated the individuals who went from being on a high performing team together to suddenly being on much less functional teams.

The end result: maybe slightly better teams, but also the loss of some of these high performers as they quit, fed up with the struggle of being on teams that couldn’t keep up with what they felt themselves capable of. Overall, it felt like a pretty bad net loss to the org.

The real problem here is you don’t just need to invest in individuals, you need to invest in teams. Then you need to challenge them, and hopefully have the leadership and structures in place that help them overcome.

If you’ve ever been on a team that is genuinely high performance, it’s an amazing feeling. There is so much that seems possible. You kinda never want to leave.

But it takes time to build that team.

Be careful not to fall into the trap of thinking any group of the right titles will give you what you need. Yes, some will be able to eventually figure each other out and outpace all of your expectations, but without time, challenge, and the support of their leads, you may get a team that looks perfect on paper but can’t seem to produce anything that matters.

If you’re curious, here’s Chet’s video: https://youtu.be/Lmuy4uUPytk

Give teams the time they need. Don’t think people are interchangeable cogs, especially not in a group that is highly performant. As a leader, recognize your ability to have a positive impact, and don’t prevent your team from ever facing hard things. Instead, help them overcome them, and eventually you might help grow a team that can conquer whatever you throw at them.

Hope this was helpful!

Ben C.
Building Better Games

P.S.
The closest thing I can find to what I now call "Midpoint Theory" is Dr. Connie Gersick's model on "punctuated equilibrium." I seem to have attached several other ideas to it, possibly from other models. So what I'm calling "midpoint theory" is not her model. I do think there is some good academic research that supports what I've described above, but I don't want you to confuse what I've got with Dr. Gersick's work. Feel free to shoot me an email if you want some of the studies I think are related!