I’m currently working on the largest Atomic team of my career so far. It includes a broad range of skills, from Accelerator members to Atoms past their 20-year company anniversary and everything in between. And being a consultancy, we’ve collectively experienced a whole lot of languages, platforms, patterns, and paradigms that are culminating in an excellent solution for our client.
I joined this project relatively late in the game, and at first I was a little nervous about being on such a large team – not for any reason in particular, but simply because it’s about 25% larger than any other I’d been on before. I knew it would be a challenge to navigate the team size and figure out who knows what, who’s in charge of what (explicitly and implicitly), and how I could provide value. And I did not know whether I’d enjoy the dynamics as much as all of the smaller teams I’ve been a part of.
Well, I can happily report that those challenges were not so bad, and there are some really great aspects of being on a large team. Here are some of the most important ones:
1. More Inspiration to Learn New Skills
Small teams tend to develop a mode of working pretty quickly, and then not change much. Teammates adjust to each other’s preference, everyone naturally settles on some common tools and rules. That’s a good thing because it puts the whole team into a very productive flow. However, that dynamic does not encourage teammates to learn brand new skills. (This doesn’t mean teammates on small teams do not or cannot learn new skills! Just that inspiration has to come from factors other than team dynamics.)
On a large team, it’s much less likely that everyone will naturally settle on the same toolsets and habits. Instead, I’m noticing that everyone continuously adapts based on who they’re working with. What this means for me is that, instead of learning from a couple of people over the project lifespan, I’m learning from 10. From pairing with (and reviewing pull requests from) so many different people, I’ve been inspired to learn lots of new things – from new C# testing techniques, to prompt engineering with Codex, to vim commands I had never known or had long forgotten.
And I think this benefit actually compounds over time. Because all of my teammates are continuously learning from each other, the same pair of developers may have brand new skills and habits to share month to month as pairs shift around.
2. Meta-teaching and Learning
One unexpected benefit to working on a large team has been that I have learned about teaching more so than on smaller teams. I think there are two reasons for this.
The first is that I’m teaching different people (my pairs) from sprint to sprint. And because different people have different styles and preferences when in comes to learning, I’ve had to adapt how I teach accordingly. For example, some people like to thoroughly understand a concept before trying it out in practice, while others prefer to learn by diving right in and making mistakes. Some people need frequent repetition, or relation to other concepts, or highly precise wording, or concrete examples. Working with so many pairs has helped me get better at recognizing all of these different learning styles and know how to work with them productively.
The second is that I get to watch more people teach and learn. When you are directly learning from somebody, you’re naturally focused on the content of what they’re teaching, not how they’re teaching it. But when you are watching somebody teach someone else, you get to abstractly observe how effective the teaching is. You can see the learner’s reaction and understand what the teacher did right and wrong. You can also see them explain things differently than how you would have done it. I think absorbing these interactions from my co-workers, even passively, has helped me become a better teacher.
Of course, these aren’t totally unique to small teams. But the more numerous combinations of people teaching and learning from each other on a large team means there’s more to gain continuously over time.
3. Opportunities to Explore
Clients care most about the overall progress and velocity of a project, not how individual teammates are splitting up the work. This means that on a small team, everybody needs to continuously contribute toward the immediate project goals, and a blip in individual productivity will tangibly affect the team’s velocity.
For a larger team on the other hand, there’s a little more wiggle room for individuals to explore tangents while the rest of the team delivers to keep velocity up. These explorations can be thought of as “investments” that may or may not pay off. Examples include integrating a new tool, overhauling tests or documentation, refactoring a significant amount of code, etc. These investments are also important on a small teams, but they tend to require more “overhead” in planning, negotiating, and tracking. Because velocity is naturally more smooth on large teams, it’s simply less risky for a developer or pair to run an experiment over the course of a day or two, or even a whole sprint. Of course these need to be planned out by the overall team. But the opportunities to experiment and explore are more numerous for large teams.
One Big Caveat
These benefits of working on a large team (especially the first two) majorly depend on one thing: pairing. If teammates are working solo, then there’s not much practical difference between a small or large team as far as development goes. And pairing is still hugely beneficial on small teams. But I’ve come to realize that it’s especially beneficial on a large team for the reasons above (and also for reasons not already discussed, like preventing knowledge silos).
So if you’re on a large team that isn’t already practicing pragmatic pairing, then I suggest you start a conversation about it!