Our Handbook is open source: here's why | Hacker News Reader

Our Handbook is open source: here's why

about.gitlab.com

347 pointssytse101 comments

From the handbook [1] :

> Technical interviews

> Try to get a real sample of work (which we already do for developers by working on GitLab issues) Avoid puzzles or weird algorithm testing questions. Probing for data structures is fine as long as it is relevant to the job the person is going to do.

> Be mindful of the background of the candidate, someone who knows 10 languages already (and some languages in particular, Perl for ex), may pickup ruby in a second given the right chance. Don't assume that someone with a Java background will not be capable of moving to a different stack.

> Consider including non technical people performing soft skills questions. Because technical people should be capable of talking to non-technical just fine, we should assess it.

Kudos to GitLab for these sentences. I think this is far better approach than the usual technical interviews.

1 : https://about.gitlab.com/handbook/hiring/#technical-intervie...

Thanks, credit for this goes to our infrastructure lead Pablo if I'm not mistaken. He joined us from Amazon so it might be inspired by their process of which he speaks highly.

It's a great process to have too. Hire personalities that fit and work well with teams, and train them to be the ideal candidate instead.

I don't know... less than a year ago I didn't even get an interview because they were (legitimately) concerned with my lack of experience with Haml and Rails.

I mean, kudos to them if they changed their view on this. I just wanted to let you know about my experience on the topic at hand.

I think we had the same view a year back but the bar is higher when your experience is less relevant. Of course we make judgment errors too, feel free to reapply.

I promise that your open solicitation to GitHub http://octohire.me/ was not held against you :)

Just absolutely fantastic values for work-life balance and certainly makes GitLab look _very_ appealing...

Some of my favorites:

We're a distributed, remote-only company where people work remote without missing out. For this, we use asynchronous communication and are as open as we can be by communicating through public issues, chat channels, and placing an emphasis on ensuring that conclusions of offline conversations are written down. https://about.gitlab.com/handbook/#communication

Don't frown on people taking time off, but rather encourage that people take care of themselves and others. https://about.gitlab.com/handbook/#paid-time-off

Runbooks for the on-call person for common issues https://gitlab.com/gitlab-com/runbooks

Edit: Link formatting

This will sound like blatant propaganda for GitLab, but you'll have to take my word that I'm being sincere here:

GitLab is by far the best company I've worked at and the best company you could work for, as far as I can see. The values that you see in the handbook are really what every single one of my colleagues works and lives by.

People frequently take time off and the team is always supportive, whether it is for a long vacation, personal matters or just to play a newly released videogame. This happens at every level in the organisation.

Asynchronous communication is hard. We were lucky that we've stuck to insisting on doing this well since the very start of GitLab Inc and we're continuously working on making it easier to contribute to documentation and to encourage everyone to do the same.

Interestingly, more and more of my colleagues (and myself included) are moving house to their favorite places to live. Often in other countries. Remote work in itself does not guarantee that you're comfortable enough to make big life changes, you need trust in the company you're working for. I believe that by being transparent, fair and understanding of what makes a good work/life balance, we are slowly achieving to gain that trust.

What if i want to "sleep" for 30min?

Third line in taking time off in the handbook [0]:

> You don't need to worry about taking time off to go to the gym, take a nap, go grocery shopping, doing household chores, helping someone, taking care of a loved one, etc. If something comes up or takes longer than expected and you have urgent tasks and you're able to communicate, just ensure the rest of the team knows and someone can pick up any urgent tasks.

[0]: https://about.gitlab.com/handbook/#paid-time-off

Sounds amazing. You need any London based project managers? ;)

Thanks! We rarely need someone in a specific location. Sometimes we do need support engineers in a specific time zone. We don't have projects managers yet, we try to use GitLab as our project manager :) But have a look at our vacancies on https://about.gitlab.com/jobs

Well, we don't care where you're located!

We're not looking for project managers. But you can see all our current jobs on our job page [0].

[0]: https://about.gitlab.com/jobs/

No junior jobs, eh?

We have a few junior team members [0]. If you think you would make a great fit in one of the roles, but at a more junior level, I urge you to still apply. The respective hiring manager can let you know whether it's possible to fulfill the same role as a junior.

[0]: https://about.gitlab.com/team/

If you are open to people applying that don't quite meet the requirements of the position, you should change the position description. It's well documented that this type of approach tends to reduce the diversity of applicants.

(Not to be a nag - I think it is great that you folks are sharing this, and it sounds like a great place to work.)

The diversity is indeed an important issue. We thought about this and all of our job posts contain the following text: "Avoid the confidence gap; you do not have to match all the listed requirements exactly to apply.". Confidence gap links to http://www.theatlantic.com/magazine/archive/2014/05/the-conf...

For an example see https://about.gitlab.com/jobs/production-engineer/

Please let me know if you have any other suggestions.

> [0]: https://about.gitlab.com/team/

That team page has very few women listed, not to mention women in engineering roles.

Do you see this as an issue, and if so, what steps are you taking?

There were a couple engineering/dev jobs that had sections for Junior (in the individual descriptions). Check the support listing(s).

I've been pondering about applying for way too long, forever waiting to complete this or that FOSS project of mine, but your feedback sounds too much like the people I want to work with: kind and open (which I've experienced when contributing), from which trust comes naturally.

Screw it, I'll be applying soon.

Great to hear. Good luck with the application!

If you don't mind me asking, is the pay competitive?

I definitely like the ethos of GitLab, but unfortunately most of the remote-only companies I've interviewed with just don't offer salaries competitive with either SV/NYC tech or what I can make doing remote contracting.

Our pay depends on your location. So if you're currently charging an SF rate without the expenses of living there you're better off.

Have you considered open salaries (just the formula really would be all that was needed) like Buffer?

Yes, we're working on a global compensation framework. This is hinted at on https://about.gitlab.com/handbook/hiring/#hiring-processa-na... "The hiring manager can then make the actual offer to the applicant. This may change if/when we have a global compensation framework in place." and in the job description of the Director of People Operations https://about.gitlab.com/jobs/dir-or-vp-of-people-ops/ "Compensation guidelines that work worldwide but tailored to local markets, to the city level"

For now only are principles are detailed on https://about.gitlab.com/handbook/people-operations/#compens... one important one: "We pay on the lower end of market rates for engineering positions because we offer the benefit of working on open source (great workflow, peers, build reputation); most engineers take a pay cut to join."

Cool.

I look forward to seeing a blog post when you have that compensation framework completed. :)

I've seen/heard words like that meaning anything from a 10% paycut to a 55% paycut in practical terms, its too big a range for me to really take away an effective idea of GitLab's pay level which is why I was curious about the more concrete form.

A 10-15% haircut for a place as good as GitLab sounds on paper seems reasonable, a 50% haircut...not so much.

For sure we'll do a blog post about it. By the way if you want something now the Travis CI talk is really good https://www.youtube.com/watch?v=N8u9H6JDAzo

We don't have any hard data on this but I think we're in the reasonable range.

when it comes to deciding compensation levels, what metrics do you use? what companies in the area pay? real estate prices? a mix or something else?

there are places in the world where, say, the real estate is red-hot (obviously making higher salaries more desirable) but where local companies have not kept up with that (making cross-company surveys skew really low) so in that case what would you do?

Managing a distributed remote-friendly company definitely seems challenging, of course you're open source and have an awesome reputation, so salary is very likely not something prospective employees consider as much as they would otherwise when joining (which likely works in your favor in creating a very nice working environment full of engaged folks)

We're still in the early stages of this. Our current thinking is in https://docs.google.com/document/d/1TEHZTvg9jxlwvKvsc5fm2FvZ...

We will maybe end up with a mix of cost of living, cost of labour, and rent.

We address red-hot real estate by considering to add rent to the mix, but it is tricky since some team members might be living in rent-controlled apartments and we want to have a number that doesn't depend on personal circumstances.

thanks for the follow-up, it must be hard also because of say areas where the real estate is skyrocketing due to investment money coming in from abroad, but where rents aren't moving nearly as much (because local salaries aren't moving really), which makes compensation indexed on real estate skew very high, but compensation indexed on rents skew very low if one wants to be able to afford buying a house at some point

So people are paid according what they spend, not what they produce? That doesn't sound very sensible to me.

We thought about paying independent of location. If we pay everyone the same we would have either a huge burn rate or we could never hire great people from the Bay Area.

Another consideration is that people's costs are strongly related to where they live.

But I can also see the case for paying everyone the same. But I think other remote friendly companies are doing the same as us, this video shows how Travis CI thinks about it https://www.youtube.com/watch?v=N8u9H6JDAzo

> Another consideration is that people's costs are strongly related to where they live.

I think what's more important is that their competing offers from local companies will necessarily be higher, so assuming they're worth the higher price, you have to pay it.

From just above: "Interestingly, more and more of my colleagues (and myself included) are moving house to their favorite places to live."

How does pay vary with location changes? If I live in SF now, and get that pay, then move, do I wind up getting paid less? If I start in a small town with low expenses, does that mean I can never afford to move to SF?

That is indeed what is difficult. Any time you move metro regions we'll need to negotiate about the compensation. And if you're moving from an expensive to an affordable region your compensation will be lower.

This kind of removes a lot of the draw about being remote - you'll get a pay cut if you move?!

You get a pay cut if you move to a less expensive metro area. And you have to contact us before you move. But so far we have always been able to make it work. I think most of our team thinks it is great that you do not have to switch jobs when you need to move because of family, the job of your partner, or some other reason.

Who decides what an SF rate is though? SF rates are highly variable, like in any other city.

We try to set rates per metro area so people can move in the metro area without renegotiating. We're still working on the framework, please see https://docs.google.com/document/d/1TEHZTvg9jxlwvKvsc5fm2FvZ...

Thank you for being transparent. You've saved both of us some time.

The pay is not even close to competitive. I've been through the interview process and they wouldn't budge on what would be a 40% cut for me. Very disappointing considering how amazing everything else is. I felt a bit insulted, considering their inflexible rate was several thousand dollars lower than my first dev job.

Was it due to your location? I read they base salary offer on applicant's location... something I am feeling very undemocratic lol... I was idealist thinking I could get paid as per my skills, talent, effort, contribution etc... hell with my location, I could be in India , then in Indonesia and next year working from Mars :-)

I felt the same way, but then you get a pay cut when you go to Mars, and another when you go to Indonesia. If the max rate they told me was based on my location, I'd be shocked if they are even be able to find a mid level dev within several hundred miles of me.

Pay cut will be awkward. Thank you for adding more info, so offer was not even matched to your location...

Right. It's pretty ridiculous that they don't put that front and center, but that "the low pay issue" has to bubble up somewhere in the comments. I find it rather distasteful to lean on open source as the primary reason for paying engineers less. It's plain from comments here and elsewhere that the main pressure is to keep the burn rate low. Which is fine, that's not a dumb thing to want to keep under control. But as we used to say in the Army, you can shine a turd but it's still a turd. And I mean no offense to Gitlab. I use Gitlab in production and think it's great software. All the more reason to pay the engineers well for their excellent work.

Completely agree. Bit of a shame honestly.

We do try to be open about it: https://about.gitlab.com/handbook/people-operations/#compens... "We pay on the lower end of market rates for engineering positions because we offer the benefit of working on open source (great workflow, peers, build reputation); most engineers take a pay cut to join."

And we're working on a Global Compensation Framework https://docs.google.com/document/d/1TEHZTvg9jxlwvKvsc5fm2FvZ... so that you can calculate your compensation before even applying.

Between this and the above comment about interviewing practices (especially regarding language proficiency), I would so apply to GitLab if I hadn't just started a new job last month.

Still... circumstances might force me to move out of state next year, and if that happens and I can't stay with my current employer, I'm certainly going to check GitLab's openings first.

Glad to hear that GitLab will be on top of your list if you have to start interviewing again :)

I'm almost going to bed (it is 10:30pm in San Francisco) but I thought it might be interesting to share some deep links:

The marketing team has their OKR embedded in the handbook https://about.gitlab.com/handbook/marketing/#okrs

If we meet our sales target everyone in the company gets a free dinner https://about.gitlab.com/handbook/#sales-target-dinner

There is a pretty sweet Kramdown SSG guideline https://about.gitlab.com/handbook/marketing/developer-relati...

It is always sad to see people go, but it happens and after the decision is made we do have a checklist for the process https://about.gitlab.com/handbook/offboarding/

A recent addition (thanks Eliran) has been our remote coffee break calls https://about.gitlab.com/handbook/#coffee-break-calls

Coffee break calls are such a great idea!

As someone who works remotely, that is something I will be doing as well from here on out :)

Thanks, all the credit is for Eliran who joined us less than 2 months ago and already coined this term and wrote it up in https://gitlab.com/gitlab-com/www-gitlab-com/merge_requests/...

Thanks! I indeed contributed this idea - I think that's something that is definitely missing in the remote work environment, those casual conversations.

I haven't read the whole thing, but I really like this idea. I was always shocked to see that, when starting a new job, many documents weren't brought up until the 1st day - that is, after I had accepted the offer and left my previous position.

How does it make sense to not show me your company handbook before I decide if I want to work with you?

Now, I'm always pro-active and during the negotiation I'm very upfront: "I will not sign any new document after accepting this offer. If you have a non-compete, NDA, handbook, IP, etc I want to see them and review them with my attorney before accepting the offer." Has worked pretty well so far, helped me avoid very agressive non-compete.

Totally makes sense. Many of our applicants have read the whole handbook by the time they have their final interview. One person remarked: 'I know more about your company than the one I currently worked at for three years'. Because our issue trackers are also open (for example https://gitlab.com/gitlab-com/marketing/issues ) people can see how we actually work. It really helps letting people know what they are signing up for.

Is your only source of income right now the paid hosted repos? If so, how do you plan to scale that to support a staff of over 100 as well as compete with GitHub and Bitbucket who already have a huge market share?

They also offer a self-hosted Enterprise Edition for $39 per user per year. I imagine this makes quite a large portion of their income.

Yep, the vast majority.

Our main source of income is organisations running GitLab Enterprise Edition on-premises, paying us a yearly subscription fee [0].

GitLab.com is completely free, public and private repositories, CI and unlimited collaborators. [1]

[0]: https://about.gitlab.com/pricing/

[1]: https://about.gitlab.com/gitlab-com/

You didn't mention githost.io, is it a non-significant part of revenue (yet)?

The revenue of Githost.io is indeed not significant yet, but we expect it to grow over time.

90-day exercise window on options.[1] That means you may lose your vested options when you leave before a liquidity event.[2]

However they do allow early exercise. That means if you can afford the strike price when you join, then you won't lose your vested equity when you leave. Taxes are the main reason people can't afford to exercise their vested options when they leave, but if you early exercise then you pay no up-front tax (or very little).

So that's better than average, but not as good as the new hotness of 7-10 year exercise windows like what Quora or Pinterest are doing.[3] Reason being, the strike price can still be expensive for folks so it's better if you can just keep your vested options.

[1] https://about.gitlab.com/handbook/stock-options/

[2] https://zachholman.com/posts/fuck-your-90-day-exercise-windo...

[3] https://dangelo.quora.com/10-Year-Exercise-Periods-Make-Sens...

Thanks for posting this. We discussed this internally and have a blog post in the making. Since most options where issued at a relatively low valuation we have not experienced this problem yet. But we are thinking about how to get ahead of the problem before it occurs.

I'll be around for 30 minutes to answer any questions.

Nice, thanks for posting that! You all are doing things right.

Thanks derekja.

Thank you for free unlimited private repos and GitLab CI. This made me switch from GitHub.

Glad to hear that. We'll try to keep providing amazing value on GitLab.com. We working on introducing a browser IDE and review apps.

Browser IDE sounds interesting to me integrated with gitlab. Can't wait to try it out!

Are you guys focusing on ramping up direct sales yet? Emailed Michael earlier in the year and he said that he's focusing on your reseller program at the moment and to get back to him in August to see where you're at. Still very much on my calendar but I figured it can't hurt to check now if you're offering answers!

We have a solid sales team. Michael happens to work with resellers mostly.

I've pointed our CRO (Chad) to your comment to provide further insight.

Thank you very much! I'm located in Australia by the way, which is probably why I was originally referred to Michael.

We are hiring. For the APAC market we are selling through partners at this time. However we are a remote only company and if we find the right people that can do the job, their location does not matter. I encourage you to apply at https://about.gitlab.com/jobs/account-executive/.

Thanks for getting in touch with me, I'll be sure to!

Pretty interesting that you use "1password (PeopleOps vault)". I guess I never thought about using PW-vaults in a corporate setting. Seems like an interesting approach (compared to some alternatives I know that don't work well).

We used Lastpass Enterprise before this, but we found that 1PW works better.

1Password recently introduced "1pw for teams".

https://1password.com/teams/

We're using 1Password for teams at MM.LaFleur and it really is nice. A lot of our employees were already 1Password personal users, and the Teams for 1P just started in Beta when we started looking for a new way to share passwords in a corporate setting, and after trying some different options out this was by far the best.

You can add people to specific vaults and it works really well.

Especially considering there is no native Linux client. They say that's explicitly why your choice for development machine is one of the following: 1) Macbook.

This is an excellent resource for a new startup such as my own. We're interested in evaluating the less-tangible choices that need to occur to develop company culture, and this helps us see these options very clearly. I hope more companies follow suit!

Great to hear that it is helpful. We're hearing reports here and there of new companies adopting part of our handbook.

One recent hire tried to have their department write down more to help with scaling. It was hard to convince the rest of the department so he ended up joining GitLab.

This handbook looks great! However my experience interviewing at Gitlab stands in stark contrast to what is outlined here. Is this a standard/process the company is working on achieving?

If your experience has been different, we'd like to hear what happened and how we can improve. I'm sorry if it has been unpleasant. Feel free to reach out to me (job at gitlab com) or our VP of Scaling Ernst (ernst at gitlab com), who is currently in charge of hiring.

We're always working on improving our hiring practices, which can be different for different positions. Anyone applying to GitLab should have a great experience, independent of the outcome.

I'm sorry that you didn't have a good experience interviewing with us. We recently hired a senior director of people operations https://gitlab.com/gitlab-com/www-gitlab-com/blob/db5c01d2af... that will also focus on improving the interviewing process. We're also considering assigning every candidate a guide that they can consult throughout the process. Would that have helped in your case?

Anyway, we know there is a lot we can improve, feel free to reach out anytime to sid at our company domain.

There's an "unlimited time off" policy; what does Gitlab do to prevent that policy from being punitive in practice to employees?

What sort of punitive things do you mean?

If you go over some secret 'limit' that no one will tell you about, you'll get put in the back of the line for promotions and raises and the front of line when it's time for cutbacks.

We don't track how much time you take off. If you want to take off more than 25 consecutive calendar days, you should discuss this with your manager first [0].

We expect that our people make sensible judgements about the time off that they take, but if it's not written in our handbook, there are no further rules.

> Always make sure that your job responsibilities are covered while you are away.

[0]: https://about.gitlab.com/handbook/#paid-time-off

I believe opposite case is usually prevented, people don't usually take time off for no reason, they go on vacation, family emergency etc., an observed side-effect of unlimited time off is usually people don't take time off at all, purely a cultural(company's) thing.

We are afraid of people taking too little time off. We're considering introducing a formal performance review point that will penalize the team member and/or manager if someone took less than two weeks of vacation (full weeks, not counting days) for not taking care of themselves. But we're not sure yet this is needed. For now the executive team tries to set the right tone by taking vacation themselves. I'm going to burning man and Hawaii this year and I don't work weekends.

Thanks. I didn't mean to be confrontational. I had just thought that after Kickstarter's change, the winds were turning against unlimited vacation policies, and that fixed vacation time was becoming status quo again.

I didn't take it as being confrontational, no worries. Not being able to measure if people take enough vacation is a drawback of unlimited vacations. But we feel that having to ask for vacations and administering them doesn't rhyme with our value of focussing on results instead of hours.

having a remote company also means if you have a cold you're not going to come in and pass it to everybody, and often you can still work no problem (no coworkers getting grossed out/annoyed by constant sneezing, no getting cold on transit on the way etc.) which likely means you need to take less time off, and being remote also means being able to deal with random daytime appointments much more easily, making time off for that not necessary either

In other companies, the policy has sometimes led to employees taking less time off, because of a reluctance to appear to be "that guy" who takes off more than everyone else.

http://digiday.com/agencies/dark-side-unlimited-vacation-pol...

> Asked how many days off she took last year, Dawkins was surprised. Forced to think about it, she realized it wasn’t very much: just 14 days, although “it felt like a lot.” There is a game to play, she admits: “You are subconsciously thinking about ‘does this appear to be too much time,’ but that’s human nature,” she said. “There have to be checks and balances with management so there’s a process in place.”

Kickstarter last year reportedly rescinded its policy because of this effect:

https://www.buzzfeed.com/carolineodonovan/at-kickstarter-fle...

> It’s always been important to us to ensure that our team is able to enjoy a quality work/life balance,” the Kickstarter spokesperson told BuzzFeed News. “What we found was that by setting specific parameters around the number of days, there was no question about how much time was appropriate to take from work to engage in personal, creative, and family activities.”

Another side effect: with no minimum number of vacation days in place, employers are not required to compensate employees for accrued vacation days when they quit.

Isn't 14 days more than the US average. I thought it was 10 days. So she wasn't really taking less than other companies.

> with no minimum number of vacation days in place, employers are not required to compensate employees for accrued vacation days when they quit.

Hmm...how does that work for employees in other countries? In the UK full time workers are entitled to 5.6 weeks holiday per year (so if you work 5 days a week, you get 28 days). And employers are obliged to pay unused days when the employee leaves.

Most places I've been have a distinction between personal or sick days (days taken with no notice) and vacation days which require at least 2 weeks notice before taking. Everywhere I've started I got 5 personal days and 10 vacation days.

In the UK, and I think most of Europe, sick days aren't limited and personal days would depend on company policy. Either can require documentation (doctor's note etc).

I have 30 days vacation, which is fairly typical. Giving twice the vacation length as notice (two weeks for one week off etc) is usually reasonable, but it's usually in the company policies.

Somewhere with unlimited vacation would need to ensure the employees used at least the legal minimum (20 days, plus public holidays).

> Isn't 14 days more than the US average. I thought it was 10 days.

The US average includes lots of different employers in lots of different industries. In most of them, seniority and other factors (many of the same ones that are correlated with pay) are positively correlated with time off. So, it could be both "above the US average" and below, e.g., what would be typically granted to knowledge workers of otherwise similar education and experience in fields of similar demand.

Applause! Applause! Hands Clapping!

Thanks mgrennan!

Does GitLab do internships?

We don't actively look for interns, as we don't always have the time and resources to properly mentor someone without prior experience.

We do have a few talented interns that could get started immediately as they already showed some experience with the position they'd be taking.

If there is a position you're interested in as an intern, you can consider applying to the position, but it's up to the team lead and the circumstances whether we could give you a position as intern.

Reply on news.ycombinator.com