Back to resources

When Transparency Means Exercising More Influence

Managing Up
Managing Expectations
Collaboration
Cross-Functional Collaboration

29 November, 2020

Sameer Kalburgi

Sameer Kalburgi

VP of Engineering at Fieldwire

Sameer Kalburgi, VP of Engineering at Fieldwire, debunks the hidden meaning behind the recurring requests for transparency and shares how he managed to enhance collaboration with other stakeholders by drawing his team’s boundaries clearly.

Problem

We were initially a small, five-person startup, with engineers only. As we grew, other departments, including Sales and Marketing, were added and we were all supposed to be working in tandem communicating effectively across the departments.

Our engineering team was very much system-focused and we tracked everything and anything. We felt that our work meets the transparency criteria of the highest standard. If someone wanted to see what we were working on, they could easily go into the tool we used and filter the data by any category they wanted. This is why it came as a surprise when I heard from multiple people that we were not transparent enough. However, it turned out it was not about transparency at all, but about exercising more influence on our team.

Actions taken

I talked to people who brought up those claims and tried to understand what exactly did they mean by “not transparent enough” and what were their expectations in terms of transparency. That included people from Sales and Marketing, along with some executives, who were the most vocal about it. The more I talked with them, the better I realized what they wanted -- a seat at the table. That didn’t imply that they wanted to call the shots, but they wanted to ensure that their opinion is heard and considered.

Transparency as a notion served their purpose well. It is such a convenient concept to build a consensus around and prevent objections and it is uncontested partially due to its vagueness and concrete denotation. Once I was able to decipher the genuine intent behind those calls for transparency, I was able to come up with a concrete proposal.

I tried to tackle the problem from both sides. From the side of Engineering, we tried to listen more to different stakeholders, facilitate and be open to their feedback. We understood that we could benefit greatly from their input; for example, Sales or Support would spend time on the frontlines conversing with customers and collecting ideas that could be critically important to our work. However, for us to move forward we had to say “no” more often than “yes”.

One of the questions we had was should we provide reasons for the things we couldn’t do. For example, should we explain, “this is a great proposal, but this is why it is not part of the product vision”, “this is not a priority now” or “though it is valuable the cost is too high”? Sometimes a small change would touch ten other things and would not be so small anymore.

From the other side, we tried to draw clear boundaries and push back on the other teams. We let other people know that they couldn’t just throw something over the wall and expect us to do it. We were clear that we were not a development shop for one particular customer, but we had to think more holistically and follow the product vision. We would have to frame things more broadly (what we would want to achieve, why something would be valuable to the company, etc) and move away from any emotional assessment (“I feel this is the right thing to do”). We explained to other stakeholders that as Engineering we couldn’t jump from anecdotes to implementation and we would have to do research and prep work prior to taking any actions. We also realized that if we would put the onus on the other teams it would filter what they would send over. We would evaluate things that would come from other teams but they would have to provide some level of credibility corroborated by research.

Lessons learned

  • Words matter. Having a shared language and agreeing upon interpretation is important to avoid misunderstandings and conflicts. In this particular case, much of the misunderstanding came from the ambiguity that is embedded in the notion of transparency.
  • It is equally important what you do and how you are communicating what you are doing. Providing an explanation can iron out much of the disagreement, for example, “we had a packed quarter and won’t be able to take on anything new, so please plan it for the next quarter.” Have clear expectations about the impact other teams can have on Engineering.

Discover Plato

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


Related stories

The Importance of Culture and Values When Building Teams

26 May

Elwin Lau, Director of Software at Jana, advocates the importance of maintaining culture within a company when scaling teams.

Mission / Vision / Charter
Scaling Team
Building A Team
Company Culture
Collaboration
Onboarding
Sharing The Vision
Elwin Lau

Elwin Lau

Director of Software at JANA Corporation

Hiring a Data Team With a Stubborn Manager

24 May

Liz Henderson, an Executive consultant at Capgemini, shares her experience hiring a data team with a manager who was difficult to work with.

Managing Up
Building A Team
Conflict Solving
Hiring
Data Team
Liz Henderson

Liz Henderson

Executive consultant at Capgemini

Managing Different Time Zones: Inclusive Collaboration Methods

19 May

Jonathan Belcher, Engineering Manager at Curative, shares an unknown side of synchronous communication tools and advises managers on how to handle a team that’s spread across the globe.

Remote
Internal Communication
Collaboration
Cross-Functional Collaboration
Jonathan Belcher

Jonathan Belcher

Engineering Manager - Patient Experience at Curative

Creating a Company Culture That Balances Helpfulness and Productivity

16 May

Alexis Philippe, Vice President, Product & Engineering at Amilla, describes his one simple rule for creating a culture of helpfulness that doesn't disrupt productivity.

Mission / Vision / Charter
Company Culture
Collaboration
Cross-Functional Collaboration
Alexis Philippe

Alexis Philippe

Vice President, Product & Engineering at Amilla

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.

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.