Scaling a Team

Growing any team or organization requires a set of common principles that the team believes in and can iterate on. Therefore, it's best to document them with some semi-permeance — it brings everyone on the same page.

A process allows a team to operate on a standard set of steps - a framework. For example, a logistics team needs a set of processes to transfer a package from one place to another. The process that works for one package will not scale for a million packages, so you have to empower the team to iterate on the defined process. An approach developed when the scale was small should be reviewed and updated with a new set of steps for a bigger scale. Although new learnings occasionally come to light, a well-formed team will always learn from the group's failures, external factors, and other learning events and incorporate them into the updated process.

A software development team should review its processes every few sprints—the larger the team, the slower the change. There should never be a stagnant process. While it does help to have a longer-running standard set of steps, a more frequently updated process executed by a team who can quickly adapt to change will keep any team agile and successful. Inflexibility in learning from external factors is what plagues any large organization. That is why the startups and the upstarts can take on the goliaths. The larger organizations forget what they are there for.

In a software world, a CEO should develop, document business requirements, talk to existing and new customers and their internal teams, perform QA, and be a valuable part of the sprint. It keeps them grounded in reality, but more importantly, it allows them to see how the teams update their processes and how to provide more tools and mentorship to teams to take ownership of their operations. A CEO should never influence the process directly once the team is of a certain size; always allow the team to self-iterate.