Engineering

Transparency 201: Know your audience

Transparency is a key part of many strong engineering cultures. Every great leader I know uses it often in keeping their teams engaged. However, transparency can be costly. Sharing information with your team can cause distraction, confusion, and unnecessary stress.

I’d like to consider a real-world situation about shifting company priorities. By reusing the same situation, we can consider the decisions you make every time you share information with your team: Audience, Timing, and Clarity.

This post is about Audience: who you share information with and how.

The Setup

Here’s the situation.

You get an email from the CEO. They want to maybe change your team’s mission. Meanwhile, you’re trying to lead the team through the launch of a new feature. A lot of uncertainty has just been introduced! What do you do?

There are three other engineers on the team:

  • Jordan, a fairly senior engineer who loves staying up-to-date with modern web frameworks. They are a strong contributor, and want to grow into more technical leadership.
  • Riley joined your team right of out of college and has been working for a couple of years. They have good technical chops, but need to get better at solving the spirit of the problem, instead of just doing exactly what the ticket says.
  • Avery, a former UI/UX designer. They graduated from a coding bootcamp a few months ago. They’ve already contributed a lot of the visual code.

You’re nearing a medium-sized launch of the v2 of your feature in about a month.

Meanwhile, the CEO is considering investing more heavily in your company’s API. They’ve asked you if your team would be interested in changing focus to work on the platform.

The decision is still pretty far out; there’s still a lot of planning and analysis to do before the company would officially decide to invest in the platform.

The API is currently in maintenance mode by a single engineer in their spare time. It’s not in great shape. It’s a legacy stack and a poorly-maintained codebase, which can be unpleasant to work on, but an ambitious refactoring might be on the table.

Taking on this work would be a big change for your team. You’d be working on a different technology stack and a different set of users. Perhaps this change could cause frustration and loss of morale. It might also be an exciting new opportunity for technical growth.

It’s not an easy decision to make.

Here’s your best guess on if the engineers on the team would want to do this:

  • For Jordan, it’s about 50/50. This could be a great leadership opportunity for them. But, it takes them away from web frameworks, which is the technical area they’re passionate about.
  • You’re confident that Riley would enjoy working on the platform. They enjoy API design and gravitate towards the application layer when building products.
  • Avery probably wouldn’t be excited, but will do whatever they’re asked to for now. While this would be outside of their comfort zone and a good chance to broaden their technical skills, you know their long-term goal is to be an expert in UI/UX engineering.

Share Carefully

Transparency is popular because of its many obvious benefits: better solutions, higher engagement, teaching opportunities. However, we should be realistic about the costs, especially in the context of decision-making.

Each person who finds out that a decision is being made increases the cost of the decision.

Once somebody finds out about an upcoming decision, they become invested in the decision. You’ve just added another stakeholder who will want to hear updates on how things are going and share input. This makes the decision-making harder (though potentially better).

And there’s also a passive cost. This decision creates uncertainty around future plans, and sharing it will distract people. If their input isn’t part of the decision, it can feel disempowering to know it’s happening and not be able to affect it.

Ultimately, you have two important decisions you need to make in order to share information:

Who–Do you share this with everybody on your team, or just some of the people?

How–Do you talk your team individually, or all together at once?

Key Contributors vs. Everybody

Jordan is growing into a leader, and keeping them motivated is a high priority for you. It seems pretty obvious that they should be looped into these goings-on; it gives them practice thinking about company-level priorities, and ensures that they know that their opinion is valued.

Riley and Avery are different. Realistically, they’d both go along with either world. You feel comfortable representing their perspective to your CEO. Excluding them from the conversation probably wouldn’t materially hurt them in any way, and could save everybody time and energy.

However, if they did find out about it from somebody who wasn’t you, that would damage trust. Further, sharing with them is an opportunity to teach them to zoom out and think about global prioritization.

Avery, in particular, might need some time to get used to the idea of not working on UI/UX. By including them in the process, you can help them get to a great mindset for working on the legacy API.

If you do share with Avery, then Riley is the only person left out. This creates greater risk that they’ll find out and feel excluded. So, if you talk about the plan with Avery, you should also talk about it with Riley.

But is it worth the cost in thrash and time?

Individual vs Group

Suppose you decide that you do want to share with every member of the team. Should you do it privately, or in public?

One-on-one conversations make people the most comfortable with sharing their thoughts and fears. It also lets you talk openly about how a change in project affects people’s careers.

However, no matter how much you prepare, individual conversations are each unique, and what each individual hears will vary. Your teammates will talk to each other, and the information mismatch can breed rumors and misinformation.

It also signals that this is “private information”, which means that later discussions and questions will also be 1:1, which is more costly than having them out in the open.

Speaking to the group all together is a lot scarier. It can have a chilling effect on people sharing authentically, especially for your teammates who are less confident. However, it demonstrates trust for the whole team, and shows that everybody’s feedback is valued. Further, it does a lot to prevent misinformation and gossip, since everybody will have heard the same information.

To deal with personal reactions, like “how does this affect my career”, you can follow-up the larger conversation with individual ones. Or, more radically, you can also have these conversations out in the open. If you have a culture of mutual success, you can create a team where everybody is supporting each others’ learning and growth.

Be Better at Transparency

There’s no simple heuristic to use for determining audience. Each situation is different, and depends on so many things. Personal dynamics, trust, career goals, timing, stress level, and history all play a part. But when you consider the full of the range of possibilities, you will find the right approach.

Be bold, try new things, and trust your team to give you honest feedback.


I’d love to continue the conversation on Twitter (@personamb) or in responses:

  • How have you handled a similar situation on your team?
  • How do you make sure the team’s input going to be valued and used appropriately?
  • What about sharing more broadly? What if the decision-making process was entirely transparent to the entire engineering org, or the entire company?

Finally, if you care about helping teams collaborate effectively, check out our many engineering job openings at Asana.

Would you recommend this article? Yes / No