You Don't Need to Sacrifice Developer Experience for Productivity

I recently came across a story in the book Atomic Habits that got me thinking about how small changes end up making significant impacts. About 25 years ago, Dave Brailsford set out to revamp Great Britains cycling team which had been mediocre for a century. His strategy became known as the aggregation of marginal gains.

Brailsford explained it like this: "The whole principle came from the idea that if you broke down everything you could think of that goes into riding a bike, and then improved it by 1%, you will get a significant increase when you put them all together."

This approach proved tremendously successful. At the 2004 Olympics, Team GB won two gold medals. In 2008 and then again in 2012, they won eight.

The strategy of the aggregation of marginal gains applies to software engineering too. Rarely is a developers workflow suboptimal because of just one or two big factors. Rather, theres a lot of little things that in aggregate result in a bad developer experience.

What better way to create high-performing, highly-engaged engineering teams than to help your engineers optimize their workflows and improve developer experience?

Focusing on Velocity Is an Anti-Pattern

Being an engineering lead means you're under constant pressure to ship more features. But you face the constant constraint of too few resources. Thats why pretty much everyone is trying to hire more developers, but it can take a long time to find the right people.

So how do you ship more features without expanding the team?

The obvious solution seems like it would be to boost velocity. This is the approach many leaders want to take when they first become a team lead. As our COO Dan explained in a previous post, thankfully, an experienced dev on the team warned him that this was a bad idea.

Find out why agile velocity is the most dangerous metric for software developers. Look at 12 alternative metrics instead.

Perhaps the easiest way to boost your development velocity is to ask your team to do more. This can work, for a while. But eventually your team is going to get burnt out. Some may even take a job at another company. Ultimately, your velocity is going to drop and you may be left in an even worse position than you started in.

This was exactly what happened to Ben Matthews, Director of Engineering at Stack Overflow. At a previous company, he focused too narrowly on increasing developer velocity. He told the cautionary tale at Interact, our annual conference for engineering leaders:

Boost Productivity By Improving Developer Experience

If you cant expand the team (at least not immediately) and you cant increase your team members WIP, what are you supposed to do?

The answer lies in recognizing that increasing the number of features your team ships and developer well-being are not mutually exclusive. Quite the opposite, in fact! By improving developer experience in the right ways, you can boost your teams productivity.

If we hire engineers to write code, and they want to write code, then why do they constantly struggle to carve out time to do it?

There are 3 kinds of issues that eat up a developers time and prevent them from focusing on building new features.

1. Time Spent Not Coding

Outside of coding, developers spend most of their time in meetings (although there are certainly plenty of developers who spend more time in meetings than coding!)

One of the worst kinds of meetings is when each person simply updates everyone else on the status of their work. Daily scrums can easily devolve into this. In turn, either your daily scrums have to run longer or members of the development team have to make do with less time to surface their blockers and get help from their teammates.

Weve tried to do away with a lot of status update meetings and check-ins. If you want to know, Who is working on project XYZ? or Where is my team spending their time?, you dont need to ask your team members. This only takes up their time and interrupts their focus. Instead, you can just check in LinearBs Pulse view.

Check out this awesome dashboard we use for our standup. It identifies who's blocked, who has too much WIP, and if our work is aligned with the business priorities. Learn more about Pulse!

Developers are also forced to spend a lot of time managing the metadata around the code they write in project management tools like Jira. We studied over 1,000 dev teams and found that on 71% of teams, over 30% of all WIP branches were unlinked to an issue in Jira.

Shadow work like this means that you can analyze project status and team performance all day, but because the underlying data isnt accurate, your insights cant be trusted.

With our WorkerB bot, your devs dont need to go into Jira to create a ticket for shadow work. WorkerB will alert them if they have an unlinked branch and then allow them to create a ticket, in just one click, from right within Slack. Teams who have started using the One Click Ticket feature have seen a 67% drop in unlinked branches.

Switching between tools also prevents developers from focusing, an issue well look at next.

2. Context Switching

Flow state has become a big buzzword lately - and with good reason. When youre in flow, youre doing your best work and youre having the best time. Studies show an extremely strong correlation between time spent in flow and overall happiness.

Unfortunately, its becoming increasingly difficult for engineers to access a flow state. When theyre not jumping in and out of meetings, theyre jumping from their IDE to Slack to Jira to Gmail.

We built our WorkerB automation bot to solve this problem. From right within Slack you can:

• See the estimated review time of PRs
• Review and approve small PRs (less than 5 lines of code or diffs)
• Check on the status of your PRs and the PRs assigned to you to review

When developers know in advance how long a review will take, they can slot them into those moments where there are natural context switches, like between meetings or when transitioning from one larger task to another. Or they can estimate how much time they need to block off in order to work through a backlog of reviews all at once.

By enabling developers to stay informed about PRs and to review small ones from within Slack, WorkerB is saving them a bunch of context switches into GitHub or Gitlab.

3. Idle Time

At Interact, Luca Rossi, founder of Refactoring.club, spoke about the importance of reducing pull request pickup time.

He said, We spend incredible effort to, for example, shave 10 minutes off our CI/CD pipeline and then we have code sitting with nothing to do for 20 hours and later on someone says, Im waiting for someone to read it.

Luca had a lot of great thoughts about code reviews, which you can listen to below:

At LinearB, we discovered that the biggest wait time in development cycles is at the code review stage. Luca gave the example of 20 hours, but the reality is even worse. Based on our analysis of over 733,000 branches from almost 2,000 engineering teams, we found that on average, PR reviews take over 4 days!

A main reason that reviews take so long is that PRs spend a lot of time simply waiting to be reviewed. Our analysis found that:

• 50% of pull requests were idle for 50.4% of their lifespan
• 33% were idle for 77.8% of their lifespan

Reducing PR pickup time is an easy yet extremely effective way to increase the efficiency of your team. It doesnt get higher leverage than this!

The single best way to reduce PR pickup time is to reduce PR size. Large PRs take a long time to review. And because they take a long time to review, developers have to wait to review them until they have a big block of time (which is hard to come by for the reasons we looked at above).

Our analysis shows short PRs (<220 lines of code) can be reviewed more quickly. A lot more quicklyIm talking 10x more quickly!

Our Team Goals helps you establish and then track your progress against goals like reducing PR size or keeping the PR lifecycle under 4 days (ideally under one day based on our Engineering Metrics Benchmarks study.)

WorkerB is integrated with Team Goals so that it can inform team members when, say, theyve created a PR that exceeds the goal set by the team. With WorkerB, you can even approve PRs shorter than 5 lines right from Slack.

WorkerB combined with Team Goals creates an engine for sustained improvement on dev teams.

Parting Words

Just as Dave Brailsford relied upon the aggregation of marginal gains strategy to turn Team GB into an elite cycling team, you can use it to boost your teams performance.

By leveraging LinearBs WorkerB bot, you make slight reductions in time not spent coding, time wasted by context switching, and idle time. The combined effect of these reductions will improve your developers happiness and make your team more productive. Everyone wins: you, the developers, users, and the company as a whole.

This is why one of LinearBs core principles is to optimize developer workflow. Our WorkerB bot helps automates the annoying, tedious parts of the job and enables developers to stay in flow, doing what they do best: solving problems and building features.

To learn about all the ways LinearB empowers you to build high-performing engineering teams, get in touch to set up a demo.

Want to improve your engineering processes at every level? Get started with a LinearB free-forever account today!