svpg.com · March 10, 2015
Virtually every leading tech company has jumped on the empowered, dedicated/durable, cross-functional, collaborative product team bandwagon, and I think things are much better for it. I don’t see very many companies that are still using the old models (primarily the pool model).
The results speak for themselves, but I attribute most of the benefits to the increased level of motivation, and true sense of ownership, when teams feel more in control of their own destiny.
However, while most leaders tell me they have empowered, autonomous teams, some of the people on those teams complain to me that they don’t always feel so empowered or autonomous. Whenever this happens, I try to get to the specifics of just what it is that the team is not able to decide, or where they feel constrained.
Mostly what I hear falls into one of two cases:
In the first case, the team simply isn’t trusted yet by management, and management is reluctant to give too long of a rope to the team.
In the second case, the team is wanting to change something that the leaders had assumed was part of the foundation.
In general, most teams would probably agree that there are some things that are wide open for the team to do as they think best, and other areas that are part of the common foundation that all teams share.
As an example of the latter, it would be very unusual for each team to select it’s own software configuration management tool. If the engineering team has standardized on GitHub, then that is usually considered part of the foundation. Even if one team had a strong preference for a different tool, the total cost to the organization would likely far outweigh any benefits.
While this might be a straight-forward example, there are many others that are not so clear.
For example, should each team be able to approach test automation in their own way? Should they be able to select the programming languages they wish to use? What about user interface frameworks? What about browser compatibility? How about expensive features like “off-line support.” How about the flavor of Agile they wish to use? And does every team really need to support several company-wide product initiatives?
As is so often the case with product, things boil down to a trade-off; in this case between team's autonomy, and leverage of the foundation.
I will also confess here that while I love the core notion of autonomous, empowered teams, I am also a big fan of investing in the foundation. Building a strong foundation that all teams can leverage to create amazing products and experiences much faster than they would otherwise.
In this article I wanted to discuss this trade-off openly. For the record, I do not believe that there is one answer to this question. I think it is different for each company and even for each team. Everything depends on several factors, which I’ll discuss here:
Considerations:
Team Skill Level:
There are roughly three situations here: 1) “A team” - a experienced team of smart creatives that can be entrusted to make good choices; 2) “B team” these people have the right intentions but may not have the level of experience necessary to make good decisions in many cases, and may need some assistance; and 3) “C team” this is a junior team that may not even know what they don’t know yet. These teams can unintentionally cause substantial issues without significant coaching.
Importance of Speed:
One of the main arguments for leverage is speed. The logic goes that teams should be able to build on the work of their colleagues and not spend time re-inventing the wheel. However, sometimes it’s simply an accepted and acknowledged cost of empowerment to allow teams to potentially duplicate areas or proceed slower in the name of autonomy. Other times the viability of the business depends on this leverage.
Importance of Integration:
In some companies, the portfolio is a set of related but largely independent products, where integration and leverage is less important. In other companies, the portfolio is about a set of highly integrated products, where integration leverage is critical. This boils down to whether the team should optimize for their particular solution, or optimize for the company as a whole.
Source of Innovation:
If the main sources of future innovation are necessary at the foundation level, then there will need to be more freedom for teams to re-visit core components. If the main sources of innovation are expected to be at the solution level, then the company needs to encourage less re-visiting of the foundation, and instead focus the creativity on application level innovations.
Company Size and Locations:
Many of the problematic issues with autonomy arise due to issues of scale. As companies grow, and especially as companies have teams in disperse locations, leverage both becomes more important and more difficult. Some companies try to deal with this with the “center of excellence” concept where leverage is focused on teams in a physical location. Others try stronger holistic roles. Yet others add process.
Company Culture:
It is also important to acknowledge the role that an emphasis on autonomy vs. leverage plays in team culture. The further on the the spectrum that the company pushes towards leverage, this can be perceived by the teams as chipping away at their level of autonomy. This may be acceptable for B and C level teams, but more problematic for A level teams.
Maturity of Technology:
One very common problem is to try to standardize on a common foundation prematurely. The foundation isn’t yet ready for prime-time, in the sense of the leverage it is designed to provide. If you push too hard on leverage before the foundation is ready, you can truly hurt the teams that are counting on this foundation. Building on a house of cards.
Importance to Business:
Assuming the foundation is solid, there’s likely more risk in a team not leveraging that foundation. This might be fine for some areas but with products or initiatives that are business critical, it becomes a question of which battles to pick.
Level of Accountability:
Another factor is the level of accountability that goes along with the empowerment and autonomy. If there’s no accountability, and especially if you don’t have strong “A” teams, there’s little reason for the teams to stress about these trade-offs. But you want the teams to stress over these trade-offs. If I believe the team is strong and they fully understand the consequences and risks, and yet they still feel they need to ignore or replace a key component of the foundation, then I tend to side with that team.
As you can see there’s plenty of considerations. However, I find if you discuss these topics openly most teams are reasonable. Sometimes just a few key questions asking about some of the implications can help teams make better decisions regarding this trade-off.
If you find that teams are consistently making poor decisions in this regard, you may need to consider the experience level of the people on the team, and probably spend more time ensuring that team has the full business context.