For the most part, engineering organizations know how to scale. They know how to scale software to handle more users, they know how to hire and organize teams to effectively work together. But what has been historically a blind spot for our industry — and that is now rapidly shifting into focus — is whether they know how to scale their tools and processes so developers can continue to deliver valuable software.

“As an industry, we are not very good about thinking about how to make engineers effective.” — Peter Seibel, 2015

When executives complain about their engineering organization’s pace, “why are we moving slowly?”, it often comes down to this: the daily work of developers is slowed by suboptimal tools and processes. Imagine this day in the life1: a developer starts their day with alerts that end up being false positives, they can’t find documentation they need to understand a problem they’re working on, their day is broken up with meetings, their tests are unreliable and their builds break. Multiply the daily issues experienced by developers across an organization and the answer to “why are we moving slowly” becomes clear. And as we know well, adding more engineers is not the most efficient path to producing more software. 

More organizations today know that removing friction from development teams is vital to their ability to continue moving fast as they grow. But just as they will look to correctly time their investments in scaling their team and product, they want to invest in their developer experience at the right time as well. 

As the goal of investing in developer experience improvements is to make developers more effective, early startups can focus on empowering developers to make incremental improvements to improve their daily lives. Tech debt, documentation, code review — these are all areas where developers should have the ability and time to maintain. 

“Platform work is also the most important retention tool for your engineers. Give them the tools and architecture to be productive. And if you don't, they will leave to a team that will,” — Jean-Michel Lemieux (former CTO at Shopify) on Platform Investments

When the company grows, it makes more sense to invest in a dedicated group. Here are two models to help think about how much to invest in a dedicated team: 

A rule-of-thumb: 50% of your engineering spend should be focused on platform work. “A way of visualizing your r&d investments is with 3 buckets. Having the right mix is critical. They work together. A healthy investment distribution is 50% platform, 40% features, and 10% experiments. You can skew for short periods, but over the long term its fatal… Platform work has an interesting attribute in that the side effects of low investment mean you'll get slower slowly. It doesn't happen over night.”

‍

‍

A calculation: We can also use the model created by Peter Seibel (tech lead for Twitter’s Engineering Effectiveness Group). Seibel describes the following model:

‍

‍

Where E is the total effectiveness, ee is the total number of developer experience engineers, b is the effectiveness boost for the first DevEx member and s is the scaling of the boost. The units for effectiveness are full time engineers (FTEs). 

In your organization, the number of engineers is given. The interesting parameters to this model are the scaling factor, s, and the boost, b. For his model, Seibel uses 0.7 for s and 2% per FTE for b.

‍

‍

If these parameters are right, for a thousand person engineering org we should devote over a quarter of our engineers—255—to engineering effectiveness, yielding a total effectiveness equivalent to 1,465 engineers for the price of 1,000.

Seibel notes that these big investments pay off when the developer experience group focuses on problems for the wider organization, not for individual teams. A counterpoint to consider, however, is to take into account different personas when making prioritization decisions — sometimes there are specific groups that are focused on mission-critical work, and improving their effectiveness may be the right decision for the business. (More on making prioritization decisions in Chapter 4.)

Another calculation to consider using is the estimated time/cost savings of solving specific problems. Estimate the time suck from one instance of experiencing a problem (time wasted or waiting, time to complete a task, etc), then multiply that by the estimated number of times a developer experiences that problem in a given time period, and again by the number of developers that experience that problem. Consider that number over a period of time compared to the headcount investment. 

Now, all of these calculations miss an important point: that there’s a psychological aspect to providing a good developer experience. Seibel, again, explains it well: “On one hand, good tools are just a pleasure to work with. On that basis alone, we should provide good tools for the same reason so many companies provide awesome food to their employees: it just makes coming to work every day that much more of a pleasure. But good tools play another important role: because the tools we use are themselves software, and we all spend all day writing software, having to do so with bad tools has this corrosive psychological effect of suggesting that maybe we don’t actually know how to write good software.” Some executives will “get it”, some won’t. The calculations and rule-of-thumb shared above will help support an argument for making an investment in a dedicated developer experience team.

“Being productive motivates developers. Without the friction, they have time to think creatively and apply themselves.” — Tim Cochran, 2021

‍A recommendation: if you’re looking to form a dedicated group, make a copy of this template and modify it to fit your situation to advocate for budget.