Was it the right time to create a developer productivity team at Yelp?

I was recently asked by Abi about when Yelp first hired for our DevEx roles as part of a larger industry survey. As the first external hire for our initial DevEx team, I had a front-row seat to how this evolved over time, and I wanted to share some nuances specific to Yelp.

Setting the Stage

Initially, Yelp did not hire externally for this team. Wing (Head of Consumer) and Ken (Full Stack Engineer turned EM in the Consumer group) created the team with existing engineers from the Consumer Product group. I was the first intern/hire brought in externally in 2014.

Abi asked, “Was the team creation early, late, or at the right time?” This is a tricky question because opinions vary. I'll frame my answer based on whether, as an organization, this was the right time for investment. I'll look at two areas: getting buy-in for the investment, providing value for the engineering group, and any feelings of regret.

Organizational Context

Yelp has historically operated with a "don’t fix it until it’s broken" mindset. If something was broken, individuals took personal responsibility to fix. Ken pitched Wing on building out the team to solve long-term problems, which were hard to schedule on a product team. The first problem: shipping code as the organization scaled.

Was the Team Created Too Early?

Universally, the answer would be “no.” Yelp was a post-IPO company, had product-market fit, roughly 200-300 engineers, and shipping effectively was starting to become a problem. This is one of the benefits of the "don’t fix it until it’s broken" mindset—you work on the most impactful things.

Was This Just Right or Too Late?

You may get varying answers here, but I think the answer is “just right.” Here’s why:

1. Funding Dynamics: We likely wouldn’t have successfully gotten funding for a team any earlier.
2. Team Focus Shift: We were about to switch from a platform focus (Web, iOS, Android, Mobile Site) to a feature focus. This meant teams could now ship across all platforms for one feature in an isolated way. DevEx teams supported a persona—Webcore supported all Full-Stack developers at Yelp. This roughly fit into an “enabling team” construct shared by team topologies. (Note: This is in retrospect; team topologies weren’t a consideration when the team was formed.)
3. Dedicated Focus: We had a larger problem to solve that needed dedicated focus. I’m not convinced the team could have solved the monolith shipping problem with just 10% time dedicated by the feature team.

An additional note about the value of funding the team internally: Existing engineers felt the pain of the degrading developer experience and knew exactly what to work on without slowing down to onboard.?

Why Might We Say “It Was Too Late?”

1. Technical Debt: By the time we started solving the monolith problem, it was very hard. We had to tackle it in an incremental way over years of investment.
2. Scaling Limits: We were building our distributed system for running tests while pushing the scaling limits of our current system, resulting in burnout.
3. Monolith Legacy: Our monolith is still around today. Our organization made the deliberate decision to move out of the monolith incrementally based on need without a top-down mandate; we led with a carrot instead of a stick. Most of our development happens outside the monolith today, even though it still contains a large amount of code. We have largely removed our dependence on the monolith from our production flows.

If we had started moving out of the monolith earlier, the problem might have been easier to solve, but it’s unclear whether we would have made the right design choices given the changing nature of our company.

Final Thoughts

You’ll notice the article suggests that “it was just right” for Yelp, but I hope this additional context helps you understand that this answer is nuanced.