Blog Culture GitLab & Buffer CEOs talk transparency at scale
Published on: March 14, 2017
7 min read

GitLab & Buffer CEOs talk transparency at scale

The two transparency advocates recently met to talk about openness in business, what they keep confidential, and some things they've learned as their companies grow.

ee-products-hero-image.jpg

Joel Gascoigne, CEO of Buffer, a social media management tool, recently met GitLab CEO Sytse (Sid) Sijbrandij on a call to chat about one of their favorite topics: transparency in their respective companies.

“I feel like I know you already,” seemed like a sentiment shared by both men, since each has a vast public footprint online. This isn’t an accident, but a result of their shared philosophy that the traditional business’ tendency towards secrecy is not only unnecessary, but at times wrongheaded and even harmful.

Being open by default has led to unconventional choices. Both companies are remote only, making the impulse to document everything a necessary one for organizational knowledge. After all that effort, it’s a short jump to hit ‘publish,' and teams in both companies have developed a habit of doing so. Buffer has made their financial model predicting the company’s health available to all employees. Their transparency dashboard also includes details on equity breakdown by individual, demographics of applicants and employees, pricing, fundraising, and every email sent by teammates.

GitLab recently rolled out a salary calculator on our jobs page, and our company handbook is entirely public, including details on the hiring process and how we should respond in the event of a crisis. We recently live-streamed the recovery of deleted production data. Finally, Sid’s monthly email to our board is also sent to all team members, including all the good and the bad from the previous 30 days.

Here are some highlights from their conversation, which, naturally, they wanted to share.

How do you share salary and career progression info?

Sid: We’re early to the salary calculator; we created bands so that engineers can make progress while not becoming a manager. GitLab does not make actual salaries public because raises are based on performance, which is one of the rare things that we tightly guard. This is becoming a challenge because there seems to be uneven progression available on the business and engineering sides; we’re still working on how to create a clear growth path on the business side.

Joel: We use a salary formula to calculate each team member's salary. Within the formula we have four levels: Entry Level, Intermediate, Advanced, and Master. In practice, we realized that these various levels left room for bias, and it wasn’t clear how one person might go from “Intermediate” to “Advanced,” for example, so we started thinking about putting together a clear career progression framework throughout Buffer. We're including more explicit definitions and suggesting timeframes to move from one level to another. Our goal is to apply this framework across all teams at Buffer. We have evolved the framework to include levels on the engineering side by designating people as “engineer one, two, three,” etc., and we’re also aiming to provide the same clarity amongst other teams. Our happiness (customer support) and marketing teams are currently working on their career paths as well.

Which things do you keep categorically confidential?

Sid: We never talk about conditions under which people leave the company, and performance feedback is never public. We’re worried about information being damaging to the person when they apply for new jobs and give reference calls. We think it’s unfair because the person cannot share their perspective. It’s hard when a colleague leaves the company and the team is accustomed to total openness, but we think that this is a case where transparency could harm the person who left. They shouldn’t be punished in seeking new opportunities simply because we’re likely more transparent than their new employer. We used to say that the person was on a performance improvement plan (PIP) and it didn’t work, but stopped because PIPs gained a negative connotation. We’re working to replace it with a proactive, positive way to help people grow in their roles.

Joel: At Buffer, we do share information when people leave the company, but we keep the details of the feedback and performance improvement plan private leading up to that. We experimented with fully transparent feedback for a few months, but it didn’t work out very well. People weren’t keen to give transparent feedback very often. Sharing something potentially sensitive about an area someone can improve in can be difficult to do 1:1, so doing it publicly made things even harder. On the few occasions when someone managed to provide constructive feedback to another teammate, it quickly became a much bigger thing, due to its public nature. Frequently, we had other people jump into the discussion to provide their opinion of the situation, which is only natural if you have full context and feel you have a valuable perspective to offer. Ultimately we decided that fully transparent feedback didn’t quite work for us, though we still publicly celebrate achievements and provide positive feedback in Slack and Discourse.

How do you talk about company culture?

Sid: I recently decided to stop using the phrase culture fit, because we have to be mindful when building a diverse, accepting company. Often “culture fit” is a shorthand that excuses hiring only people who look like ourselves, or who want a “brogrammer” culture. It’s better to tie to values.

Joel: Buffer uses the phrase “cultural contribution,” for similar reasons; we want to focus more on what people bring to their jobs. Do you have a scorecard for assessing different factors?

Sid: Not yet. That could be beneficial going forward to see how top performers scored in different areas. During the interview I use 12 questions on the website that applicants answer ahead of time. It’s not all qualitative, though. Our technical standards are very high and developers have to actually develop something on GitLab.

How has your approach been challenged as you grow?

Sid: Some pain points for us have been our beloved team calls — it’s a great way to get to know everyone on the team, but our number is so large now it takes a long time. Structuring the team has also been a challenge. We aim to have a maximum of ten people reporting to any one person, but it means we’re getting more segmented. At Y Combinator, everyone was either selling or building, with myself doing everything else. Now I have offloaded finance and business operations on other people, and now I have to stop focusing so much on the product. Now I work with reports to get changes into the handbook, so I have to keep in mind: “You’re building the company that’s building the product.” Having people in so many time zones also means everyone has to stay disciplined about when they ping people: it’s preferred to use issues first, then email, then Slack. For product management we prefer to use GitLab for everything.

Joel: At Buffer we’re having some remote work issues. Things are starting to feel more synchronous because we use chat a lot. Something about chat makes it feel urgent, so people are responding right away to things that they might not need to. Buffer uses Dropbox Paper; hierarchy doesn’t really exist so we need more of a wiki system, and we need to be able to distinguish between source of truth docs and docs used for short-term progress.

Who are some of your biggest inspirations?

Sid: Buffer has been an inspiration for transparency. For getting results and going after what your customers need: Amazon. Tesla and SpaceX are great examples of doing the impossible by focusing on the basics. Also, our team members think of new ways to get the most out of remote work: someone recently proposed a GitLab house swap, and two team members used our travel policy to visit 22 locations over six months.

Joel: Amazon is one of mine as well, "The Best Service is No Service" by their head of customer success is great. Zappos, and recently Patagonia as well. I like their attitude towards avoiding the “deferred life plan,” which is a huge benefit of remote work. I recently read "Joy at Work", by Dennis Bakke, founder of AES. Interestingly, “fun” was a company value, not ping pong tables but really making sure everyone has responsibility and satisfaction at work.

Have more questions? Tweet @joelgascoigne and @sytses using #transparencytalk

We want to hear from you

Enjoyed reading this blog post or have questions or feedback? Share your thoughts by creating a new topic in the GitLab community forum. Share your feedback

Ready to get started?

See what your team could do with a unified DevSecOps Platform.

Get free trial

Find out which plan works best for your team

Learn about pricing

Learn about what GitLab can do for your team

Talk to an expert