Refactoring

Share this post
How to Improve Engineering Productivity πŸƒβ€β™‚οΈ
refactoring.fm

How to Improve Engineering Productivity πŸƒβ€β™‚οΈ

What makes engineers perform at the top of their game?

Luca Rossi
Jun 2
12
Share this post
How to Improve Engineering Productivity πŸƒβ€β™‚οΈ
refactoring.fm

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:

  • How to Spend Your First 90 Days

  • Creating a Good Hiring Process (Part 1)

  • Creating a Good Hiring Process (Part 2)


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!

Refactoring is a reader-supported publication. To receive new posts and support my work, consider becoming a free or paid subscriber.

πŸƒβ€β™‚οΈ 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.

Learn more about BestPracticer

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:

Refactoring
Code Reviews πŸ”
Shipping fast and often is the #1 element shared by top performing engineering teams. Elite teams release multiple times a day, and it takes less than one hour to go from code committed to code successfully running in production. This idea was made popular in 2018 by the…
Read more
6 months ago Β· 21 likes Β· 2 comments Β· Luca Rossi

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 πŸ‘‡

Refactoring
When Should You Have a Meeting? πŸ”‹
A couple of weeks ago we discussed how communication should be designed inside our team. This is of course a very broad topic, and I started from a specific angle that is about responsibilities. I also wrote briefly about the "Async vs Sync" feud. A few people reached out for advice and in the last few days I had some great conversations about meetings, …
Read more
a year ago Β· 14 likes Β· 4 comments Β· Luca Rossi

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 πŸ‘‡

Refactoring
Do you really need a Staging environment? 🚒
Most companies I know use staging or pre-production environments to test recent changes before they are released to real users. This lets them discover more bugs, but it also increases the cost and complexity of their delivery process. In recent years, anything that delays or makes the release slower, like testing environments and complex branching struct…
Read more
22 days ago Β· 17 likes Β· 4 comments Β· Luca Rossi

❀️ 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 πŸ‘‡

Twitter avatar for @mar15saMarissa Goldberg @mar15sa
Working in the office is like using a coloring book and drawing in the lines. All the rules are defined for you (9-5 Mon-Fri, location, etc). Remote work is like drawing from a blank paper. You define your own rules. One is easier. One has far more potential.

May 24th 2022

8 Retweets52 Likes

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 πŸ‘‡

Refactoring
Building Relationships in a Remote Team πŸ€—
When I talk with people about the switch to remote, the #1 drawback they mention is the lack of human connection with co-workers. Creating meaningful relationships at work is important. Relationships make us happier, create a sense of belonging, and, ultimately, make us more productive too…
Read more
4 months ago Β· 15 likes Β· 2 comments Β· Luca Rossi

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!

Share

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 πŸ‘‡

Check out Refactoring Jobs πŸ’Ό

Share this post
How to Improve Engineering Productivity πŸƒβ€β™‚οΈ
refactoring.fm
Comments

Create your profile

0 subscriptions will be displayed on your profile (edit)

Skip for now

Only paid subscribers can comment on this post

Already a paid subscriber? Sign in

Check your email

For your security, we need to re-authenticate you.

Click the link we sent to , or click here to sign in.

TopNewCommunity

No posts

Ready for more?

Β© 2022 Luca Rossi
Privacy βˆ™ Terms βˆ™ Collection notice
Publish on Substack Get the app
SubstackΒ is the home for great writing