How I Increased My Team's Productivity By 40%
Tags: discuss, productivity, softwareengineering, management
Published: 2023-08-18 13:19:09

I've been focusing a lot on productivity and habit building for over a decade now. Throughout the years I've tried many different techniques and I've had a good amount of success increasing my personal productivity.

Last year a random thought crept up: 

>_As a software engineer, could I use the same techniques to increase the overall productivity of my team?_

## The Environment That I was In

![Group of friends playing beach volleyball](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/ocm03s4xzt79iosmabqv.jpg)

I've learned that the groundwork needed to inspire long-lasting change is deeply rooted in how a team interacts with each other. From my experience, there are no shortcuts here. 

Luckily, I was on a team that **already had a strong innovative culture**.

## What I Had Learned So Far

I've seen many initiatives started by tech/team leads slowly fade away after a few weeks. 

Or worse, the initiative keeps going despite its lack of effectiveness! 

Too often I've seen the weak results be blamed on the team's apparent lack of discipline or experience.

>A mentor once told me: _"OK ideas have to be nudged. GREAT ideas spread like wildfire."_

## What To Improve

![Runners on track field](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/u7k9h8vzd2n7zm8n2aey.jpg)

There were two areas I saw the team could improve on:
 
- **Speed**: Less time spent from when a work item/ticket was worked on to when the pull request was merged  

- **Focus**: More time spent on work that produced high value for the stakeholders

## The Plan

Another good lesson from that old mentor was that the most effective strategy for change is to **prove _before_ preaching**. 

So for the next month I tried various different techniques that I believed would yield an increase in speed and focus. 

Some didn't move the needle much, but some were a complete game changer. 

Here are a few techniques that proved to be the most effective:

### Strategy Documents

![Two people working on a document](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/e2hzsvhb9e7ajd5dlu3z.jpg)

For trickier issues, I would write a short plan of how I was going to solve a problem and why I had chosen that specific technique. 

I then shared it with the team to gather feedback and consensus around what was being built. This is what I came to call a strategy document.

This type of feedback is nothing new, but it's something that's normally left for the Pull Request stage or covered in a daily/meeting. 

My hypothesis was that by collaborating asynchronously and as early as possible it would **decrease the time spent on coding and PR reviewing**. 

A nice side hypothesis was that it could potentially welcome a more diverse set of stakeholders to give feedback (clients, product owner, managers, directors, etc.).

### Weekly Team Objectives

![A team of rowers](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/fn11yq9jd6wvrde6a6mt.jpg)

For our daily work, we tended to just pick work items we were interested in or followed what we had completed before. 

This created **mini-silos** were engineers would establish residency in certain parts of the codebase. 

With weekly team objectives, my hypothesis was that engineers would naturally **switch their focus to the objectives** meaning more **collaboration** and higher **impacting work**.

### Small Pull Requests

![Shipping containers on a boat](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/s79vdtsqm3ox1wmcd88p.jpg)

Everyone already knew that small PRs were the way to go on our team, but there seemed to be hesitation, maybe even a lack of belief that it was worth it. 

I had already seen this work very well in a previous team, so my hypothesis was that by showing the value of my super small PRs I would get more teammates on board.

## The Results

![A work team laughing together](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/b20miu5kpastjhf7llu1.jpg)

Once I started implementing these changes for my own work, my teammates, curious bunch that they are :grin:, started asking questions. 

> _Is it ok to merge changes that are not completely finished? What should be in a strategy document? Where are those team objectives you were talking about?_

That's when I knew these ideas had potential to make an impact.

In the next month, my teammates started trying these techniques and asking more questions about the process. 

By the end, we saw a **decrease of 40% in time spent** from implementing changes to merging pull requests for the entire team. 

Naturally our **deployment frequency went up** as well, and given we had achieved this through reviewing each other's solutions deeper, our **change failure rate also went down**.

But most importantly, our team _felt_ substantially more productive and dynamic. 

It's somewhat ironic that by slowing down to invest more time in collaboration before coding, we were able to achieve both a quicker output and a superior codebase compared to our previous approach.

### If you do the same, will you see the same results?


Maybe. I don't know.

It's not about the practices or tools you put into the place, it's about that word every engineer is sick of hearing, **culture**. 

The techniques were just an **accelerator** for what was already there. 

I mean, you might even see **negative** productivity if your team does not have enough trust or cohesiveness. Readers beware!

Sadly it's an area of tech that I feel not enough people are working on: how to build _real_ innovative culture. 

> _A few paid lunches and go-karting with the team each quarter isn't going to get us very far._

But that's for another post :smiley:

**_Have you initiated productivity changes in your team? What were the results? What did you learn from that experience?_**

_Photos by: 
<a href="https://unsplash.com/@jannesglas?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText">Jannes Glas</a> on <a href="https://unsplash.com/photos/0NaQQsLWLkA?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText">Unsplash</a>
<a href="https://unsplash.com/@slelham?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText">Steven Lelham</a> on <a href="https://unsplash.com/photos/atSaEOeE8Nk?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText">Unsplash</a>
<a href="https://unsplash.com/@homajob?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText">Scott Graham</a> on <a href="https://unsplash.com/photos/5fNmWej4tAA?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText">Unsplash</a>
<a href="https://unsplash.com/@mitchel3uo?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText">Mitchell Luo</a> on <a href="https://unsplash.com/photos/H3htK85wwnU?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText">Unsplash</a>
<a href="https://unsplash.com/@carrier_lost?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText">Ian Taylor</a> on <a href="https://unsplash.com/photos/HjBOmBPbi9k?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText">Unsplash</a>
<a href="https://unsplash.com/@priscilladupreez?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText">Priscilla Du Preez</a> on <a href="https://unsplash.com/photos/XkKCui44iM0?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText">Unsplash</a>
<a href="https://unsplash.com/@brookecagle?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText">Brooke Cagle</a> on <a href="https://unsplash.com/photos/g1Kr4Ozfoac?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText">Unsplash</a>_