Without a Solid Team You Can’t Build a Good Product

Problem

I recently joined a team of six other developers who were reluctant to dedicate themselves to the company goals. They had poor knowledge of the breadth of technology, and no appreciation of what both the business and product were capable of doing. I could attribute this to them being inexperienced but they were also lacking a work-ethos that could propel the technology forward. I was brought in as a senior developer because the leadership didn’t want to upset other developers by abruptly imposing a lead role on them. I identified two groups of problems: team and their processes. I decided to first focus on dealing with team-related problems since without buy-in from the team it would be challenging to optimize the team’s process let alone work towards building a good product.

Actions taken

First off, I had to understand what was happening in the team and do a knowledge download from them. After I did that I could think about revamping the team so that we could perform better and get the expected results. During my first week I had one-on-ones with everybody on the team as I was trying to get to know them better - to understand their problems, motivation, values, sense of ownership of the product - but also, to learn about roles and responsibilities across the team.

I used the one-on-ones to also communicate my values and my motivation and prepare them for inevitable changes. I would explicitly state what is expected from my teams and let them make their own conclusions about what changes on their part that would imply.

For example, our build times were upto 20 minutes and it seemed the team didn’t care about this inefficiency and that alone spoke volumes about the team itself. I would state that these kinds of inefficiencies were unacceptable and that we were going to take drastic steps to address this.

I experienced a lot of antagonism and pushbacks from other senior developers. They were initially reluctant to even answer my questions and were - as often is the case in stagnating teams - quick to blame the leadership. Their blaming of the leadership meant that their ownership of the product was rather low as they kept on dwelling on frustrations.

While my initial talks announced the future changes, I knew that nothing would speak louder than action so I rolled my sleeves up and did some hard work. I identified the highest value item in terms of speed and efficiency and worked for a week to upgrade it to the latest version of Webpack. The problem was that in 2019 we were using the long-outdated version 1 of Webpack, a common build-tool in front-end technology, that was wasting our time on every build. After the upgrade, we witnessed a huge increase in speed and productivity. This was a simple entry-point that had a great impact. By doing the upgrade myself I wanted to lead by example and do something that is challenging. I moved from the phase this is what we are going to do to a phase this is what we are doing right now that was really about reclaiming the ownership and demonstrating my values. Also, I was able to demonstrate how solving small problems could have a lasting and profound impact on our work.

Lessons learned

• I worked for some time in the startup world where people are eager to learn and change, therefore I underestimated how firmly people can resist change and how stagnant they could be and have since learned to be most cognizant of how human-nature plays in the team.

• I also had to manage the expectations of my leadership and to explain the proposed changes and their business value to my direct boss and project managers. It was demanding to do leadership both ways in my team so I had to learn to manage my leadership capital.