How transparent should you be as a leader?

Two things I’ve found helpful to consider when trying to decide what to share with my team – and what to keep to myself.


How transparent should you be as a leader?

This is a question many leaders struggle with — including myself. Do you share financials with the company? Or how about salary? How open should you be about why someone was fired?

From open-book management to making compensation public within the company, the concept of transparency in the workplace is more popular than ever.

Understandably (and rightfully) so. As a concept, transparency makes sense: If you want your team to behave the way that you would behave, they need access to the same information that you have. And, the more transparent you are, the more you’re likely to build trust within your team.

But what about the unintended consequences? Can transparency backfire? Do you inadvertently cause panic in a company when you reveal what the monthly burn rate is? Do you encourage resentment from more junior employees when you reveal how much senior employees in the company are making?

As a leader, how do you decide what to share with the rest of the team and what not to?

A few months ago, I spoke with the insightful Des Traynor, Co-founder of Intercom, on this topic. For Des, deciding how transparent he should be was one of the hardest lessons to learn as a leader. And as a CEO myself, I couldn’t agree more.

In our conversation, Des shared with me two things to consider when deciding how transparent you should be in your company:

Transparency requires context.

“The key thing people forget in transparency is it’s not about opening up the Google Drive and making sure that everyone can read everything,” says Des. “It’s about transparency of context as well.” Many of the CEOs who are a part of our leadership community in Know Your Team, The Watercooler, echo this sentiment as well. One CEO remarked how he had shared revenue numbers once, and “things had gone sideways with individuals who just don’t understand or appreciate all that goes into starting and operating a business.”

In other words, the negative reaction came from the lack of context about the revenue numbers. What that CEO wished he would’ve done was share more context. If you share revenue numbers without context of monthly spend, people start wondering, “Where’s all that money going?” So for example, at my company, we share revenue numbers, within the context of also our profit margin and expenses — so it’s understood how revenue supports our business as a whole, and not just “here’s the pile of money we’re making.”

Transparency is a spectrum.

Transparency isn’t all or nothing — things don’t have to be either completely open or completely a secret. Des emphasizes this, saying, “I think it’s worth having a critical threshold to decide what’s actually good for everyone to know, what’s not a secret but needs context, and what actually genuinely might be a secret because you don’t want everyone panicking about something.” Transparency is a spectrum, and if you indiscriminately just make everything 100 percent public, you could be wasting people’s time, confusing them, or causing them strife. Everyone has a capacity of information, and overloading folks with every detail of what’s happening in marketing, support, design, engineering — it can be too much. As a leader it’s important to ask yourself: In what cases is transparency appropriate and helpful, and in what other cases is it distracting or a burden? Are you being transparent, just for the sake of being transparent, or are you truly trying to help people make better decisions, and feel a greater sense of trust?

At the end of the day, transparency is truly a positive force. When it does backfire or causes fallout, it’s often because a leader hasn’t often taken the time to consider these two things: Transparency requires context, and transparency is a spectrum.

As you think through what you should be transparent about in your company, keep in mind these two things. Hopefully, they’re things you won’t have to learn the hard way.


https://upscri.be/ee998e/


P.S.: This was originally published on the Know Your Team Blog. If you enjoyed this piece, please feel free to share + give it 👏 so others can find it too. Thanks 😊(And you can always say hi at @clairejlew.)

This article was originally published for Inc.com.

Let’s drop the unrealistic expectation of total transparency in open source

Running a large, long-running open source project like Ruby on Rails is very rewarding but can also be exhausting. The glimmers of glamour usually only sparkle around release time, but the grunt of the grind is daily.

The grind is an endless stream of bug reports, requests, demands, questions, and occasional inquisitions. To avoid getting stuck in the mud, you need to travel as a team, not solo on a lonely road. Without the backing of stable, friendly faces, you simply aren’t likely to go the distance. It’ll be thanks for the fish and adios muchachos!

A big part of this feeling is that co-chairing a popular open source project means you’re always ON in the public space. Every reply to every ticket, every comment to every discussion is fair game for dissection, scrutiny, applause, or ridicule.

Doing the work of justifying choices, presenting arguments, and collaborating on code in public is great for transparency, but also at the heart of why the work is so draining. Everyone needs a place and a time to retreat. To step out of the spotlight and loosen the guard.

We’ve embraced that need on the Ruby on Rails team through a series of contracting circles of intimacy and privacy. There’s the community at large, where all the interactions happen in public on GitHub or the mailing lists or wherever. But then there’s also a Rails Community Basecamp, a Rails Contributors Basecamp, and finally a Rails Core Basecamp.

I appreciate that the standard response from the open source gospel is that this is somehow sacrilegious. That total and complete transparency into all matters of an open source project is more important than the mental well-being of its long-term, key contributors.

I’m sympathetic to that ideal. Surely Rails would be worse off if everything happened behind closed doors, the community at-large wasn’t involved in anything, and releases just dropped from the sky. But there’s a nuanced world of grey beyond those extremes where healthy, happy people live and work.

We’ve long since accepted how pivotal our individual idiosyncrasies are to the art of programming. That much of the work in programming tools and languages reside in tickling the interface between code and our all-too human emotions. It’s well past due that we recognize the same fallibilities are present at the group-level of development, and that we find ways of working to accommodate these.

I’ve worked on Ruby on Rails for more than thirteen years now. The only way that’s been sustainable and enjoyable has been to protect my sanity and motivation in dealing with the encouragement and discouragement, judgment and praise from thousands of strangers over the years.

Letting smaller groups do some of the work and shoulder some of the exhaustion in private has been a key strategy. It’s a small trade-off to complete transparency for the well-being of the most active participants. I’m not going to feel bad about that.


When we started the Ruby on Rails core group back in 2004, it was just a private IRC channel. We then leveled-up to Campfire in 2006. Most recently we’ve leveled-up again to a full-fledged Basecamp 3 account that doesn’t trap us in chat. It’s been liberating!