How to Improve Developer Productivity – Guide for Tech Leaders

Rebecca Murphey, the Field CTO at Swarm, delved into improving developer productivity in a recent CTO Shadowing session we hosted.

However, she did not focus on zooming in on individual developers even though there’s talk on LinkedIn about how some 10% of them aren’t doing any work. Instead, Rebecca dealt with teams working together to ship value to customers and, more importantly, how to further improve that process.

Because, at some point, you stop valuing people’s contributions in terms of time, and start valuing their contributions in terms of life goals. In other words, you start valuing the outcomes they produce that may expand beyond actual coding or otherwise expected output. 

Additionally, Rebecca looked into the overall developer experience (not to be mistaken for ping-pong tables and kegs) and the concept of business outcomes in terms of its correlation to developer productivity. 

Table of Contents

• The Guiding Principle for Improved Developer Productivity
• Where Leaders Often Go Wrong and Damage Productivity
  • Habits and Tendencies of Engineers – US vs. Outside the US
• Preventing Common Failure Modes
• Flow Efficiency
• How to Define Capacity
• The “Brains Methodology” Framework
  • How to Subtly Introduce Brains Methodology?

The Guiding Principle for Improved Developer Productivity

The guiding principle is simple:

We want our developers to work efficiently on the right things. 

For that to happen, all three concepts: productivity, experience and outcomes, must come together to lead to a successful engineering organisation. And it all depends on tech leaders and their ability to set the environment and processes right. 

So for a starter, ensure that your team isn’t working on twenty things at once. 

Second, if they are drowning in interruptions, they must have the capacity to reduce them. 

If interruptions occur regularly, ask yourself the following questions:

• Did the organisation set clear and reasonably consistent priorities? 
• Are the teams empowered to follow those priorities and seek the outcomes the business wants?
• Are teams allowed to say no?

Where Leaders Often Go Wrong and Damage Productivity

1. Teams are forced to work on too many things at once
2. Missing automation processes

RULE OF THUMB: A team of four people should work on one story before moving to another instead of having each member work on a separate story. 

Habits and Tendencies of Engineers – US vs. Outside the US

Cultural differences are profound when it comes to productivity. In the US, for instance, people tend to work more independently; i.e., less collaboratively. They want to own a project so that they can brag about it at their performance review in the hope of getting a bonus. 

Outside of the US, on the other hand — and this is a vast generalisation –, there is a lot more collaboration. In other words, people tend to work together on something as a team.

The same goes for monetary incentives: they are more appreciated in the US than outside the US.  

Preventing Common Failure Modes

As a leader, there’s a lot that you can do to intervene in some of the most common failure modes:

• Prevent working on too many things. 
• Defend against interruptions. 
• Reduce “waste work” (the result of the constant switching or wasting time on deprecated projects). 

Fail to address these issues and the outcomes are: 

1. Less predictable delivery
2. Higher error rates
3. More wasted work 

Flow Efficiency

Flow efficiency measures the proportion of active time spent on a task compared to the total time it takes to complete the task, from initiation to production.

Ideally, you want to see around 80% active and 20% idle time. 

If, on the other hand, you get 30% active time and 70% idle time, either you are utilising about 30% of the capacity or you’re trying to do too many things. Also, the team might be too small to handle so many pull requests in such a complex system. Or, you have an optimal-size team, but there are too many external processes they have to go through (eg, security or API reviews, manual QA process…). 

How to Define Capacity

Here, we are talking about predictability rather than productivity. It is a more suitable term because to determine the capacity, you must know the likelihood of having something finished in X days. 

By default, this assessment is based on historical performance. For example, you know that your team can deliver five small stories a week. Hence, the predictability gives you their capacity. 

TIP: Use Gen AI to build the model. Include variables such as flow efficiency, delivery and lead time and failure rate.

The other thing that helps with capacity planning is to ensure you’re never doing anything big. That, of course, doesn’t mean that you never accomplish anything big. Instead, you work on small things that lead to big things. Here’s an example: 

You can ship one ticket at a time, but the feature may take 20 tickets before it’s done. Now, this number might seem insignificant; however, don’t forget that you’re a) constantly putting that code in production, and b) making sure that the right people can see the current state of it even though your customers perhaps can’t. When you can redo this process, it is called reduced batch size. 

When you can reduce the batch size and get each of your units of work down to about the same size, your predictability goes up and your capacity becomes more predictable. 

Let’s go even deeper now: 

We know that we can get five stories done every week. Here’s the key: Every story should be 1 to 2 points, not 8 or 13. As soon as you start talking about eight and thirteen points, you have walked away from predictability. In other words, larger stories have a greater likelihood of being carried over to the next sprint.

Speaking of sprints…

Sprints are great training wheels, but once you get basic alignment and prioritisation in place, Kanban can be a lot more effective because it reduces the ceremonies and focuses the team on a specific goal. However, bear in mind that Kanban might be more suitable for mature teams because it focuses on predictability. 

TIP: If you’re using Jira, you can make the column red when you have too many things in progress and/or review. 

Now we are getting to the part where you acquire the relevant data. 

The “Brains Methodology” Framework

The principle of the Brains Methodology is to get a baseline using DORA metrics for different teams (the four metrics that look at the tension between delivery velocity and delivery quality) and then assess the current state. 

Now, arguably the best approach here is to just sit and watch your team(s) working; especially if you have a situation where your lead time is one hour or something like that, but every deployment is broken. You want to understand why it is happening. 

You’d be surprised how much you learn about your teams and processes if you just sit and watch. 

Now, here’s the thing. You want to speak to each member besides doing surveys because you want to understand individual pain points and get their opinions on improvements. For example, you want to know what frustrates each of them daily while they work on projects and/or systems. 

Once you have the answers, use them to implement changes and show the team that their feedback leads to concrete actions.

For example, you might want to increase productivity by 20%. One way to achieve that is to actively protect 40% of their time by acting as a shield against, say, product or sales teams that are trying to infringe on that time. This shielding helps them with problem-solving because they know that they can put their brains together without being interrupted. 

On the technical side of things, you could implement a CI/CD process, get automated tests up and running and place alerts in your production. 

However, the most positive changes come from cultural shifts. 

Take Stripe for an example. The company invested in developer productivity early on thanks to one engineer who realised that he could be more productive working on the builds than on the features using those builds. That gave birth to the platform and had an enormous impact on how work gets done at Stripe even today. The moral of the story is to let them choose their battles from time to time. 

Remember, it’s better to focus on outcomes than on outputs; for example, an effective delivery that lifted net retention by 3% or reduced the cost of customer acquisition by 1%. 

How to Subtly Introduce Brains Methodology?

(Without making everyone feel watched and having their every commit scrutinised.)

Start by explaining that this is about transparency and not things being put under the microscope. And that transparency will eventually provide evidence for their claims.

For example, an engineer might be frustrated with constantly working on keeping the lights on (KTLO). This type of work often limits opportunities to take on projects that would lead to a good performance rating. The team might also be concerned about their career prospects if they spend up to 80% of their time KTLO-ing. The Brains Methodology can help alleviate these concerns by providing clear evidence of how their time is actually being spent. This data can then be used to justify requests for additional resources or to support arguments for shifting priorities towards more innovative projects.

Of course, every now and then, you have to remind them that we live and operate in capitalism and that they are paid for the value they bring to the organisation. But when it gets hard for them, they must feel free to inform you about their predicaments because you’d want to know about it so that you could figure out what needs to change. 

Now, as you can imagine, this transparency will shine a light on the imposed processes more than it will on teams. And that’s a good thing because more often than not, it’s the process that impedes the progress. Brains Methodology gives you a developer productivity tool to not only see inside a single process but also to get an overview of the intricate correlations and dependencies between multiple processes at once. 

That’s why we are looking into team performance rather than individual. And that’s why we should be more interested in outcomes than outputs. Something to contemplate, isn’t it?