I work for a company that is moving heavily into mobile. We find the majority of our customers use our mobile app pretty regularly.
We have tons of things we want to add to it — as well as to deliver all these new features on Andriod- and iOS-native apps.
But I wonder how big we could possible make a mobile development team without making it too big to be practical. Can we have a mobile team that’s 5 people? 10? 50? 100?
If it made sense for us to build that many new features, from an Engineering standpoint is it practical? Or is there some limit of the amount of Engineers that could support a single app (across multiple platforms)?
4
The upper limit for any team size is dictated by the governance in place within the company and the individual projects. As the team grows larger, more governance is required in order to continue to remain productive.
Communication without governance grows by an exponential rate (n*(n-1)) because each team member needs to check in with every other team member in order to introduce significant changes. Remember that communication paths are one-way in this case.
Small development teams get away with less communication because a team of 3 developers only has 6 communication paths.
A=>B; A=>C; B=>A; B=>C; C=>A; C=>B
A team of 4 developers has 12 paths.
A=>B; A=>C; A=>D; B=>A; B=>C; B=>D; C=>A; C=>B; C=>D; D=>A; D=>B; D=>C
Now this is usually manageable for small projects, but things start to break down when the sheer number of communication paths gets to be too much.
How much is too much? It depends. A well modularized application staffed by top-notch A-players can probably sustain a lot more developers with less (formal) governance then a poorly structured application with neophyte developers.
The point of the governance is to eliminate some of the communication pathways, and this is where specialization comes into play. Developers start identifying themselves as “front-end” or “back-end” or “database” or whatever type developers. It usually occurs as the application gets too large for any one person to really understand.
Governance comes into play because Front-end dev Sven normally never needs to talk to the database folk, and he very rarely needs to talk with Todd who is the team lead (or architect) for the back-end devs, and Sven almost never needs to talk to Jane who rules the database layer / roost. Governance allows each developer to work within their normal sphere and minimize who they need to coordinate changes with.
So with a team of 12 developers, instead of having 132 communication paths, you have 3 groups of 12 communication paths plus 6 more communication paths between the 3 team leads.
So that was some fun, fancy-dancy, high-browed intellectual thoughts about teams. Let’s use your specifics for a little less abstraction.
You want to have iOS and Android apps. That’s fine, that’s two teams there.
You have a ton of features you want to add. That’s fine too. You’re going to need teams for UI work, web services, database changes, etc … You now have more groupings to use to limit the total number of communication paths with.
Don’t forget to designate folk to coordinate with other teams. Some companies call these architects, other places call them team leads. Call them what you want, just make sure that you don’t duplicate too much effort between various teams. Again, governance and process play a critical role here so that people focus only on the area they need to change in order to code up the necessary features.