Three Levels of Developer Productivity

If you work on developer productivity, you sit in an unique spot. You are often given a broad mandate — “make the engineers more productive”—and typically little guidance on what the word ‘productive’ means. (Spoiler: There’s no one right answer here.)

To start to give some shape to the job, in my experience, there are two important categories of problems you are solving. There are other categories, of course, but these two feature prominently and will drive much of the work.

The first problem is one of engineering morale. The tools engineers use for their work factor greatly into the satisfaction they get from their jobs. If you place too high of a hurdle between an engineer making a change and them seeing the impact of that change, or if you make the risk of making those changes too great, you will sap people’s satisfaction. People do quit over slow build times and people do quit over dangerous deploys.

There’s also a breadth of research that show that teams that have fast feedback loops are higher performing. While this research may speak to many, what I’ve found to be universally resonant is the ethos of “don’t frustrate engineers with bad tools and processes.” Nearly everyone can get behind that.

The second problem, in coarse terms, is engineering return on investment. There is a good chance that one of your company’s biggest expenditures is engineering headcount. And every new feature shipped and every bug fixed is generally gated by an engineer doing something. Therefore, engineering cycles are one of the most debated, negotiated and protected resource in any tech company and the bulk of processes have their roots growing out from the perceived scarcity of those engineering cycles. There will always be a natural pressure, from all angles of the business, to get more from less, to speed engineering up, to help engineering do “more” and whether said directly or not, part of your job is to understand this and make improvements here.

If you’ve been around larger organizations, you’ll quickly see that some of these productivity problems can be solved with engineering elbow grease, but it’s not hard to see that engineering as a whole is often slowed down by the sheer coordination overhead that comes naturally to complex organizations running complex technical systems.

The challenge is that improving build times will make a small dent if any on coordination costs (unless you are starting on one extreme and moving it another extreme), leaving the “engineering is the bottleneck” problem largely unaddressed. But, when you start to focus on the second problem, the work isn’t as easily understandable to others.

To make the work more understandable, a framework I’ve had some success with is to explicitly put developer productivity efforts under 1 of 3 different banners: individual productivity, team productivity and team-of-teams productivity.

Individual productivity: In my experience, this category of work is what is typically seen as the core duty of developer productivity teams. This work includes efforts like speeding up build times, reducing test flakiness, increasing deploy cadence, making debugging easier and so on. The primary focus is on the individual developer and moving the code they author through the pipeline faster and more reliably.

There is tremendous value in this category. If you can take a routine process that every engineer is involved in multiple times per day and speed it up by 10%, that’s a huge number of valuable engineering cycles that are freed up, making a scarce resource that much less scarce, speeding up valuable feedback loops and making engineers enjoy their jobs a bit more.

And, at some point, some of these processes hit a phase change where because something has become so cheap to do, it encourages a whole lot more of that thing to happen. Think of the difference between a full build taking a day and that same build taking 10 minutes, or a weekly deploy becoming on-demand. The entire economics of your engineering processes change and it has knock-on impact across the business.

Team productivity: This category focuses on improving production by focusing on the flow of work between engineers, and usually engineers within the same team.

This is the realm of team processes: how does code get reviewed, how many projects can one team undertake, how does a backlog get managed and so on. This is where words like “agile” and “scrum” get mentioned.

In my experience, individual teams often have a lot of leeway in how they manage themselves. Where bad tales arise is often from a top-down mandate to “become agile.” There is also value here but it is riskier and efforts here will falter unless the most senior leadership is actively involved, you have a network of coaches throughout the org and you are willing to take a short term (eg, 3 to 6 months) dip in productivity while teams learn to operate differently and tweak their processes. Lining up and sustaining these preconditions is tough and there is no one weird trick to pursue here.

One approach to this level of productivity is to focus on the handful of teams that are recognized as a shared resource (eg, SRE, centralized tools teams, platform teams) and are on the critical path for some key projects and then help improve how they take in, prioritize and execute their work. You’ll likely get a large percentage of the value of “becoming agile” mandate while not actually having to spend the time and effort to make every team implement Scrum, as an example. Your org likely has a few critical teams that are the bottlenecks or dependencies on many efforts and there is high leverage in improving those specific teams’ processes.

Team-of-teams productivity: Problems here possess the delightfully confounding combination of being harder to see, requiring a delicate touch, are usually seen as “not your job” and are notoriously hard to measure. Yet, in my opinion and experience, making headway on these problems is where real leverage lies, not just for the engineers but for the whole business.

This level is the realm of quarterly/yearly planning processes, org design, platform migrations and other processes that are expensive, hard to change and slow. Simply because these things are expensive, hard to change and slow make any improvements in efficiency here incredibly valuable.

One example: Migrations are a fact of life of larger and older orgs. At any point, there are likely many migrations any individual team could be involved in, or that the organization would like to be doing. This presents a tradeoff: is it better to focus on one migration at a time, or to spread your efforts across many migrations? In general, migrations have little value mid-migration — you have the overhead of living in two worlds simultaneously plus the overhead of the migration itself. So reducing in-progress time should be a priority. This leads naturally to focusing teams on a single migration, which reduces overhead, reduces technical complexity, reduces status checks and reduces context switches, which are all good things.

So in that example, a team-of-teams productivity improvement would be to cap the number of in-flight migrations occurring at any one time.

The ways to make improvements at this level is by having relationships with pivotal engineers and managers, getting involved at the right time (eg, quarterly or yearly planning) and making a case for a productivity-improvement constraint when stakes are fairly high and involve influential people with differing goals and motivations. Nudges and tweaks to existing processes typically work much better than large campaigns.

When the “CI/CD person” shows up to suggest improvements to quarterly planning processes, using the framing of improving team-of-teams productivity, with a focus on overall program and organizational effectiveness to help the whole organization deliver more value sooner, helps explain the motivation behind the suggestions.

— — — —

Working on developer productivity can be hugely rewarding and there is a lot of value that comes from working on it at different levels, even outside the typical domains of automation and CI/CD.