On scaling up teams

I’ve been doing a lot of reading on teams lately, coming up with pretty common trends, such as the importance of good team dynamics, namely people are a huge reason why a team is productive or not. Or in other words, throwing a bunch of random people together an expecting a good team to emerge is a pretty big anti-pattern if there ever was one.

What I’ve found is most people’s theories on team dynamics and building a good team tends to scale to around a dozen folks max. But what happens when your team gets larger?  All of a sudden that tight knit group begins to fracture into their own tribes, which is when the dreaded “office politics” begin to emerge.

I was reading this blog post the other day, which really spelled out what happens. Quoting from them…

The craft itself – the creation of that new business model and new product to solve a big, painful problem,  is a smaller and smaller portion of the time and energy pie chart (at least, for managers/execs/founders). In some ways, that’s a sad, frustrating thing. And in other ways, it’s a healthy, normal part of  scaling.

Why? Because getting bigger and working cohesively toward common goals comes into conflict with so much of human nature.

Human nature dictates that we:

  • Form tribes to build identity and camraderie – yet in a scaling startup, this causes untenable, painful, progress-stopping inter-team rivalries.
  • Invent a common enemy upon which we can heap blame and against which we can fight – sadly, inside the tribes that naturally form, there’s often a tendency to create that common enemy internally (it could be marketing vs. engineering or testing vs. production or sales vs. execs, or any number of others).
  • Minimize the positives and focus on the negatives – that could be feedback from customers, internal critiques, manager reviews, product imperfections, or weaknesses in process. It’s so easy to forget that we somehow beat the formidable odds against building something that worked, something that attracted customers, something that scaled, and a company where hundreds of people really do want to work.
  • Resist change at all costs – yet in a scaling startup, change is the only constant, and processes, procedures, formats, teams, and everything else has to change to be successful.
  • Act emotionally, yet believe our decisions to be driven solely by logic – we tell ourselves we act rationally, but can easily prove that irrational biases rule our minds. This wouldn’t be nearly as dangerous if we could recognize these biases, but in another failing of human nature, we cannot – we cling to the notion that our decisions, unlike the rest of our species, are uniquely logical.
  • Lose empathy as our numbers grow – tragically, when we need empathy the most (as an organization gets bigger and there are more people to consider and more complexities between them), our nature is to rescind it. It’s easy to empathize with a small group you see everyday, but much harder to extend that empathy to everyone in a larger group (especially those you may not know well).
  • Create rules and process to prevent against repeats of singular abuses – the old adage of one bad apple ruining the whole bunch becomes more and more likely the larger a startup grows. Process can be wonderful, but sometimes we create a process just to ward against some bad behavior from a former employeee and, by doing so, ruin the company a little more for everyone. Use process to free and enable, not to punish and restrict.
  • Irrationally romanticize the past – “Remember how things used to be? It was so much better three years ago when I first started here and…” -everyone at any organization, ever. But I remember three years ago. It sucked compared to today. Our ability to delight customers paled in comparison. Our ability to attract talent was in the toilet. Fear about our budget and our bottom line was a daily occurrence. 2013 is superior in so many ways and I know it, but even still find myself fondly remembering (or, rather, misremembering) back in 2010 when (in my human-addled mind) it all seemed so much easier.

This really nailed it on the head; as a small and nimble team, the sense of camaraderie gives you this sense of security and drive. And this is a good thing, as in the early days the focus on getting a product to market and getting a revenue stream established gives a team clear vision and goals. But when you hit one of those plateaus, things get a bit more cloudy on where to go from there.

I don’t think there’s a magic bullet to avoid all of this. Nor can you try to cling on avoiding team growth as a way around this. You need to know it’s coming, and make sure you don’t let the larger team grow apart.


2 thoughts on “On scaling up teams

  1. Interesting info about human behaving. I would personally recommend splitting developers or employees to more smaller team. From this team you can make team of teams where you select one guy as a leader of each team (scrum master if you use scrum) and let him meet with other team leads.

    The worst thing is “Minimize the positives and focus on the negatives” point. When you have team of 5 people and one of them is mainly negativy it distrubs 4 other people… these are going to be negative in same time as well… But if you have team of 20 or more people then it’s much easier to go all negative and disturb rest of the team. Main problem here is that bigger the group is, bigger is the chance of someone going negative from time to time.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s