Expansion teams

Engineering teams build up efficiencies over time. Many organizations utilize strategies like reorgs, layoffs, org-wide process changes, and realignment of ownership to create efficiencies. Each of these breaks down the team’s efficiencies gained, with some having a more significant impact than others.

While the team has certainty in how it does things, who is on the team, and what it works on, they are building efficiencies. Communication gets easier. Work moves through the process without as much blocking. Engineers become knowledgeable owners of the codebase that they love or love to hate. They collaborate with outside teams more effectively. They progressively increase their ROI.

Significant changes in the team ecosystem can render an engineering team functionally ‘new.’ Communication patterns need rebuilt when people are added or removed from the team. Processes will be clunky and expereince bottlenecks. Engineers may not feel like they are owners that can change and make improvements to the codebase. They will need to build new connections with other teams. Their ROI will take time to build.

These large scale type of changes can be helpful in the long term and may even need to happen for a business to survive. However, strategy makers & executors need to put the loss of efficiencies that a team has gained into the short/mid-term equation while deciding if the possible gains or risk mitigation are worth the proposed change and then adjust roadmaps and revenue from new features/product lines in order to accurately predict a business' future position.

If you like sports, this is my go-to summmary that paints the picture well: Large changes to an established engineering team turn them into an expansion team. Expansion teams rarely win the championship.