From Developer to team leader

How I manage the hard transition from developer to team leader.

How did it happen

At the beginning there was one, then we were two. That was the size of the product development team. We were separated by 500km and united by our skills and willingness to achieve great results. The workload was shared naturally between us.

The product had potential but lacked some crucial features. The sales were growing at a good pace, so the company invested more and brought some young talented developers.

A little less than 2 years had passed since I started working for the company when the decision was made to create a new version of our now well-succeeded product, for the cloud. The creator of our product, our team leader, was assigned to be the architect and leader of this new product. So, here I was, the new team leader of a team of 5, distributed in two different cities.

I accepted the challenge and I was convinced that I had the necessary skills to do a good job.

I thought that my only goal would be to make sure the product continued to be reliable and innovative and I was (kind of) right; I just had no clue what it actually meant.

Context

The company, the product, and the team

The company was doing great. The product was a success. The team had skills and a little lack of experience which turns out to work on my benefit, as nobody knew exactly what to expect from a team leader. I was seen as the most experienced developer and acted as a mentor.

Me

I think I have some skills to fit as a team leader:

• I am a good communicator;
• I am honest about my work or the decisions I make;
• I create a positive and honest environment in a group;
• I am very self-critic and self-demanding;

The result

With the product having great success and the team being inexperient, I had less pressure either from our stakeholders as from the team to improve in my new role.

If I was to lead the team now with what I knew then, I wouldn’t last long.

First steps

I thought I could manage and develop

At that time, I thought I was best contributing to the team by having my own features delivered.

As the team was only beginning to implement Agile practices, I was avoiding some of the Scrum events. Daily meetings were skipped and I was having occasional screen sharing sessions with team members to check on progress and fix impediments.

I was trying to apply what worked for a team of 2 on a team of 5.

Small decisions were delayed making the team switch to new a task before finishing the current. Work was getting done, but the context switching was a performance breaker.

Recognize what’s wrong

Then came the first appraisal. I took the opportunity to discuss calmly with each team member (I was having one-on-one meetings before I knew what they were).

After the meetings, I had a pretty clear idea of what was good and bad.

Good

+ Development pace was good;

+ Work quality was good;

+ Team interactions were very positive;

+ Team was happy working on the project;

+ Team was focused on goals;

Not So Good

- Daily meetings should be mandatory;

- There was some confusion distributing tasks;

- Tasks were accumulating in code reviews

- I felt overwhelmed sometimes, doing a lot of overtime with the feeling of having nothing under control

The team was a rocket performing like a train, a high-speed train, but only a train.

My first intervention as a team leader

Having the outcome of the retrospective in mind, it was clear that we had to change some things.

Each task is assigned to a developer and follows a workflow. One of the mandatory steps is the new code from that task being reviewed before integration into the main code. The code review step was a bottleneck. We have a culture of high code quality. At that time, we always prefer to delay then take any shortcuts to cut quality (we are more mature now and take other approaches like scope refinement). The problem then was that everybody wanted to make sure we maintain high quality, but nobody was investing enough time on it. This was already an issue since the team had grown to more than 2.

We already had tried several things:

• dedicate the first hour of the day to code review;
• having code review meetings;
• the code reviews days;

These approaches were used simultaneously. Developers were occasionally skipping the first hour of the day to code review, so we needed the meetings and if those were still not enough, we’d stop everything and dedicated full days to code review. These actions lowered symptoms but didn’t fix the root cause.

The real issue was that the team members were feeling that the work was done once a task was in code review.

We decided that each person would be responsible for the assigned task until it got tested and approved, or at least until it was ready to be tested if no feedback on test results could be given soon. It seems so obvious now.

Takeaways

I thought managing was only a matter of exchanging some chat messages, making some calls and represent the team before stakeholders.

I was doing too many things and was mostly responding to events instead of driving the process.

I felt more secure having control over all tasks and the code produced. I was still not ready to give more autonomy to the team.

Getting feedback and critics from each individual combined with my retrospective made me aware of what I should improve.

Next

In the next post, I’ll write about how I’ve embraced my role acting as a real team leader. This allowed me to prepare for the inevitability of scaling the team, as well as make new mistakes along the way.