
Our Handbook is open source: here's why - sytse
https://about.gitlab.com/2016/07/12/our-handbook-is-open-source-heres-why/
======
drinchev
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...](https://about.gitlab.com/handbook/hiring/#technical-interviews)

~~~
sytse
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.

~~~
noxxten
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.

------
leetrout
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](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](https://about.gitlab.com/handbook/#paid-time-off)

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

Edit: Link formatting

~~~
jobvandervoort
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.

~~~
morgante
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.

~~~
sytse
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.

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

~~~
sytse
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](https://www.youtube.com/watch?v=N8u9H6JDAzo)

~~~
x1798DE
> 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.

------
sytse
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](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](https://about.gitlab.com/handbook/#sales-target-dinner)

There is a pretty sweet Kramdown SSG guideline
[https://about.gitlab.com/handbook/marketing/developer-
relati...](https://about.gitlab.com/handbook/marketing/developer-
relations/technical-writing/markdown-guide/)

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/](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](https://about.gitlab.com/handbook/#coffee-break-calls)

~~~
groovy2shoes
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 :)

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

------
dudul
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.

~~~
sytse
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](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.

------
deanclatworthy
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?

~~~
jobvandervoort
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/](https://about.gitlab.com/pricing/)

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

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

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

------
abalone
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/](https://about.gitlab.com/handbook/stock-options/)

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

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

~~~
sytse
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.

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

~~~
Trundle
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!

~~~
chadmalchow
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/](https://about.gitlab.com/jobs/account-executive/).

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

------
kriro
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).

~~~
lukevers
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.

------
skoocda
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!

~~~
sytse
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.

------
throwaway412
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?

~~~
jobvandervoort
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.

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

~~~
Daviey
What sort of punitive things do you mean?

~~~
dagw
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.

~~~
vinu76jsr
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.

~~~
sytse
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.

~~~
danso
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.

~~~
sytse
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.

------
mgrennan
Applause! Applause! Hands Clapping!

~~~
sytse
Thanks mgrennan!

------
moosingin3space
Does GitLab do internships?

~~~
jobvandervoort
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.

