Back to resources

Influencing Without Authority (Servant leadership)

Leadership
Convincing
Coaching / Training / Mentorship
Prioritization
New Manager

2 September, 2021

Pratibha Shambhangoudar
Pratibha Shambhangoudar

Engineering Lead at Target

Pratibha Shambhangoudar, Senior software engineering manager (emip) at Target, shares how to influence without authority, demonstrating how to use your technical expertise to enable the team.

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.

Discover Plato

Scale your coaching effort for your engineering and product teams
Develop yourself to become a stronger engineering / product leader


Related stories

The Art of Asking Why: Narrowing the Gap Between Customers and Users

24 May

Jord Sips, Senior Product Manager at Mews, shares his expertise on a common challenge for product managers – finding root causes and solutions.

Customers
Innovation / Experiment
Product
Personal Growth
Leadership
Stakeholders
Users
Jord Sips

Jord Sips

Senior Product Manager at Mews

Streamlining Product Processes After a Reorganization

16 May

Snehal Shaha, Lead Technical Program Manager at Momentive (fka SurveyMonkey), details her short-term technical strategy to unify processes among teams following an acquisition.

Acquisition / Integration
Product Team
Product
Building A Team
Leadership
Internal Communication
Collaboration
Reorganization
Strategy
Team Processes
Cross-Functional Collaboration
Snehal Shaha

Snehal Shaha

Senior EPM/TPM at Apple Inc.

Navigating Disagreements When It Comes to Priorities

9 May

Pavel Safarik, Head of Product at ROI Hunter, shares his insights on how to deal with disagreements about prioritization when building a product.

Innovation / Experiment
Product Team
Product
Dev Processes
Conflict Solving
Internal Communication
Collaboration
Convincing
Strategy
Prioritization
Pavel Safarik

Pavel Safarik

Head of Product at ROI Hunter

Growing Through Different Engineering Lead Roles

8 May

Weiyuan Liu describes his experience moving up from an individual contributor, tech lead, and engineering manager.

Leadership
Coaching / Training / Mentorship
Career Path
Weiyuan Liu

Weiyuan Liu

Director of Engineering at Zillearn

Preparing For Your First Presentation: The Art of Public Speaking

8 May

Weiyuan Liu shares his insights on public speaking, such as how to prepare for your first presentation.

Different Skillsets
Coaching / Training / Mentorship
Weiyuan Liu

Weiyuan Liu

Director of Engineering at Zillearn

You're a great engineer.
Become a great engineering leader.

Plato (platohq.com) is the world's biggest mentorship platform for engineering managers & product managers. We've curated a community of mentors who are the tech industry's best engineering & product leaders from companies like Facebook, Lyft, Slack, Airbnb, Gusto, and more.