How to Get Your Team Back on Track

Problem

Having to join a company where the team was not executing well and the releases were constantly slipping was a rough start. On top of that, there was a series of moving deadlines with frustrated customers. It was a great deal to me because I needed to build a level of trust and credibility; instead, I was firefighting. The team already had a leader who was not delivering per the expectations.

From the product side, they had varying priorities 一 so productivity was a concern. It prompted the release to have moving targets and confused the team. They were looking forward to bringing someone who would get the process back into the system, find out why the team's velocity was a huge variant, figure out the motivating factors of the group, and bring everything together.

Actions taken

I had no other choice but to jump into this from day 1. Since it was a startup, we had to make sure that our customers were satisfied with the services to keep the cash flow rolling. I did not have the 30-day, 60-day, 90-day plan; instead, it needed a lot of hard work and investment from my end 一 more than any other role would have demanded. To some extent, I chose to work longer hours.

I went through different levels of prioritization. First of all, I had to establish trust and credibility among the team members as well as our customers. I took a quick deep insight into the current challenges because without understanding the problem statement, there was no use in jumping to conclusions.

I had some solid 1:1s with all of the engineers, only to understand the main pain points. Instead of saying, "I was told this was the problem," I preferred to get the details out of the engineering team. Through the 1:1s came a lot of important information; I found some patterns emerge as to what the issues were.

After that, I started bucketing some of the challenges and working on them with the different stakeholders. For example, one of the main problems was a constant change of priorities or having stories come midway through the sprint without any requirements. They were not following the agile process very well; instead, they would pile things on top of the other. They were pretty much setting up the team for failure.

I did not back off from setting expectations for the product and let the engineers know that it is crucial to speak up when something doesn't feel right. While the product team would assume that everything was on point, when in reality, nothing was, it led me to further actions. I aligned the product and the engineering team to understand why the engineering team was not delivering on time with the constant change of priorities. Newer leaders in product organizations became my solid partners!

I also worked closely with the quality organization. Since the planning was so up and down, the quality team would not be involved as much. They would rather work on the backlog that was initially promised, and they would go off the sprint without closing the rest of the stories while the developers were forced to do so. This led to creating a lot of bugs and an endless cycle.

We went back to first principles and sound engineering practices. It alleviated some of the pressure that the engineering team already had, and then came the constant push back from the product management. Then came some heart-to-heart conversations between the teams and product owners.

My first 30 - 60 days pretty much went on like that, and I was finally able to earn the trust of my team. They were not as much under pressure as they used to be. They were able to understand that I was trying to help them and help them succeed in their roles. It created a lot of long-lasting relationships for me that I carry even today. Many are still in touch with me, and some of them even ask me for guidance to date!

Lessons learned

• Focus on people first. No matter what, Put your team and team members first, which teaches you incredible selflessness and leadership skills.
• Never be afraid to say or do the right thing.
• Always be open to different perspectives. Do not make up your mind without hearing the different outlook, understanding the problem statement only to begin working on the solution. Also, the trust needs to be there. You need to trust and believe that people are doing the right thing before data make you see otherwise.