Article summary
Switching teams is a constant expectation at Atomic. My previous project was a standard Atomic team: three full-time developers plus a part-time delivery lead. This eventually turned into me being solo on the project while I was wrapping it up. From there, I transitioned onto a much larger team, along the lines of twenty or more people (from Atomic, our client, and another third-party team). Not only was this the largest team I had been on, but it also had the most developers from outside Atomic.
I’ve been on many teams of various sizes, but it’s important to be aware of how every team functions, interacts, and works together.
Large Teams
Pros
Because there are many people on the team, there are many different backgrounds, which can lead to unique solutions. There’s a greater chance that someone on the team has come across a given problem in the past and can propose a solution that worked for them.
Having many team members also makes it more likely that you’ll have various levels of experience. Junior and senior developers can both learn from each other.
Being exposed to new ideas can make developers more well rounded and prepared for whatever a project brings them.
Cons
If there are too many conflicting opinions, it can be hard to make important decisions about the project. Differing opinions can be beneficial to the project, but strong, unwavering opinions may not be.
Some work can easily be split between many individuals and pairs on a team. However, this isn’t always the case. If work isn’t easily parallelized, people can get blocked waiting for their teammates — stuck without other work they could pick up in the meantime.
Small Teams
Pros
On a smaller team, it’s easier to collaborate with everyone. Whether this means quickly gathering the team into a huddle to work through a problem or pairing with everyone on the team during the day, working closely together keeps everyone in alignment. Everyone on the team should know or have exposure to most parts of the codebase. Even if a developer isn’t familiar with an area of the code, they should easily be able to pull in someone who does.
Smaller teams mean fewer schedules to juggle. This makes meeting as a team much easier. Teams can work more flexibly, scheduling team syncs as needed rather than making formal meetings far in advance.
Cons
Teams of any size can have members from different backgrounds, but on a small team, you’re likely to have a smaller variety. This gives you a smaller variety of experiences, which makes it more difficult to find solutions to difficult problems.
Smaller teams also suffer more if even one person is on vacation or sick. If a team of three has one person out, that’s 33% of the team. That doesn’t mean the team is 33% less effective, but productivity will take more of a hit than it would on a twenty-person team.
There are many pros and cons to every team size — far more than I listed here. It’s important to be adaptable to any size team, especially if there’s no telling what project will be next.