Component Team, Feature Team and Tiger Team

Our managers had a heated debate on team ownership model. The topic is worth continuous debate because “Information system’s architecture tend to reflect human organization’s structure.”, as stated in Conway’s Law. When organization structure stops making sense, information flow will choke. There are some common ways we can organize teams: 1. Component based team: teams following this model are the owners of hardware or software components. Between components there are (ideally) clearly defined interfaces. When a component gets too complicated, does too many things, becomes a monolithic monster - we refactor them into smaller components. Component ownerships are long term. They often launch self driven projects to improve the properties of the components: availability, scalability, maintainability etc. But component ownership model tends to build siloed mentality: “your priority is not my priority. When a feature crossing the boundaries of multiple components needs to be launched under a tight deadline, component ownership can become the obstacle. 2. Feature based team: teams following this model will work on multiple components to get things done. Feature team's structure tend to be short term. When a feature is launched, it is common to regroup the team for the next project. Although feature teams may move faster, the lack of long term ownership may give a feeling of drifting: constantly moving from one project to another, only touching the surface of involved components. If not careful, engineers working in feature teams might build a knowledge base that is 1 mile wide but 1 inch deep. There is also a dilemma who will be responsible for the long term maintenance and continuous improvement after a feature is launched. 3. Hybrid of Component and Feature based team: Except for consulting or outsourcing companies pure feature teams are rare. Eventually a team will become long term owner of some components. When feature teams need to change a component, they get the component owner’s buy in and approvals. 4. Tiger team: Tiger teams are special feature teams that are formed from top engineers of the organization. They are put together temporarily to get high impact initiatives done under deadlines. It is tempting to form Tiger teams whenever we run into big blockers. But be warned, Tiger teams are based on super hero mentality, they get things done but can also leave a mess. I do use a special Tiger team model: I always have a few Sr. SDEs reporting to me directly. I use them to launch strategic initiatives: break new ground, take big risks but hope to get big returns. I need to manage the Tiger team carefully so their early success does translate into long term benefit and ownership for the org nicely. Like most things in life, there isn't a “one size fit all” answer, the truth is always relative to the context and likely sits somewhere in the middle of the spectrum.