When to form a Developer Productivity team
Deciding when to establish a dedicated Developer Productivity team can be tricky. Too early, and you risk diverting resources from critical areas. Too late, and you’ll be stuck with inefficiencies that drag down your developers. So, when is the right time?
This is a common question we hear, so we interviewed 20 companies to understand when they established their DevProd teams. We share what we found in our new report, and also cover what influenced their timing and whether it was the right time or too late.
Download the full report here. Or, keep reading for a summary.
We found that companies varied widely in when they started their DevProd teams—some kicked off before hitting 100 engineers while others waited until they had thousands. We dug in to learn whether some of these leaders felt their timing was ‘late’ versus being on time, and had assumed that companies that waited longer would feel their timing was late. Surprisingly, that wasn’t the case: there was no clear link between how large the organization was when it hired DevProd and whether they felt their timing was on time.
Instead, we saw that companies like Lattice and Cash App, which established DevProd at around 100 engineers, felt their timing was late. Meanwhile, giants like Thomson Reuters and Disney, who waited much longer, felt on time. Curious, we dug deeper: how could both be true?
We discovered that a key difference was whether the company had made investments in developer productivity work at the individual team levels prior to forming the dedicated team. Disney and Thomson Reuters had been working on this long before forming dedicated teams. In contrast, Lattice and Cash App only began these efforts when their teams were established. This shows that timing isn’t just about company size—it’s about how developer productivity is managed internally.
Getting your timing right
Two-thirds of the companies that contributed felt their timing was optimal, while the rest thought they were too late. Notably, no one thought they were too early. Here are some insights:
- Major technology transitions are a good time to hire DevProd. For instance, Stem brought in their first DevProd member when shifting from monolithic architecture to microservices. Similarly, Thomson Reuters began platform engineering when they transitioned to the public cloud.
- DevProd teams are brought in when there’s a clear need for standardization or improved cost efficiency. It’s difficult to standardize infrastructure or establish golden paths without a centralized function that’s responsible for these initiatives. Tapad (part of Experian) set up their team to reduce tool redundancies and mature their development practices. Thoughtspot’s DevEx team managed to drive more cost-effective operations, helping them grow their customer base without increasing expenses.
- If infrastructure is not keeping pace with business growth, you may be overdue for forming a DevProd team. Several of the organizations we studied faced challenges as their infrastructure struggled to support the company’s scale. Mercury relied on volunteer efforts for infrastructure maintenance until they hit 50 engineers, at which point a dedicated team became necessary.
Invest in developer experience before there’s a dedicated team
At many of the organizations we studied, developer experience investments began before a dedicated team was established. At DX, we’ve seen many organizations successfully tackle developer productivity with local efforts before establishing a centralized function. Even once a centralized function is established, local efforts are critical.
Here are some strategies we’ve seen work:
- Dedicate a percentage of engineering time to developer productivity. Set aside a fixed percentage of your engineering investment specifically for developer productivity improvements. This top-down alignment ensures DevProd efforts don’t get overshadowed by feature work. Atlassian’s approach is a great example—they mandated that developers spend 10% of their time fixing things that 'make their day job suck.’
- Equip teams with developer experience data. Provide teams with data on their developer experience. This is crucial for Platform teams that can’t dictate team priorities. Sharing insights, like pain points or deployment frequency metrics, motivates teams to tackle these issues organically. Team-level data can also advocate for DevEx investments, demonstrating the impact and business opportunities of resolving these problems.
- Appoint dedicated internal champions for DevEx. Assign dedicated internal champions for specific developer experience areas. These champions curate insights and best practices, offering visibility to leaders and support to teams facing common challenges. This focused attention helps drive meaningful improvements across the organization.
Conclusion
Deciding when to set up a Developer Productivity team isn’t a one-size-fits-all. It depends on several factors unique to your organization. Looking at how other companies have navigated this can provide valuable benchmarks and strategies. Stay tuned for our next article, where we’ll explore the initial focus areas for new DevProd teams.