Grow The Startup, Shrink The Teams

While emphasis is usually put on initial team building, a large organizational development problem appears farther into the startup when company growth begins to accelerate.
Our company quickly grew to almost 200 people in just a couple of years after our mobile event app platforms were adopted by hundreds of the Fortune 1000.

Quite simply, that kind of growth can play hell with a workforce as it expands from a small, intimate corps of developers to a larger group in which employees become disconnected from each other. What begins as a tight-knit group with a common mission can rapidly develop into a type of production line where staff members merely do rote work to keep the project moving. High growth and subsequent change can mean that they lose that entrepreneurial startup edge.

Consequently, a fast-growing company has to look at how to evolve its team concept into a larger, but still collaborative, organization. There are several steps involved in fostering this evolution:

Re-imagine your development resources: Initially, most technology companies use a system of virtual teams, loosely described as matrix management, where workers with different skills come together for a particular task and disperse when it is completed. But as a company grows, a bigger pain develops with how many (or, more precisely, how few) connections people have with each other. Staff can grow more isolated and, as a result, less invested in the ultimate result. A solution to this problem is to move to a project-team structure composed of small, cross-functional and permanent teams or modular units that can work autonomously.

Set up a workable structure: Teams should have 7 - 9 people, each with a specialty that they can contribute to each development project. This creates more agility when creating a new product. It also means projects will be consistently delivered with the same Project Managers, Developers and Quality Assurance people. Also, it should result in management spending more time planning and less time reacting. In addition to the specialized teams, the new structure needs a group of client-delivery team members that serve as floating, on-demand resources called in to provide special support. This could involve unique skills or support for core teams when they are overloaded. Lastly, not all teams can be development teams as described: Some teams, such as those conducting design and content/analytics work more efficiently under a "bucket" scheduling system.

Manage the transition: Suddenly transitioning from one system to another is a recipe for chaos, so staff -- and management -- have to be weaned off old-system thinking and educated in the new. It should also be acknowledged that, while it would be most effective to manage all projects through a core team model, it would be impossible to transition all the work that is currently in the pipeline to fit the new revised structure. There will be a period where existing projects continue with their current team members, while newer projects will be accepted and delivered in the core-team structure. Further, accept that all change involves problems and potential mistakes, so try to standardize procedures and processes, create guidelines and anticipate problems. Try to empower everyone in the organization and create a sense of ownership so individuals automatically react by trying to rectify a problem without delay.