Team Objectives – Collaboration

Continuing with our series on Team Objectives, there are several forms of collaboration that are essential, yet often confusing to product organizations as they optimize for team autonomy and empowerment.

Shared Objectives

The first and most basic form of collaboration is the concept of a shared objective.  For an important objective, it is not at all unusual for multiple teams to have the same objective.

This is especially common in the case of large company initiatives (which are essentially problems large enough that they require help from many or sometimes even all product teams).

The most straightforward example of this is when both an experience product team and a platform team have the same objective, because the platform team is expected to need to provide one or more new services to enable the experience product team.

In this case, normally the teams will collaborate to establish a simple form of contract with each other in the form of an API, and then both proceed to figure out their sides, and then they will again collaborate on testing and delivery.

Another form of shared objective is when multiple teams temporarily combine their talents to solve a particularly hard problem.  Especially on problems that benefit from a range of different skills brought to bear, bringing the teams together can often provide the knowledge and synergy required to quickly come up with an effective solution.

In certain situations, the teams will co-locate for a few days or a week in what is sometimes called a “swarm,” which is an intense, highly collaborative technique to dive deep together on either or both of discovery or delivery work, for a particularly challenging problem.

Common Objectives

Another form of collaboration is when multiple teams are asked to pursue the same problem, but in different ways.

The reason for this is really risk management.  If the problem is difficult, we know that it’s very hard to know which approach, if any, will produce the necessary results.  So we may ask multiple teams to pursue, and hope that at least one of those teams will be able to generate the necessary impact.  It would be even better of course if all of them made a significant impact, but we know that’s unlikely.

A good example of this might be when one of the focus areas is subscriber churn, where too many of our customers are leaving the service.  There are of course many ways this problem can be addressed, and having multiple teams address this from multiple angles is often a good strategy.

In this case, the teams will need to communicate to ensure that there are no conflicts between the work, but normally each team is addressing based on the perspective and angle of their team, and what code and technology they own, so these approaches are usually largely independent and cumulative.

One of the questions that often comes up with common objectives is how to attribute progress to a specific team when multiple teams are making changes in parallel.  This is referred to as the product attribution problem, and the standard answer to that is the A/B test, which will isolate a specific team’s contribution (keep in mind that sometimes the work helps, sometimes it actually hurts, and sometimes it makes no impact).

The higher order point is that it is normal and often wise to have multiple teams pursuing the same objectives in one form or another.  

Companies that avoid shared or common objectives in the name of autonomy or communication, are often limiting their ability to solve the toughest and most important problems.