How big should a team be?
Let me share a recent experience that made me rethink the concept of team sizes and the dynamics within a cohesive unit. Last week, during a mentoring session, I discussed the age-old question of "How big should a team be?"
It was with an engineering manager who felt overwhelmed by managing a team of eight to ten developers, plus UX designers, testers, and operations folks. It got me thinking about the importance of team cohesion and effective collaboration—a topic that resonated deeply in my experience as a founder and CTO.
The Problem: The Pitfalls of Oversized Teams
Picture this: you have a team of developers, some UX designers, testers, and maybe even an operations person. All of these individuals are assigned to work on a seemingly small application. A performance issue arises—something that needs immediate attention. The request gets handed to the frontend team, who quickly dismisses it as a backend issue. The backend team, in turn, claims it's a front-end problem. UX isn’t even consulted, despite being critical to the experience.
This endless cycle of pushing responsibilities over the fence is all too common. The problem isn't that people don't care; the structure creates barriers. Instead of working together as a unit to solve a shared problem, individuals operate in silos. This brings us to the root issue: ownership breaks down when teams are too large or organized by strict roles instead of missions. Accountability fractures, and ultimately, so does cohesion.
Miro Board was used during the stream.
My Actions: Bringing Everyone Together
I’ve experienced firsthand how this fragmentation can derail progress. In my own projects, I learned that the key to solving these problems lies in restructuring teams not around roles but around the mission—the outcome they are trying to achieve. It’s about creating a team that, no matter how specialized, feels ownership over the entire problem, not just their individual slice.
During the mentoring session, I shared my approach: Instead of splitting a team into isolated silos like backend, frontend, and UX, create interdisciplinary teams. Everyone needed to solve a problem should be involved in the conversation from the beginning—from UX designers to backend engineers. They all bring something unique to the table, and only when those talents are combined can you find effective, sustainable solutions.
One analogy that came up was playing soccer as a kid. You didn’t have different departments on the field; everyone played with a shared goal—to score. You adapted your position based on the situation, trusted your teammates, and played cohesively as one unit. That’s how a high-performing engineering team should function, too—as a cohesive, mission-driven unit.
The Result: Small, Cohesive, Mission-Driven Teams
After implementing these changes in my teams, I found that smaller teams (ideally around 5 to 10 people) that share full ownership of the outcome tend to function more effectively. We worked better, faster, and with far less friction. In larger organizations, I’ve seen similar transformations when cross-functional teams are free to own a problem end-to-end rather than waiting for tasks to be passed along. This isn’t just about efficiency; it’s about creating a work environment that empowers people and fosters trust.
So, my question for you all: Have you ever been part of a cohesive, mission-driven team where everyone felt ownership of the outcome? Or do you still find yourself navigating the frustrations of silos and unclear responsibilities? I’d love to hear about your experiences and how you've tackled similar challenges.
Let’s keep this conversation going; maybe together, we can redefine what working effectively as a team means.
Can You Guess The Right Team Size?