Autonomy vs. Initiatives

To continue on the series on team autonomy (see autonomy vs. leverage, autonomy vs. mission and autonomy vs. ownership), I wanted to add one more important dimension to this discussion which concerns the practical implications of working on large, multi-team initiatives.

First, when I say “initiative” I’m referring to those product efforts that necessarily span many teams.  Common examples of this include: a site usability redesign, or a move to responsive design, or an internationalization and localization effort for a significant new geography such as China.  These are essentially important efforts but usually would require the coordinated efforts of many if not all of your product teams to pull off.

Technically, a re-platforming effort such as moving to a new architecture or technology base for scalability or performance reasons would be considered an initiative as well, but we handle these tech debt initiatives differently so I’m not referring to that type of work in this article.

Let’s set aside the notion of whether doing this initiative is a good thing to do or not.  I discussed that topic in the article on Autonomy vs. Mission.  Let’s just assume here that we all agree this is a good and important thing to do.  The purpose of this article is to discuss the three main ways teams tackle these sorts of large and complex initiatives.

Here’s the thing.  By definition, we have a complex project that we need to figure out, and we have many teams that will be contributing to this.  While each team has its own details to work out, the bigger question is how and who will lead this?  If the initiative is to adapt the product offering for the Chinese market, then do we send every team to China to figure this out?  That wouldn’t make much sense, and it’s very possible that each would come to somewhat different conclusions.

Lead Team Strategy:

The main way teams tackle this is that they identify one team that will take the primary role in leading this initiative.  That means the lead role in discovery and also delivery.  They will of course depend on work from many if not all of the teams, but they’ll be driving and coordinating.  For example, they might identify a set of customers to work closely with to determine the necessary product changes, and then help to divide and conquer on the necessary work (discovery and delivery).

The benefit of this approach is clear ownership and responsibility.  We of course try to pick a team to lead this that is heavily impacted by the work.

The disadvantage of this approach is that if the lead team doesn’t make a sincere and ongoing effort to keep the other teams involved as to the learnings and decisions, then when it comes time to spread out the work, these other teams may not understand or agree with the decisions, and that’s when the very real challenges to sense of autonomy will arise.

Transient Team Strategy:

In this approach, rather than identify one of the existing teams to serve as the lead team, we instead create a special, transient (for the life of this initiative) discovery team to do at least the discovery aspects of this work.  Normally this is a product manager, a senior UX designer, and at least one senior engineer.  Once this group has identified the necessary delivery work, and backlog items generated, the people on this transient team go back to their normal teams.

The benefit of this approach is that you have a strong team of people dedicated and able to focus on this work.  The disadvantage is that these people soon go back to their teams (which is good in that they carry with them what they learned) but bad in that the clear accountability and ownership leaves with them.  And this strategy has the same limitation of the risk of the other teams not understanding or agreeing with the learnings.  Another disadvantage is that borrowing people from their team works against the goal of team durability.

Combo Team Strategy:

The final approach to tackling these sorts of initiatives is something I don’t usually advocate, but I need to mention because it is sometimes used, and that’s where several teams (not necessarily all of them) combine forces to do the discovery work together.

The big benefit of this approach is the shared learning that results, which is definitely valuable.

The main disadvantage of this approach is that it usually suffers from design by committee.  Way too many cooks in the kitchen.

One way or another, you will need to discover the initiative solution, and then get that work delivered.  These are the three main ways I see teams tackle this.  It is hard to argue that any of these are really better in terms of autonomy than others, because the very nature of an initiative is about doing something good for the organization and not necessarily what any single team decides they want to do.  It’s probably more accurate to say that you can choose your approach to minimize the sense of loss of autonomy.

Just remember, these initiatives are often hugely valuable for our customers and our company, so if you execute well on the initiative there is a lot to feel good about.