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
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
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
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
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
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
Once I started implementing these changes for my own work, my teammates, curious bunch that they are 😁, 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 😃
Have you initiated productivity changes in your team? What were the results? What did you learn from that experience?
Photos by:
Jannes Glas on Unsplash
Steven Lelham on Unsplash
Scott Graham on Unsplash
Mitchell Luo on Unsplash
Ian Taylor on Unsplash
Priscilla Du Preez on Unsplash
Brooke Cagle on Unsplash
Top comments (0)