Eric Farkas

Information asymmetry is a feature, not a bug, of management. You are in meetings with leaders from different teams and departments. In these meetings you learn things. Not only that, as a good manager you seek out information. What are other departments working on? What features are we missing that cause us to lose potential customers?

As a manager, how should you decide which information to pass along to your team?

Your bias should be to “share by default”.

Take a step back. Start from a place of “trust by default”. Every person on your team is a diligent professional, doing the best they can with the information they have. Each teammate brings their unique personal and professional experiences to bear on their work.

You put in the work to get to know each teammate. You have facilitated the establishment of common practices within the team. Despite this, you cannot know, much less predict, the effect that a piece of information will have upon a person’s work. Yes, you have context your team doesn’t have, but they also have context you don’t have.

“Share by default” is empathetic. It communicates that you don’t know everything. It demonstrates that you trust your teammates to make good decisions. You believe that the more informed they are, the better decisions they will make.

What shouldn’t you share by default?

• Individual matters, shared in private. This includes things shared with you by someone, or shared with you about someone.

• Assume anything shared in a 1:1 is “share with permission”. If you learn something in a 1:1 that you think another person should hear, always ask “Do you mind if I share that?” In my experience, most of the time the answer is yes, but never assume.

A bias for “share by default” doesn’t mean you will wind up sharing everything in public. It only means that you’re looking for reasons to not share information. This is as opposed to looking for explicit reasons to share information. Just because you, in your limited wisdom, can’t come up with a reason to share information, doesn’t mean a good reason does not exist.

In the absence of a compelling reason to keep information to yourself, you should share it, even if you’re not sure other people need to know it.

Lightbulb Moment

I learned this lesson some time ago when I was in a meeting with leaders from other departments. An executive spoke about how we’d market the feature my team was working on with features two other teams built, as a package aimed at a segment of target customers. I gathered that many in the room had known about this marketing effort for weeks, but it was the first time I had heard of it. I realized that if I didn’t have this context, my team didn’t either.

At our next standup I said something like, “I was in a meeting yesterday where I heard the feature we’re working on will be marketed together with these other features. Here’s how the rest of the company is viewing our work. Thought you’d all like to know.”

Having that knowledge didn’t help anyone write better code. But it did renew the team’s sense of purpose in their work. We saw our effort in the larger context of the company’s goals. We realized other teams were depending on our work in a way that we hadn’t before.

Since that meeting, as a manager I have become more aggressive in seeking out information and context. The goal is to then share it with my team. For example, when in discussions with a PM about a feature, I will often say, “There should be nothing you know about this feature, that we don’t. Give us everything.”

Far from overloading your team with information, you will communicate that you trust them to synthesize new information, and make good decisions with it.

You are also exemplifying the traits they will need when they are technical leaders.