When Hype Doesn’t Deliver Value

Problem

When I was at Facebook, I worked on a couple of different infrastructure technologies. At that time, a significant investment was made in technology called reactivity that had some purported advantages over the older technology we had been using. Reactivity was expected to enable a number of real-time products that are interactive and would deliver a lot of customer value.

There was a massive hype around the idea and we were considered almost a celebrity developer group within the Facebook ecosystem. Everyone was excited about what we were doing and everyone was following our updates with the greatest interest.

I was tasked to manage the team and my goal was to release this technology that had been in development for a couple of years. After a short while, I realized that there was not much customer value associated with it.

Actions taken

First off, I tried to establish if there was value -- and to what extent -- around this technology. In the Facebook ecosystem, the infrastructure team offers software to product teams. To prove the value, an infrastructure team has to acquire internal stakeholder customers.

I talked to a number of customers trying to understand what and where the value was and I learned that the developer velocity and other things that this technology could offer was not interesting to them. Though we were removing some friction in the developer onboarding process that was minor in the grand scheme of things. Customers were more interested in reliability, clean abstractions, updating versions of the software and compatibility, etc. that were already present in the existing technology.

We realized that our technology would not be able to provide a lot of value. However, there were some parts of our solution that people quite liked. It was easier to reason about and it provided some nice developer abstractions that could reduce maintenance -- this was a nice incremental improvement to the previous solution.

Based on these findings I realized we would have to shut the team down. There were, however, a number of good things we learned that could be incorporated into other teams. Canceling your own team sounded daunting. Nevertheless, I endeavored to be selfless and think about what was best for the company. I discussed my plans within the core team and got them on board. Then I socialized the solution with the extended team. I also talked to my management, our peer teams, and many more to ensure understanding and support company-wide. We secured buy-in from all of our extended team and got our peer teams to buy-in to incorporating some of our technology. Thus, our learning could live on but within other teams.

Finally, we rolled out the public communication and did a number of interesting retrospectives that were shared across the entire company. We became a model for how to shut the project down. We also received great praise from our management team for how we were able to extract learnings from the project.

I helped many of the engineers on my team find new teams within Facebook. I made sure to help them understand that their careers are not at risk and provided them with a path forward.

Lessons learned

Lead with the problem, not the solution. The investment that the team had been pursuing was a technology investment, but we didn’t really understand what the customer problem was. We had a piece of shiny technology that we thought was a solution to the problem that we didn’t understand. If we understood the problem better, a meaningful solution would follow from there.