When Transparency Means Exercising More Influence

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.