Influencing Without Authority (Servant leadership)

Problem

In one of the organizations I worked in, I faced a unique challenge in the initial days of my joining. I was not only new to the company, but also to the regional culture, which is a polar opposite to the Bay Area, where I came from. It took a mindset shift: in the Bay Area, things have to be done lightspeed fast, while in the Midwest, things are done in a different way.

Upon joining the new company as a Senior engineering manager, I encountered a system architecture that rested on architectural decisions made three or four years before. These decisions were followed ever since without anyone challenging them, although they caused a number of issues. Much of the problem had to do with tech debt, which is not uncommon, but those issues significantly hindered the application performance. In a nutshell, we had serious problems with the application cache, which we tried to address by adding more instances.

Actions taken

I came in, challenging in good intentions, the status quo. When I asked the team why we were running into certain issues, an engineer explained that they started adding machines as and when the api calls increased. I knew this problem had to be addressed immediately.

I reached out to my manager, who was distantly aware of the problem but was excited to have me there to fix it. On the other hand, I had a team that was intimidated with me asking all those questions about past architectural decisions. Obviously, they perceived me as an outsider who had yet to build trust.

I was an enthusiastic manager, wanting to set everything straight. I was working as an IC before -- intermittently with being a manager over a number of years -- and had that instinctive drive to roll up my sleeves and correct mistakes I would see. I had to try really hard to abstain from rushing to fix things. Instead, I was just asking the questions, but it seemed that even asking the questions was making the team uncomfortable.

Now in hindsight, I could tell that I should have progressed just a little slower and work on establishing the trust first. When I talked to my mentors and my managers, they got the impression that I was overwhelmed and should have taken it more slowly. But the engineer in me was rushing to fix the problem. I was pushing my team to do something about it. Yet, for us to move forward, I had to take my manager’s hat off and show them that I was genuinely interested in helping them fix the problem.

Without my manager’s hat on, I could walk in as a peer. My natural curiosity helped a great deal. For e.g when I asked the team, “We have these static files which our product owners send once a month, and we are refreshing those every 24 hours. I just wanted to know what is the reasoning behind that?” I felt they appreciated my approach (bringing data and facts) and started to perceive me more as a peer. When I deep-dived into the architecture further, I found that there were only half a million key-value pairs. Yet, we had 18 machines for handling that data, which was clearly not required. After several probing questions and bringing data points into the discussion, the team started to realize the severity of the problem.

Instead of being directive, I asked them, “How do you want to go about it?” I also asked how I could help and offered to connect them with people who encountered a similar problem in the past. I wanted us to explore different solutions and discuss the pros and cons of each of them. Accordingly, someone took and discussed RocksDB as a potential solution, and another researched on Caffeine. I wanted to create an in-team repertoire of knowledge instead of imposing a solution. Most importantly, I wanted my team to be able to answer why a certain architectural decision was made. People were quite enthusiastic about this participative approach and willing to invest their time in learning new things.

Then I connected the team with another cross-functional team that used RocksDB. We discussed with their architect, a long-standing employee and expert in the domain, all possible scenarios. The discussion helped identify the bottleneck which was a “Go client”. After the analysis, we revamped the architecture and deployed the solution on a three-node Redis cluster which proved to be enough to handle all the data and requests. Finally, the performance test proved our decisions: Not only did we reduce the number of resources 18x times, but the app sustained 2x times more workload.

This didn’t come as a surprise. I was almost sure that we could handle this with fewer resources, but at that time, I was more concerned about establishing trust with the team. As a manager, I was there to ask questions and enable the team. I was not creating any artifacts. I encouraged a senior engineer who went ahead and created all the architecture. After we discussed three-node cluster architecture, they put all the artifacts. Their effort also resulted in them being promoted to a tech lead. What did come as a surprise was a message I got from the tech lead after I moved to another team, who expressed their gratitude for me challenging the status quo and bringing everyone together.

Lessons learned

• If a software engineer approaches another software engineer and asks why things are done a certain way, it will be a candid conversation between peers. But if a manager asks the same question, it will be perceived differently. This terrified me the most and impacted my decision to become an EM: I still want to utilize my technical skills whenever needed and enable the team. More importantly, maintain the delivery excellence and bring back the high-performing team that was derailing. As they say “Teams’ strengths and behavior norms can become their weaknesses”
• Understanding regional, company- and team-specific culture was crucial. Not only that the Midwest was different to anything I experienced before, but any team I worked with in the past was different. But, I walked in with a willingness to learn and be open to whatever a new environment would bring. Instead of being directive, I encouraged the team to think and come up with their solutions. I got to influence the team without having to exercise authority.