Duplicative Work

One of the most stressful things, for teams in large companies, is finding out that another team is working on a similar product or similar problem that you are. 

It is understandable why teams feel uncomfortable. It is hard enough to build compelling products that compete in the market without having to also compete internally for resources and attention. Duplicative products set up an awkward dynamic that some people perceive as forced competition. The term "bake off" or “hunger games” are used by teams in this situation. If two teams are working on something similar, ultimately only one will survive. 

In bottom's up organization the chances of duplicative work are much more likely than top's down. A bottom's up culture has multiple benefits. Primarily, it allows teams the autonomy to pursue, what they believe, is the highest impact work. It is inevitable with the number of teams working on adjacent problem spaces some will decide to work on similar things.

From a leadership level, there is an incentive to allow duplicative work. Pursuing parallel paths increases the chances of finding product market fit by spreading the risk over a larger surface area. It does have hidden costs.

None of this removes the anxiety of finding out another team is working on a similar product.

Duplicative work isn't inherently bad. But there is good duplicative work and bad duplicative work. 

Good duplicative work is when the teams will learn something definitive with the success or failure of either effort. This means the work is distinctive enough that the learning is accretive to everything in the problem space. 

Good duplicative work allows teams to the freedom to pursue approaches without significant collisions in approach or audiences.

Bad duplicative work is work where the success or failure of the initiative will not help us achieve our collective goal. Bad duplicative work is where the solutions are experientially and technically undifferentiated. Bad duplicative work is where people and channel partners are unclear which product to use and how they differ.

If you find out a team is working on something you perceive to be duplicative, your first goal is to uncover if the duplicative work is good or bad. This means acknowledging if the work is not distinctive enough to warrant spending resources on.

It is really tough for teams to honestly evaluate the sameness or uniqueness of their approach. People get attached to their products and believe them to be distinct or special. A host of cognitive biases kick in here (sunk cost fallacy, Dunning-Kruger, loss aversion etc.) making it difficult to assess the situation objectively.

Teams, wedded to technical solutions, argue that their approach is novel because it uses one language or framework vs. another to maintain duplicative projects. This is not a good reason.

If you uncover duplicative work, be willing to let the other team do work for you. Instead of trying to own it all, try to agree on how your work can be mutually beneficial to each other. Be greedy in getting teams to do work for you vs. controlling all of it. 

If the work is distinct enough to warrant continuing, then agree on swim lanes and how you can learn from each other. Accept that one approach will be more successful and will most likely mean one team will ultimately working on something else over time. The goal here is to learn as quickly as possible.