Elevate Spring Summit has been announced (Thu, Mar 11th)

🔥


Don't have an account? 

When Transparency Means Exercising More Influence

Cross-functional collaboration
Managing Up
Managing Expectations
Collaboration

29 November, 2020

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.

Related stories

Creating a Culture of Quality
20 January

Guru Kini, Co-Founder and CTO at Fincity, explains how to build a culture that champions the quality of the product.

Managing Expectations
Product
Company Culture
Guru Kini

Guru Kini

Co-Founder & CTO at Fincity

Introducing Design in the Roadmap Creation Process
5 January

Dmitry Nekrasovski, Senior Manager of Product Design at HashiCorp, recalls the recent efforts to for the first time introduce Design — on par with Engineering and Product — in the roadmap creation process.

Cross-functional collaboration
Roadmap
Dmitry Nekrasovski

Dmitry Nekrasovski

Senior Manager, Product Design at HashiCorp

Accepting Tough Decisions
30 December

Wadah Sayyed, Director of Engineering at HPE, shares how he had to accept some tough decisions when pursuing his plan, though rightful, became disruptive to the team.

Managing Expectations
Convincing
Roadmap
Wadah Sayyed

Wadah Sayyed

Director of engineering at HPE

Overcoming the Multi-Person Identity Challenge
20 January

Aram Grigoryan, Product Manager at Qualtrics, dissects the ongoing dilemma of multi-person identity and explains how to benefit from shared identities.

Managing Expectations
Product
Users Feedback
Company Culture
Impact
Aram Grigoryan

Aram Grigoryan

Product Manager at Facebook

Why a Risk-Driven Product Roadmap
20 January

Aram Grigoryan, Product Manager at Qualtrics, explains how a risk-driven product roadmap can help with building a product that bridges the gap between the digital and physical world.

Product
Collaboration
Roadmap
Aram Grigoryan

Aram Grigoryan

Product Manager at Facebook

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.