It’s amazing how complex things can get once you’re trying to figure out a working pattern that would satisfy a team of several developers and keep your boat afloat at the same time. It’s a wrong jungle type of problem, where management are trying to keep everything under tight control, living in illusionary world in which every developer can work at any part of a big and growing system. It’s understandable to aim at preventing skill silos, but at the same time experience should indicate that when it comes to large systems, it’s just not going to work like that.
I’m personally a big on small teams of developers. I don’t think you could or indeed should run a Team of developers larger than four individuals. Why four? It’s just an arbitrary figure. I’ve done well with up to four and surely better than with team of five. Having that said, some companies understandably need more horsepower than a team of four developers, nonetheless a project shouldn’t require more than that. If you find yourself in a situation in which you’re running a project with more than four developers, you should reorganize, otherwise sooner or later you’d end up managing the unmanageable.
There’s a bit more maths to it than just arbitrary choice of my personal experience. Consider number of messages in communication matrix. The amount of bulletins, formal meetings, or even just phone calls and e-mails grow exponentially as your team grows. Laws of diminishing results kick in with every team and I estimate are really severe beyond aforementioned number of four. Amount of unproductive work of a large team is just unsustainable in competitive environment. Running a large team of developers, mostly wasting their time, also works as an indicator to your competitors that there’s a space on the market for doing the same thing more efficiently.
Managing effective software workflow means spotting when and where the problems are too big, or realizing that too big team of developers with indistinctive roles is part of the same big problem. Having that said, you really would like to stay ahead of the curve and act proactively before problem occurs. As solving bloated team issue is simple, admitting the problem is hard. Almost all software architectures can be broken up in a way which would allow subdividing big tasks into series of small ones and aligning team sizes according to their manageable competencies. Small teams dedicated to their areas of responsibility means more ownership, which in turn translates into more forward thinking solutions that require less support.