Compact, niche teams doing really interesting things can make or break a product. Well... Not really. That's more click baity than anything. Small teams can do amazing, quick work of features or trim up a backlog full of issues. However, the capacity of small teams isn't constrained by their size. Or lack thereof.
No, what holds back small teams is their ability to effectively review code. Take, for example, two specialized individuals spearing off and creating a whole new micro service. These two folks are likely quite good at what they do. Both exibiting a high amount of autonomy and work capacity in their specified tasks. However, let's say that both of these indivduals are completely illiterate towards one another's code.
Who do they turn to when they have produced a swath of refactorings through their code base? They could ask one another and hope that the resulting code review will be more substance than ceremony. Although, this is usually not the case. The more likely outcome is a review that is speedily done just because one party feels obligated to keep the other unblocked.
While these types of reviews can and will find things like debugger or 'puts' statements, they often times miss the mark on finding the quality, 'code smell' labeled problems in the new code. This seems antithetical though! We are inundated with the idea that small teams are more agile (not Agile) and can pivot much easier when things go South. Which brings us to wonder who's closer to being correct in their assumptions of small teams?
The code produced by these small teams or the folks who are propogating these crazy theroires of small teams?
The code review process isn't everything though. It's a rather small part of a team's process. Never-the-less, it's one that delivers substantially better code. That code has the least amount of bugs, it's more resilient to breaking and stands up when major parts of the system shift. This kind of quality is what we want making it's way into all projects. It's what leads to fewer and fewer runtime errors, greater revenue across the entirety of the business, and perhaps the most important thing of all: developer happiness.
If any team (large or small) is looking to better themselves, quality code reviews are a wonderful start.