Building an Effective Team

Problem

While working in my previous company, I was tasked to manage a new team. The team consisted of a mix of acquired folks and long-standing employees. The company was trying to pivot to a new industry and thus acquired an ambitious startup that already set its foot in the industry. As I walked into the team, I could tell I was walking into total chaos.

The lack of trust was staggering. People were so distrustful toward each other that I could tell that the rift between acquired and long-standing people was threatening. The lack of trust caused complete disarray -- the team missed multiple deadlines, reviews were poor, and milestones kept changing. To make matters worse, their manager quitted in the midst of the important project.

At that time, I was looking for a challenge, and knowing the director well, I asked if I could help. I realized that the leadership was exacerbating the situation by coming up with new proposals, changing requirements on the fly, and throwing the new dates around, hoping that someone will rise to the challenge.

Actions taken

First and foremost, I initiated a series of conversations with all team members. I wanted to understand what troubled them and how we could bridge that communication gap. We hired smart people who wanted to do well, yet they could not come out from their entrenched positions. I would have to sit them in one room and facilitate communication between the polarized team.

Distrust within the team was largely a consequence of the difference in processes between the acquired startup and the main company. They had complementary expertise that, when paired up together, could bring incredible results. But they were siloed and with a lot of tribal knowledge that sat with the long-standing employees. So I had to mix them up and restructure the existing team. My efforts to blend them together were met with resistance because they required both to step outside of their comfort zone. They had their ideas with whom they wanted to work with, and I made them a bit uncomfortable, which was a game-changer.

Then I sat down separately with engineers to learn what made us fail. As it turned out, we were building a rather complex product, and management kept adding new requirements. That made engineers change the design on the spot, which created a lot of thrash.

I knew I had to talk to management and set up the expectations straight. “You give me an MVP; I will give you a date,” was my line of defense. Then I would talk to the team and be able to assess if that would be feasible. But until then, I would ask management to stay away. That was not easy because as a new manager, I also had to earn my trust with management. To convince them, I presented them with several alternatives, including adding more resources, which was out of the question.

Next, I took a careful look at the roadmap. The problem was that this was the second attempt to launch this type of product, and we wanted it compatible with what existed in the market from the get-go. Therefore, the roadmap was full of must-fix things and features of questionable relevance. It had it all, and it would commit us to do it in one go. To move forward and deliver something tangible, I had to trim down the roadmap and come up with a more realistic plan. I made management come with up to five things and be precise what were must-haves and nice-to-haves.

Over time, I managed to build trust with the team, management, and within the team. We launched a product in nine months, which was the fastest launch time for a product of that scale. The team also made quite a reputation. I considered them one of my dream teams where everyone -- with the proper support -- can rise to the challenge.

Lessons learned

• The first thing is always to listen and build trust. Without a rapport, no team can be effective. It’s hard to make engineers do something they don’t want to do. This is especially true for new managers who want to develop trust by coddling engineers. Be careful with that because that kind of approach can backfire easily.
• Don’t be afraid to say no and push back. Be prepared to question the existing roadmap. Don’t take it for granted; instead, investigate to see if you can deliver or not. If that means pushing back to senior leadership, be it. The project I was given was a high-pressure one, with the CEO personally inquiring about the progress. That can cause deference and reluctance to question their decisions. As a manager, you should be responsible for delivering what is deliverable. -Question their perspective, come armed with data and tell them what could be realistically done. Sometimes this becomes an “either-or” conversation -- we can deliver only this one piece or nothing at all -- but don’t shy away from saying no.
• For a team to be effective in the long run, its members need to grow. Upscaling people works like a chain -- you upscale one person who upscales the other, and the whole team will continue to grow through a domino effect.