How to Improve Engineering Productivity 🏃♂️
What makes engineers perform at the top of their game?
Hey 👋 this is Luca! Welcome to the ✨ monthly free edition ✨ of Refactoring. Every week I write advice on how to build great engineering teams, backed by research, case studies, and my own experience.
If you’re not a subscriber, here’s what you missed this month:
A few weeks ago I joined a panel on engineering productivity with two exceptional guests:
Kathryn Koehler – Director of Productivity Engineering at Netflix
Truong-An Thai – VP of Engineering at FloSports
You can find the full conversation below 👇
That chat — and preparing for it — gave me the chance to reflect and research on engineering productivity.
What makes engineers perform at the top of their game?
It’s a complex question that touches on basically every aspect of our work. This article tries to break down the main elements that contribute to productivity, covering:
🏃♂️ What is productivity
🎽 What is good management for productivity
🔨 What is good tooling for productivity
❤️ Well being and remote work for productivity
To write this article, I embedded the best ideas that came out of the panel, and did a ton of additional research surveying some of the best engineering teams that I know.
Let’s dive in!
🏃♂️ What is productivity
What does it even mean to be productive? In my experience there is a short-term and a long-term angle.
The short-term angle is about output — you ship features fast, fix bugs relentlessly, etc.
The long-term one is about well-being — your personal needs are met; you don’t burn out, you grow and stay several years at the company.
In other words, you need to optimize both for output, and for being able to sustain such output for a long time.
There are two elements that enable this for engineers:
🎽 Good management — processes to allow people to do their best work.
🔨 Good tooling — automate boring work and make things fast.
Let’s see them both.
Before we dive in, I am happy to spend a few words to promote a product I am very fond of: BestPracticer.
Ever wish you had an experienced coach in your corner to help you lead your engineering team? BestPracticer has engineering leadership coaches who have been in your shoes, and a curated curriculum on essential engineering leadership topics you can learn from.
I have done professional coaching myself on the platform for several months, and the experience has been awesome. Whether you are interested in coaching, or being coached, you may want to check this out.
Now, back to the article 👇
🎽 Good management for productivity
You know the saying that goes: hire smart people and get out of the way.
This is easier said than done. Especially the “get out of the way” part is confusing to many. To make it easier, let’s try to reframe it as: “get obstacles out of the way”
But what are such obstacles?
In 2017, Pluralsight surveyed 1,000 engineers about productivity. Among other things, people were asked to rate the things that drain the most productivity from their days.
As it turns out, the biggest offenders are… other people! Either in the form of meetings, or waiting for them to do stuff, or more.
As a manager, how can you help? We could entire write books on this, but here are the three tactics that in my experience bring the most benefits while being the easiest to implement:
1) Reduce concurrent work
The more things people have to juggle with, the more they lose effectiveness. Your whole team just gets worse:
More meetings — with more projects, it gets harder to keep everyone on the same page. So you need more meetings, which further reduces the bandwidth for dev work.
More rework — when people are spread too thin, they get things wrong more easily, which leads to rework and frustration.
Context switch — the cost of switching from one task to another is real. With highly technical tasks, you need to load a giant context in your head before you are able to make any progress. This cost is pure overhead and you want to pay it as seldom as possible.
The nasty effects of concurrent work have been well understood since forever. Kanban, that got popular as early as in the 80s, explicitly tracks work in progress (WIP) as a KPI, and recommends setting hard limits for it. Low WIP positively correlates with lead time and little rework.
2) Optimize the code review process
Code reviews are often the biggest bottleneck in your release process.
I have seen teams working super hard to shave 10 mins off their release pipeline, while being ok with code sitting idle for 15 hours straight, waiting for review.
In many cases, code waits for review for longer than it took to write it.
A few months ago I wrote a full article on how to make the review process better, and it became one of the most popular Refactoring pieces ever. It includes ideas on keeping PRs short, trunk-based development, pair programming, and more.
You can check it out below:
3) Optimize meetings
Meetings are the most powerful tool you have to get anything done. They are synchronous, video + audio, uninterrupted time with multiple participants.
This also makes them extremely expensive, so you should use them sparingly.
How sparingly? I have my own set of rules for when it makes sense to have a meeting and when not. I wrote them here 👇
Here is also other advice that was extremely useful to me:
Optimize for focus time — I always try to schedule meetings in times where they do not interrupt a long streak of maker work. I may put them towards the end of the day, right before lunch, but never—e.g.—mid afternoon at 15:30. You can do this manually, but you can also use a tool like Clockwise that tries to optimize it for your whole team.
No agenda, no attenda — stole this great line from Kathryn. Enforcing agendas is a great way to 1) make meetings shorter and more productive, and 2) actually make less of them! Sometimes, people schedule meetings because they are too lazy to write things down. The need for agendas counters this, so you will find people will write more docs instead of organizing calls.
🔨 Good tooling for productivity
These days I am working on a survey to better understand how developers think about their career (spoiler!), and what elements they consider when they decide to join a company. I am having many 1:1s, and one of the points that comes up the most is the developer experience.
Engineers really leave and join companies because of good or bad DX. This shouldn’t be surprising to devs reading this — but I suspect it is for many managers.
For those who do not understand, bad tooling for an engineer is death by a thousand cuts. In isolation it’s all small things, but in aggregate, they make people flip the table.
Conversely, good tooling does wonders:
You ship faster — with efficient CI/CD pipelines, preview links, and automated testing.
You automate repetitive stuff — with scripts, internal tools and frameworks.
You encourage / enforce the right behavior — with linting, engineering analytics, notifications for PRs, and more.
Good tooling also gives you the confidence to do ambitious work. By instrumenting your systems and making them observable, you can better test your changes in production and reduce your mean time to restore. That includes investing in logs, metrics, distributed tracing, and more.
Two weeks ago I wrote more on tooling and development environments 👇
❤️ Well-being and remote work
Other than being productive, it is important that you are able to stay productive over time. We all know work is a marathon rather than a sprint, but sometimes we still fail to take enough care of ourselves.
Paradoxically, while remote made work conditions better for many, it also made it harder to draw the line between what it’s healthy and what not.
That’s because remote is a blank paper 👇
Defining our own rules is hard.
I have been working remotely for more than two years now and I still feel like I am figuring out the basics. This is a shared responsibility we have for ourselves and, as managers, for our reports.
As an individual — you need to understand what works best for you.
As a manager — you need to work on it with your reports and set them up to do their best work, sustainably.
So, what have I learned so far?
As a manager, if I had to tell you just one thing, that would be to work on fostering good relationships between people.
A big chunk of our well-being, as humans, comes from this, and this is also what remote makes uniquely harder.
Really — chances are most of the other stuff will be ok, but improving human connection needs some hard, intentional work.
I wrote more about how we can do it in this past edition 👇
And that’s it for this week! If you liked the article, please do any of these:
1) ❤️ Share it — Refactoring lives thanks to word of mouth. Share the article with your team or with someone to whom it might be useful!
2) ✉️ Subscribe to the newsletter — if you aren’t already, consider becoming a paid subscriber.
p.s. 30-days money-back guarantee with no questions asked!
📚 Resources
Here are a couple of resources to learn more.
📺 Improving Engineering Productivity with Culture and Metrics — in this panel, Kathryn from Netflix, Truong-An from FloSports, and myself, discuss challenges and tips to help engineers perform at their best.
📑 2017 Software Developer Productivity Survey — interesting survey by Pluralsight about productivity, the relationship with managers, and more!
⭐ Job of the Week
Senior Backend Node.js @ Mutuiamo (Remote EU / Italy)
My good friends at Mutuiamo are looking for an experienced Node.js engineer to join their team, either remotely or in their office in Rome.
Mutuiamo is disrupting the Italian mortgage industry and has already helped 100K people overcome one of life's greatest challenges: buying a home.
Check out all the other jobs on the board or add your own here 👇
Create your profile
Only paid subscribers can comment on this post
Check your email
For your security, we need to re-authenticate you.
Click the link we sent to , or click here to sign in.