anthony galvin

It's taken me a while to come to this realisation, but I've spent a huge chunk of my life trying to achieve things with teams. Sports teams, software teams, bands, orchestras, actors and product teams. To be fair not all of these notional teams have been successful - but when they work well, teams are awesome.

It's a cliche to say that "being a team player" is important at work. Most of the time this is just a platitude for people who don't rock the boat. A way of saying that the person in question is no trouble. I don't always buy into this team of mates dynamic.

To continue the cricketing viewpoint, Mike Brierley, arguably the greatest exponent of captaincy and understanding the psychology of teams sums it up nicely "If individualists are too powerful, too divisive and too selfish, the team suffers. If they run riot, the notion of team scarcely exists. At the other extreme, some teams can become flat, conformist and dull. Far from running riot, individuality is suppressed."

So there's plenty of scope for the right kind of discussion and a team that's able to sometimes hold divergent points of view, at least for short periods of time.

It's not always easy to identify the right group dynamic from the inside, never mind on the outside. In my experience it's one of the reasons why agencies often struggle with consistently casting high performance teams. Even if resourcing is operating beyond the principle of "availability as a skillset", the people making the decisions when pulling together new project teams are on the outside, and from there the signals of a genuinely good team are almost impossible to detect. In an agency it can sometimes feels like the approach is "We've got this project team performing really well. Now we've delivered everything we should break the team up and make sure this group of individuals never work together again".

I've written recently about some of the challenges in scaling teams across multiple locations, but as well as geography having a significant impact, more people also comes with a time cost.

More people doesn't have to mean your people. As the number of integrations, partners and vendors increase the time cost of managing, motivating and co-ordinating all these different folks can have a significant impact. A small team that has many thrd-party integrations doesn't just have a scope challenge, it also has team management challenge as well.

Perhaps this is the ultimate team challenge - when the team in question isn't just your team, but other teams as well.

It often starts with a sigh. Away from work you hear the obvious sound of frustration when an app or service doesn’t work as expected or crashes at a critical moment. As more and more of our lives are mediated through different glass rectangles, the expectations and importance of delivering brilliant, scalable and reliable experiences on those devices grows.

Which means in practice that the numbers of people involved in creating and engineering the apps and services that people rely on are inevitably large. One of the challenges for people like myself responsible for delivering the software to make all this happen is that with so many people involved how do you create an environment that delivers high quality software and services.

It’s a bit of a management speak truism that everyone on a project is “on the same team”, but in practice that’s not really possible. For some of the global projects I’m working on at Huge, there’s often over 100 folks involved, with a large percentage of these made up of engineers in variety of locations. We have a common objective but in practice we are many teams.

Where location does play a factor is often around balancing time zone coverage so that there’s enough people in each location to ensure effective collaboration. There’s no point adding a single developer with almost no time overlap with anyone else on the project.

However, in practice the amount of overlap doesn’t always have the positive effect people might think. Complex engineering problems require deep focus and an environment that reduces interruption in addition to cross discipline collaboration. The reality of a distributed team is that at some point of the day there are times when there’s fewer people online. Which correlates with fewer interruptions.

Would I choose to have the engineering teams scattered across the planet if it was possible to have everyone in one building. Probably not, but the reality of the work is that this isn’t really possibly, and in practice it’s not the most important piece of the puzzle.