Building Highly Efficient Teams : Part - 2

Read (if you haven’t read it yet) : Building Highly Efficient Teams : Part - 1

Over the past 20 years in the technology industry, I have been involved in various teams, managed large groups, and even built teams from the ground up. It's often said that "an expert is someone who has made all possible mistakes in a very narrow field." Indeed, I have witnessed and made numerous mistakes. However, these experiences have been invaluable in teaching me critical lessons and enabling me to build exceptionally productive teams characterized by high accountability and commitment.

I would like to share some insights and experiments from my journey. Perhaps these reflections might inspire positive changes in your own teams.

Solve the problem first

A large and complex tech system is akin to a moving truck with 10,000 moving parts. It’s inevitable that occasionally something will break, slow down, or malfunction. Especially in a live production environment, when something goes wrong, it often feels like the fire alarm is blaring. Frequently, in these situations, the immediate reaction is to figure out who is responsible for the problem or who is to blame. Even while addressing the issue, energy is often wasted on finding the culprit. While understanding who made the mistake, what caused it, and what we can learn from it is important, the priority should always be to resolve the issue first, regardless of these factors.

To address this, I’ve established a simple rule: whenever such a situation arises, we don’t discuss who is at fault until the issue is resolved. It is the tech leader’s responsibility to ensure that the team stays focused on fixing the problem rather than assigning blame. This approach yields multiple benefits. Problems get resolved more quickly, and once the issue is fixed, the team is less likely to engage in finger-pointing. Instead, they tend to discuss what they can learn from the incident. The person initially responsible for the issue isn’t put on the defensive and can contribute fully to resolving the problem. Most importantly, this approach instills confidence in the team, signaling that making mistakes is acceptable as long as they are careful and have the right intentions. Otherwise, fear of punishment can stifle decision-making and initiative, leading people to stick to the status quo rather than innovate.

In essence, a tech leader must assure the team that it’s okay to make mistakes. Mistakes are a natural part of doing work. It’s easy to stay spotless when you do nothing. A tech leader must give the team the confidence to take initiatives and assume accountability without fear of being wrong.

One solution at least

“We have a problem.” Almost every leader hears these words daily from their team. It’s often assumed that the leader’s role is to listen to all problems and provide solutions. However, there are times when it feels like the team should have come up with the solution you’re suggesting.

When I was just out of college and new to the job, my team leader was not only supportive but also a good friend. I’d approach him with every issue I faced. Eventually, it became a habit to consult him for even the smallest problems. One day, when I brought another problem to him, he told me directly, “Rahul, next time you come to me with a problem, make sure you’ve tried everything you can and come up with at least one possible solution. I don’t care how flawed that solution is, but having one is non-negotiable.” Initially, I felt bad, but soon I began solving many problems on my own. For the ones I couldn’t solve, I spent more time explaining my proposed solutions than just describing the problems. That team lead remains a close friend and mentor to this day.

Since then, I’ve realized that identifying problems is easy, and it’s even easier to ask someone else to solve them for you. But this approach stifles your problem-solving skills, turning you into a mere resource for the company rather than an asset. I’ve implemented a simple rule within my teams (inspired by my past experience): Whenever a team member comes to me with a problem, they must also present a possible solution. I’m open to considering any suggestion, no matter how impractical it might seem. For example, if the search function isn’t working and someone suggests buying Google company as a solution, I’m willing to explore that idea. This approach encourages the team to shift from complaining to actively finding solutions. We then work together to refine and implement the proposed solutions. Often, I bring up problems I’ve identified and discuss my solutions with the team, knowing that our collective intelligence is greater than my own. Together, we refine the solution until it’s finalized.

I believe life is about solving problems. The more problems you solve, the happier you become.

I plan to write and publish a few articles on this topic every week over the coming weeks. Feel free to connect with me on LinkedIn or email me at rahul.iitdelhi@gmail.com .