Article summary
I’m coming up on one year in the accelerator program at Atomic Object. During that time, I’ve had the pleasure of working on a small team with only one other developer and on a larger team with seven developers. The dynamics working on small vs. large teams can be quite different. There are pros and cons to both. Both team dynamics offer different learning experiences. It’s all about how you approach the opportunity and what you hope to gain in your professional development. Here are some observations as a junior dev I’ve gathered from working in both team dynamics.
Small Team
My first two engagements at Atomic Object were small two-person teams. As a new developer, this was a great experience as my introduction for a couple of reasons.
Focused Mentorship
Smaller projects usually have a smaller scope and a shorter engagement time. This also means you may be working in a more fast-paced environment and not much work can be done concurrently. As a result, I was able to pair constantly and get a lot of focused mentoring.
Easier Communication
In a small team like this, communication is much easier, and establishing team norms happens naturally. I also had the opportunity to work closely with clients, and this gave me a better chance to build my consultant skills. Also, meetings tend to be much more efficient with lesser people.
On the other hand, with a shorter engagement, fewer opportunities arise to take a deeper dive into certain issues. We found that we needed to be more creative with approaching problems.
Large Team
Afterward, I transitioned to a team that now has seven developers. Projects like these usually have a longer engagement time. Inevitably, larger projects also have a bigger scope and a more complicated system. This can be overwhelming to wrap your head around at first. Ryan Abel’s article 3 Problems Big Software Teams Face and How To Mitigate Them has some great tips on how to gain an understanding of a large and complicated system.
Pairing Opportunities
With more developers come more opportunities to pair and receive different styles of mentorship that span many experience levels. I get to experience different coding styles and learn different ways to approach certain issues. I also get to add different problem-solving techniques to my growing professional developer bank.
Technical Growth
There’s much more work that can be done concurrently. There’s more of a chance to tackle issues on my own. This allows me to gain more comfort in my skills. Plus, there’s a bigger brain bank to pull from if I find myself stuck on an issue. But with more developers working at once, you start to run into other issues. Stories move quickly, so more time is spent on story writing. Merge conflicts are inevitable. There’s a bigger need for an intentional approach to communication.
Ideal Team Size
So, depending on what you hope to gain, there are pros and cons to both types of team dynamics. I’m very glad I have been able to experience working on both. Personally, it was helpful for me to start out on a smaller team because it’s less overwhelming in size and scope. I’m also glad I had the opportunity to transition to a bigger team in order to grow and nurture my technical skills.
What’s your ideal team size?