Fast Autonomous Teams
/
In this presentation I’ll discuss organizational structures we’ve observed in various development environments. Some generate slow development projects and others contribute to faster development cycle time.
Steven Wheelwright (HBS), described four types of product development team structures;
functional hierarchy
lightweight
heavyweight
autonomous
We’ve added speed and accountability to his model.
We’ve worked with all four configurations and many variations in between. We’ve learned to adapt the structure to the readiness the organization and their willingness to transfer power laterally to teams--away from the vertical or functional hierarchy.
Functional hierarchy
The classic structure where information moves horizontally up and down the hierarchy. Each function in the development process exists in silos with high walls in between. Someone once called this “silage!” The development effort has to navigate between these silos. Only a few people have contact with the market and customers. Information is filtered. Product development is slow. Power is concentrated in the hierarchy. It tends to be inwardly focused and few are accountable for the product, most are accountable to only their functions. Product quality and margin suffer.
Lightweight teams
The traditional response to the inefficiencies of the functional hierarchy. The idea is to get some lateral coordination without sacrificing the vertical power structure. Information still flows up and down in order to move horizontally since power (i.e. budget) resides in the functions. Typically engineering managers lead these lightweight development teams. They are called project managers, but really they are coordinators. They start out with power, but are corrected by the hierarchy when they get overconfident. They are given responsibility for product delivery, but little authority to execute. They don’t control people or budget, spend most of their time “negotiating” and pleading for cooperation from functional managers who control things. These teams still don’t really connect with the customer who are sheltered by marketing. Information from the customer is translated by marketing to these, primarily engineering focused teams. It is not uncommon for people to be on ten of these teams at once and for a project manager to be managing five or more at the same time. This structure provides a little more accountability to the product, but still is slow since the resource under-capacity problem is masked by lots of people trying very hard to make this work.
Heavyweight teams
The next evolution of team structure designed to make the team accountable for the success or failure of a product development effort and to improve the speed and efficiency of the process. This means the functional hierarchy needs to be willing to share power with the lateral team. Many times this means the program manager shares budget and resource allocation decisions with the functions. Further, they can, in this configuration, provide performance reviews to their team members, or have at least 50% input. This really is the game changer in terms of power distribution. Decision-making is faster as information moves laterally. Also these teams have a direct line to the customer and market. This creates “customer-pull” and tends to accelerate development. Decisions stay within the team and they have higher levels of authority to determine technical direction. Further, these teams tend to be more dedicated to a single development project. This structure costs more, but they know that this increase in R&D expense is offset by more than 10x with what is gained in cycle time improvement and products that meet customer needs. These products are also more profitable since the ASP is higher at introduction, due to the fast cycle time.
Self-directed autonomous teams
The most advanced stage of organizational development. These are fully dedicated and in most cases physically separate self contained teams. They are lead my senior general managers. They have all the functions of a small business, like a start-up. They are directly connected to the customer and do continuous VOC through the development cycle. It is hard to distinguish functions in these teams, each person knows a lot about everyone else's domain. Marketing and engineering are virtually indistinguishable. The functional hierarchy is designed to provision and not interrupt these teams. They are set up to support them and provide resources, rather than control them. These self-directed teams are very fast and focused and tend to have a greater success rate with products that are on time and exceed customer needs.
So where are you in this continuum?
Or is your structure some type of hybrid configuration. Most organizations we work with will rate themselves higher (to the right) than they actually are in practice. This represents the desire to move to the right, but the reality is that the functional hierarchy pulls them back to the left. Some will set up an autonomous team, as a one time event, and then revert back to the more comfortable “lightweight teams.” Others have programs to gradually migrate to the right as they develop the skills to operate in this space. If speed is critical, moving to the right is essential.