GitLab’s Secret to Managing Employees in 160 Locations: Write Everything Down
blog.ycombinator.com
blog.ycombinator.com
We've also noticed that over-communicating is critical but hard - it is surprising the things that are "yeah yeah, we know" to some but are "oh we're doing that?" to others. This is only natural - organizations become complex as they grow, and individuals are busy doing their thing. You often have to bring the important data to them.
On another note, working remote is awesome. I recommend everyone give it a spin once in their careers - but try to find a team that embraces it. I've heard mixed experiences from those who were the single remote person on a team.
I pretty much agree with your thoughts about over-communicating, it's super important and we've run into exactly the same things, where people aren't always caught up on everything going on at the company. In my experience this happens in physical workplaces as well, just to a lesser extent.
Hybrid remote/on-site requires some great discipline. If you have a watercooler chat with someone about a feature, it's easy to forget that a remote colleague wasn't there for the discussion/not document what was said.
+1 for working remotely on a team that makes an effort to make it work.
That said, I completely understand why someone would feel differently.
I like what I do, take pride on it and everything, but at the end of the day, my private life (where I get to choose my friends) is OUTSIDE work hours. And I'm committed to close the laptop as soon as I'm done.
I guess this kind of "school feeling", "we're on the same boat" feeling, where groups of people linger together in long coffee breaks tends to belong to corporate, especially in USA where they work stupid hours to "show off" their commitment. Utter nonsense.
One more thing that I really feel I "broke free" from (after becoming full time remote) is the ALCOHOL CULTURE. Peer pressure into drinking: company credit card on the tab and unlimited drinks (no food, otherwise it's cheating). So degrading.
That said, no one here puts in extra hours to "show off their commitment", everyone shows up when they want and dumps at 8 hours later. I've stayed late when I was buried in debugging once or twice and got told to go home by numerous colleagues. Just things like that, telling you to put it down is a positive influence sometimes. I came in the next day and solved the issue that I had spent 3 hours on the previous day in about 20 minutes.
I don't like myself this weird culture where it's supposed that you have to be always a nice guy, politely nod and smile and say "Completely agree! Except..." when there isn't a single point you actually agree on, so I often dismiss such labels as "toxic attitude". But your attitude is just that — toxic. I'm okay with people being somewhat rude and arrogant and whiny and always complaining about "why should we", but this attitude of "I have a real life outside, and here — I just work here, so fuck you all" — that makes you both absolutely unreliable and very unpleasant to have around. Unfortunately, the word "toxic" fits really well.
I've actually never had anybody to work extra-hours, but knowing that they would is significant part of what makes me care that they don't have to. Technology is worthless, people are what makes companies to succeed, and absence of meaningful relationships with your team basically renders you to be a piece of quite primitive carbon-based technology.
There are plenty of companies that manage their work in a way that minimizes the human component and maximizes the technical utility of their engineers (judged on productive output alone), almost in a way that makes the human component and all it brings with it (unreliability, politicking, emotional outbursts, backstabbing, you name it) irrelevant. In fact, my ideal company reduces face time to close to zero, because that's the only reliable way to eliminate politicians, bad actors and people who try to game the system using social skills and emotional manipulation. A nice side effect of remote work is that it automatically creates that sort of environment, unless you go out of your way to change that (but then the remote work model is probably not for you).
>renders you to be a piece of quite primitive carbon-based technology.
The fact that you don't know how to manage engineers in an entirely meritocratic, non-political environment, says more about your management abilities than anything else.
Bouncing an idea off of someone remote gets difficult. I feel bad for interrupting them and they feel annoyed at being interrupted. Culture also plays a big role in that as well.
To your other point, communication tools are still pretty limited. IM/Slack/IRC are good for some things though a lot of people I work with don't use them. I've yet to see anything that remotely compares to being together in a conference room for high bandwidth interactions.
It's not always roses and rainbows, but it definitely helps.
I hate both working in-office full-time AND working fully remote. But a mix sounds awesome, I always feel energized when working one day from one place, another day from another, and I also enjoy having the meetings in-person...
What this really mean is 50 % teams in a company are remote and 50 % are onsite. Remote working is binary.
Also for me, not always roses and rainbows. But that mutual understanding is really helpful.
And of course, I'd be remiss if I didn't say that we're hiring. =)
https://www.digitalocean.com/company/careers/#current-openin...
Yeah, and your hiring process is rife with stupid biases like autorejecting people based on who they worked for in the past.
This was the second such miserable experience I had with D.O. I assumed that my first bad experience may have been due to a lack of maturity at the time with the interview process and so applied again a couple years later. Wow, was I was wrong.
I have a family and a life where I'm at and part of the reason I like to be remote is because it allows me to be productive with minimal impact on other things (e.g., don't have to waste 2 hours in commute time each day). Places that require quarterly visits to the home office are kind of just aggregating all of that disruption into a single week. Still better than doing it every day, but not a thing to tout as a benefit.
You're welcome to your own preferences of course but, as someone on a largely remote team, I consider regular get-togethers in various forms pretty much essential.
If face-to-face communication is "pretty much essential", what's the argument for continuing to run the company as a remote/distributed enterprise? Isn't the whole concept of telecommuting predicated on the fact that face time is not essential to performing the job function?
Leaving aside the personal interruption represented by such events, I don't understand the philosophical underpinnings. To me, it seems like someone said "There's not enough chance for politics and cliques to emerge over IRC [which is incorrect btw], let's make sure we all get together physically at least once every 3 months so we can find new things to take petty offense at."
Again, I think that well-run open-source projects provide some really good examples of the right way to do a distributed company. They usually have one big pow-wow per year, and it's a convention with planned talks, networking events, etc., and of course, attendance is voluntary and the meetings are transcribed and broadcast. Debate and consideration occurs online where everyone can participate.
If a massive project like the Linux kernel can get by without having such events every 3 months, why can't $Random_Startup?
I've been a full-time remote worker at the same company for the last few years. I'm the only remote worker on my team and one of a small handful dispersed throughout the company. I've been back to the head office once. It's absolutely true that there are negatives and downsides to being remote, but nothing that jeopardizes my ability to perform my duties.
Beyond that, I did several years fully remote as a full-time contractor. Some clients were local and I would meet with them face-to-face up to a couple of hours a week, but the majority were non-local. I only met a few of these people in person and I don't feel that impacted my ability to do my job.
Like so much else in contemporary tech culture, my opinion is that it traces back to putting single 24-year-olds at the helm and making everything subservient to their whims. They think it's cool to rent out a vacation home on a beach in Belize and fly 10 people out to set up camp in there for 2 weeks. Grown-ups with spouses and kids or other significant non-work obligations are likely to be less enthusiastic.
I think it's predicated on face time being not necessary on a day to day basis given the tradeoffs associated with requiring it.
A lot obviously depends on the task and individual preferences. I probably shouldn't have used the word "essential." However, I've found some level of F2F very useful and I'd probably encourage teams that weren't too distributed to get together physically on a semi-regular basis (as most want to do anyway).
It's funny that you mention the Linux kernel. I've heard GKH on a panel at a LinuxCon explicitly say that he thought one of the reasons that Linux development was so robust was because there was enough money in the ecosystem to get people to events like he was attending.
I think our face time is abit excessive but it's ok, even nice, but that's because it fits into my workday and family life, and it's always paid travel time.
Management is onboard with it and has taken the openly stated position of "we don't care as long as you're reachable during the hours it's reasonable for someone to be online" (and the obvious: "deliver your deliverables when they're due"). In my case as the ops lead, I have additional hours but we are so well baked into slack that if someone needs me, I get pinged via mobile, reply from where I am or delegate it. Heck just last week I did a couple of deployments from 4 timezones away, tested it, and left a PR note in the channel with a link to the JIRA ticket. It got worked, updated, fixed and closed while I slept.
I wouldn't say our team made a concerted effort, we just set the expectation that if you're going to be away, let us know, and during production hours the absolute bare minimum is that you'll be reachable if absolutely needed. Heck, even if you need to leave early to take care of home stuff or what have you: go to team chat "Hey I'm taking off early to take care of thing" and go. You'll get replies like "Take it easy" and "Cya tomorrow".
Every team meeting has a join.me session for remote people to join, they speak up and contribute if asked or needed, even our stand-up comes with an auto generated Google Hangouts link that gets published to slack every morning at 10am. If you miss the stand-up or can't connect, people have been really great about just typing up what they're working on when they're available again.
Otherwise, no one really cares. I've absolutely loved it. This is one of the better teams I've worked on just by how well everyone communicates without bombarding each other. People stay out of each other's way, but will ask when they need help and there's never any fear that you wont get someone willing to at least look at a problem with you; even if they don't know the answer-I've had devs pipe up and offer ideas and a second pair of eyes. Problem gets fixed, I shoot over a thumbs up emoji and a "thank you" and we go back to our own little worlds. Read-only Friday comes along, and we go drink.
Contrasted with my last job where I negotiated the right to work remotely because the distance constituted a total four hour commute. I was consistently turning in deliverables on-time or early, conducting client calls via an expensed voip phone and getting several orders more work done from home because I wasn't waking up hours earlier than normal to make the 2 hour drive in.
That privilege was arbitrarily lost because of a few critical management slip ups (owner took a vacation with more than a couple projects open in the lurch, and left no instruction behind for me in his wake, so things failed in a big way when). Shortly after becoming an 'office worker' again and putting in 12 hour days between commuting and sitting at my desk, I was out the door.
Long story short: I actually started on-site but negotiated part-time remote. Then after about a year of that my spouse accepted a dream job offer on the other side of the state and so it was no question that we were moving. They wanted to keep me on and so I transitioned to full-time remote.
It has it's ups and downs. From my experience, it depends on the team and ultimately the lead and/or the manager. If they get it, it's good. If they don't, don't bother.
My last team, it was beautiful. Everything worked great. It became obvious to me after transitioning away from that team just how much extra work my manager was doing to keep his remote employees in the loop. With the team I'm on now, it's not working at all. Why? Because, as you so eloquently put it:
> the people who were remote were out of the loop on almost everything... If you have a watercooler chat with someone about a feature, it's easy to forget that a remote colleague wasn't there for the discussion/not document what was said.
This is exactly the problem I am facing down. About a month ago, I even tried talking to my manager about it. Even going so far as using this exact phrasing. His response was that I should come to office for 1 or 2 day trips! Completely missed the point. I'm not surprised, I guess I just expected some effort.
I'm trying to remain positive but it's tiring. I can do good work and make progress but I'm with a lead who is insulating me from meetings and it feels deliberate. The few times I am invited in to a meeting, it's easy to see that he accepts and assumes credit for _the teams_ efforts. He was hired recently as a Senior, our manager wanted him to transition to a Lead, and he's actually landed somewhere around trying to be an architect. Ranting aside, when I bring my concerns up to him it's obvious that there's no attempt to better understand the issues/challenges of the hybrid approach. It doesn't help that he's never worked with remote employees before, either.
I understand he missed the point in this case. However, if a company is willing to pick up the travel costs associated with a partly distributed team getting together on a semi-regular basis, that's often a pretty good approach.
Yes, processes should be such that ongoing communication is good. However one of the costs of having a more distributed workforce (which has various benefits to the company, including financial) should be a bigger T&E budget.
Am I missing something?
The fact is, this entire team is all on Slack and we all have email and we all use zoom. We have internal Wiki's for documentation. We have JIRA. And on and on. The point is, there are plenty of established avenues available for people to dissiminate this sort of information but it doesn't happen. I don't think that I'm asking them to modify their behavior by asking that they include their team members or to remember that they exist when they have those impromptu meetings.
Since you're in the minority, you can't demand the majority change their working style for you. It's up to you to fit in to how the majority works, say by showing up in the office. Or you'll miss out important information, which will be to your detriment, not theirs.
> To do what, exactly?
To communicate with others the way they apparently prefer to communicate — in person.
And to build relationships, which lead to working smoother, and prevent misunderstandings from snowballing. It's easier to get pissed off with someone over email than in person.
There are many advantages to facetime. You can decide to forego those, but you can't tell others to, just because you want to.
The only way to fix this is with some concious effort to reproduce the results of water cooler discussions explictly -- and if you spend that effort anyway, you might just as well do it via Skype or Slack... He doesn't have to be on-site.
And, going to the office, those conversations will only happen to include me if they happen (they're impromptu, somewhat random) and when I'm there for 1 or 2 days at a time. When I go back home and to my co-working space I'll continue missing things. That's the point.
If the project suffers as a result of all of this, which is what is actually starting to happen, then I suppose by what you're saying here I shouldn't actually care? Heaven forbid I ask _individual people_ to keep _the team_ in the loop about the thing we're all trying to _collectively_ build.
Three other people have responded to my last post. Please see those responses, since they address your points.
On another note, having remote employees without supporting that type of working company wide is just silly squandering of resources. Sadly that is fairly common anyways.
No, he was asking that already when he asked if he could work remotely. And the company said yes.
> Since you're in the minority, you can't demand the majority change their working style for you. It's up to you to fit in to how the majority works, say by showing up in the office. Or you'll miss out important information, which will be to your detriment, not theirs.
Then they shouldn't have agreed to let him work remotely. Majority or minority doesn't matter after that decision has already been made.
Maybe they should revisit that agreement if apparently they can't make remote workers fit in the team.
"No, we believe we can't make it fit with the way our teams are currently communicating" (and do not want to change that) is a perfectly legit answer to the question if remote work is an option.
However, once the decision is made, of course effort is required from all sides.
Otherwise, why even bother asking about it.
It's like applying for a job on the condition that you can't work Wednesdays because of allergies. The boss is perfectly fine with this, you can work the other 3.5 days, you're hired. And then it turns out the most important crucial meeting of the week, of which no minutes are kept, is on Wednesday. Now this is your problem, somehow. Who messed up here?
scruple's boss should have told him that right at the interview stage, before a job offer is made. Maybe say that he expects scruple to turn up in the office for a few days every month. Or whenever a major decision needs to be made and scruple is out of the loop. Or have regular one-on-one meetings over video-conference with everyone in the team to remain connected, making up for his physical absence.
Whatever the details are, scruple's boss should have told me he'll need to make an extra effort to make up for his remote work, and both sides can then decide whether to go ahead with the job.
In the absence of that, both sides end up holding the other responsible for the problems, which is a no-win situation.
Well, this is awkward. I don't think you even read my original post. I literally said that I transitioned from on-site to part-time remote to full-time remote. I've been with this company for many years, it's gone exceptionally well until very recently.
> Maybe say that he expects scruple to turn up in the office for a few days every month.
We've had the working agreement ever since I went full-time remote, back when I was on a different team, that I am unequivocally full-time remote with no obligations to turn up in the office. *editing this to add: If that needs to change because of new team dynamics, that's fine, but it's going to be awfully hard on my colleague in Mexico.
> Or whenever a major decision needs to be made and scruple is out of the loop.
Major decisions should NEVER be made in isolation or with team members who aren't even sure what is being tabled. Why do we need to play "catch up the other 3 team members" when we're having a discussion about a major decision? Oh, because another team member keeps having side conversations with product people or customers and not relaying the information back to the rest of their team? Hmm, sounds like a personnel problem to me -- and not with the "out of the loop" team members, either.
> Or have regular one-on-one meetings over video-conference with everyone in the team to remain connected, making up for his physical absence.
Myself, my other full-time remote colleague, and my other 2 team members who are on-site meet every single working day. We scrum, we go our agile rituals, we pair remotely, etc... We meet with our product people over video conference twice a week. We meet with our managers infrequently but I personally talk to my manager over the phone at least once a week.
> Whatever the details are, scruple's boss should have told me he'll need to make an extra effort to make up for his remote work, and both sides can then decide whether to go ahead with the job.
You're totally off base here.
Sorry for getting that detail wrong. I re-read your original post to make sure I didn't miss anything else.
Since you now say that you agreed ahead of time that you had no obligation to turn up in the office (that information wasn't there in the original post), I now agree with you that your manager was wrong. (This is something I've seen happen over and over again with managers — they say yes without thinking things through.)
If people are deliberately withholding information from you, as you said you suspected in your original post, that's obviously a bad thing.
Regarding my suggestion to have regular meetings, you're already doing it, so that's good.
If I say yes, I get skewered later when people on both sides aren't adapting to the new situation.
If I say no, them I'm a do-nothing windbag who can't feel like anything is getting done unless I can physically see the people typing and clicking.
If remote work is the minority situation, you're going to see challenges. Even if it's the norm, there are decisions that are time-sensitive and you're going to sometimes be dropped (same as if you were on PTO that week; you're just more exposed to it as a remote worker in a predominantly co-located team).
I have teams all around the world; even with that, we still bother to move desks to put squads all together in the same location. If you agree with the latter practice, I think you have to give some nod that co-location matters, even if only a little bit.
That way, you're setting clear expectations ahead of time.
Dev's are missing the point of manager. Manager becomes obsolete when the communication channel is just some software medium to share text.
For me (being remote and even 9 time zones away), I've tried to scale back my own ambitions. It's hard because I've worked as an agile coach for a long time, so I'm used to having quite a lot of influence. I think trying to reinvent yourself to work for other people's success can be useful.
It can be a different style of political game. You need to show how they are better off with you than without you. It's not nearly as depressing as I'm sure this sounds. Just a different way of making a contribution.
The thing is that even if I went into the local office, I would still be "working remotely", because the development teams are distributed all around the world. Therefore everything has to be done on mailing lists, IRC, bug trackers and occasional conference calls.
When we do video chats, the folks in Philly call in just like they were on a home computer. They don't all get together in a big room and call in. We also make a point to run all of our conversations through group chat and project management software. And plenty of the Philly folks work from home regularly as well. Remote work isn't simply tolerated, it's put first.
The remote folks (myself included) miss out on some of the office benefits like family-style lunches and get togethers, but we all make regular trips there and get to partake. It's not purely about location either since we're spread across numerous time zones. It just takes more deliberate communication.
There's always going to be water cooler chats, but those can just as easily happen via email where nobody would see them. We have to make a point to capture and share things to the right people.
Development / Marketing / Support / Sales
And even then you can have smaller teams:
APAC Sales / EMEA Sales / US Sales
So no "org" should be that big.
PS: we should hang out sometime! I see you live in BK.
We also schedule quarterly travel to the office, and have a weekly meeting where remotes get together and share what they are currently feeling anxious & excited about. That's a remarkably effective way to learn a lot of things you might otherwise pick up on w/ body language, and more.
We have found that many wikis don't have good "related pages" functionality, i.e. they are hard to browse.
In my particular case, I want a company that is remotely open, but sponsors a visa for city/country X which could hold a tiny cheap apartment and a space to call home. But in my case these countries I want to call home are Japan and Korea and now try to find a remote company there.
They published the following article about remote work: https://auth0.com/blog/21-tips-for-remote-working/
Exceptional products have exceptional UX. Gitlab IMHO has the worst UX of all git based products out there, I much rather take BitBucket over Gitlab. I tried using Gitlab, but no, I would much rather pay the 7$ to GH for my private repos.
I sincerely hope they make an exceptional product. And 'should' better be 'must'!
Main complaint overall is the incredibly sluggish git push speed.
git push speed is fine on our own ce installation but gitlab.com is beyond shitty.
We expect it to become a standard component of GitLab in Q1 2017 and to reach full scope in Q3 2017.
If you are curious about what we're doing, take a look at the issues under UI Polish: https://gitlab.com/gitlab-org/gitlab-ce/issues?scope=all&utf...
Or feel free to point out any particular concerns here or through the issue tracker: https://gitlab.com/gitlab-org/gitlab-ce/issues
I think the GitLab interface is pretty good, especially compared to GitHubs. I can't speak for BitBucket since I've only used it once, but I do remember having a hard time finding my way around it.
Here's a start: http://measuringu.com/essential-metrics/
I had to do some IT support for a doctor's office many years ago, and (unrelated to what I was doing), had a chance to look at the system the front desk lady used to manage the patients, appointments etc. and it used a "clunky" old text based system (perhaps even DOS based?). TO me, it looked utterly bizarre and incomprehensible. But man, the front desk lady was lightning fast doing anything with it. Of course she trained on the system for years, and just entered keypressed rapidly that didn't make sense to me, but achieved the desired result... So, zero clicks, low search times, no (for me visible) user errors... so I guess they never should have switched, as this was the "objectively optimal" UI?
Personally, I don't think so. I.e. I think the UI could have been better, and easier to learn. But of course it's also important to see how usable it is once you do learn it... I was at that doctor's office again, not so long ago, this time as a patient... new lady (the old one retired, I assume), new system... flashy graphics... everything done with clicking, I don't even know if there still are shortcuts, the new lady certainly didn't seem to use any. And it did feel slower overall -- though this is of course a subjective evaluation only, with many years between the two observations. Plus it's somewhat unfair to compare somebody who trained a decade on a system with somebody who for all I know started a week ago... but I guess that's exactly my point here...
It sounds like you'd find it interesting.
Are 10 easy clicks worse than 2 hard clicks? Is a long, easy experience better than a short stressful one? And so on. Couldn't that vary by each person's preferences?
These are the top 3 things I can think of, based on my interaction so far. I wish Gitlab success. Thanks.
Honestly, all Atlassian products have terrible UI. JIRA is just as bad.
The individual UIs are not that bad. The problem is that people tend to use not only e.g. JIRA, but also Confluence, or more. And then the (massive) differences between their products in UX appear.
As a sysadmin, there's one thing that really annoys me: all that Atlassian stuff is written in Java (which means: on every problem one has to dig through pages after pages of Java stacktraces), and it eats resources like nothing else. GitLab got better in the recent versions, but it also had its fair share of interesting problems with memory leaks.
Oh, and both don't support MySQL (Atlassian does, but very limited) - which is bad if nearly everything else is MySQL and you already have a MySQL DBA.
I've still gotta disagree. Jira's UI is horribly inconsistent and haphazard. Some actions are buttons, some are links, some are hidden until you mouse over, everything feels like it was just tacked on wherever there was (or really wasn't) free space. It's probably the worst UI in a modern, commercial web application that I've encountered.
It feels like they took some Photoshop files from a designer and gave it to their dev team and said "make this, I don't want to hear any complaints."
Remember that git-based products include Gerrit (a UX which I hear hate about, but frankly, I like a lot)
I lost track of the amount of times I was told to "look at the source code" when asking about documentation for the internal framework.
Also fun was being assigned a feature and having it's functionality explained over the phone, with any subsequent follow-up being met with "Didn't we already talk about this"?
I never would have thought that a remote based team would have the worst documentation out of anywhere I've worked, but that's exactly what happened.
Can you elaborate on this one? This is my preferred way.
You work on product A. Your VP of very important things declares that every product should use library L. Library L has been designed to incestously interact with product D and makes a bunch of assumptions about what the "working environment" should be.
Teams B and C have already made the transition, so L made some kludgy APIs to make B and C interaction possible, though it is maintained with low priority because everybody knows D is the money maker. Both B and C have a bunch of assumptions in common that A does not share, and they both had to compromise and emulate D environment to some exent.
You are given L binaries, a few toy examples of how to use the most basic functionality in L, and access to B codebase. L codebase does not use the same source control system, so you don't even know where to begin looking for their code.
Please keep in mind that your manager does not expect you to learn all the inner workings of L. Your priority task is to use L to support some new feature in A. You still have a number of other tasks to accomplish in A that are not related to L, and some of those might raise in priority with little or no notice.
Do you still think it is a good idea to just browse L code, without knowing how large (or well writen) it is?
Having struggled with very large tools that were anything-but, I beg to differ... but I guess it is a matter of personal experiences.
Add in cases where people go crazy with inheritance and you need it or else you have no way of knowing what all it is this new class can do.
Then there were times when I did dig through to understand why something worked. When I pointed out that something should be done differently (an id-lookup done hierarchal instead of flat) I was told "Oh that's deprecated, you're not supposed to be using that anyways". And how exactly am I supposed to know that?
Ultimately it was a frustrating way to spend a lot of time.
All of the development teams were also on Slack, and many people tended to have those quick side conversations online instead of in person, so there was a public searchable record and you could jump in more easily.
It begins with the fact that the company's code needs documentation. I'm a big proponent of Robert C. Martin's "Clean Code" and the idea that code should read like prose - by reading the code, its purpose and ideas should come across naturally.
It ends with people asking "Didn't we already talk about this?".
Is this your first job? Don't let yourself get treated like this.
Or a normal place with poor-mediocre leadership.
Documentation doesn't happen by magic, and documentation is a skill. If it's not a priority from management, folks will be heads down getting their own tasks done, not thinking about what the other person/team needs.
But you're right, the timing of this piece was probably not ideal.
...and it's not like any large web company hasn't had some howlers over the years.
Could you elaborate? I recently heard about GitLab probably less than a week ago and was under the impression they're a great company to work for.
Like any company, we have our own business operations issues too but it's still one of the best jobs I've ever had. We're pretty open about our flaws, to the point where the CEO even has a page that lists his out: https://about.gitlab.com/handbook/people-operations/ceo-pref...
What's tone-deaf is the vitriol some people are spilling in this thread.
I liked their transparency a lot too! But it's neither possible nor acceptable to keep six hours of data loss and eighteen hours of continuous downtime "to yourself".
GitLab offers a middling base salary for a role and applies modifiers for experience and city-based cost-of-living (both of which may modify the base downward; my CoL adjustment is -40%, and I live in the United States!). They explicitly state on their hiring page that they prefer people from cheaper areas. [0] [1]
On top of that, just from their headcount, it sounds like they have way too many people. 160 for a technical company like this is hard to manage when the employees are local; it's even harder to manage when employees are remote. Again, for remote work, you need mature, highly-skilled staff with a strong history of successful self-direction. You're not going to get that when you're chopping their salaries in half based on their location. Bad local wages is a major reason to work remotely in the first place.
[0] https://about.gitlab.com/jobs/developer/ ; use the calculator at the bottom of the page
[1] https://about.gitlab.com/handbook/people-operations/global-c... ; gems include "you are required to notify us when you move and we may adjust your compensation up or down" and "[a]ll things being equal we will hire people in lower cost markets vs. higher cost markets."
I 100% think you are on the right track. The only people from my area that would take a GitLab salary just can't get a job elsewhere.
Sacramento, CA. Mean Salary (per latest BLS data) [0] for Software Developer, Applications: $107,540; for Web Developer: $78,050
Sacramento, CA Gitlab locality pay index: 0.39+0.25=0.51
Vs.
New York City, same BLS figures [1]: $108,770/$81,430
NYC Gitlab locality pay index: 1.00+0.25=1.25
Sac/NYC Salary Ratio (BLS): 0.989/0.958
Sac/NYC Salary Ratio (Gitlab): 0.512
Fundamentally, the rent index based methodology you are using is, I would guess, giving you below market pay almost everywhere that isn't NYC or San Francisco, assuming that you've hit the market wage for the skills you are targeting in your NYC baseline.
Didn't notice it until after the edit window was closed.
[0] http://www.globalpropertyguide.com/most-expensive-cities
I wonder if any of these indexes breaks down a city by zip code. A good analogy for here would be if you averaged all rent over the neighborhoods in Brooklyn then used that number for a bunch of candidates in Williamsburg.
It really penalizes living in a third- / fourth-tier startup hub, for example, vs either a first- / second-tier hub or a non-hub.
Taken from another perspective maybe it's an intentional filter on the candidate pool to specific cities or countries. That wouldn't seem to be consistent with most remote philosophies but it's something to consider.
Interestingly, Buffer's salary calculator is almost the opposite with a relatively small percentage difference between Nashville or Austin vs SF or NYC for instance.
Remote employees who are good at being remote have some very good options at this point of their career. Why the heck would they take less money simply because they had the foresight to move to a low cost of living location? Half the (stellar) people seeking remote work have built their entire lives around this fact - and have made very conscious decisions regarding their career and lifestyle.
Obviously it's working out for Gitlab, but I can't imagine any of my senior remote talent finding this acceptable in any way. I guess I could see it working for a couple years "converting" an engineer who is super excited to move into remote work vs. on-site. But beyond that, this policy seems extremely dangerous to me.
I'm not really sure what the justification for CoL adjustments is, beyond "we can get away with it". Apparently I'm worth paying $120,000 working from home in London, but if I move 70 miles south I'm worth half that. Not only does it make little sense logically, there's no way cost of living here is less than half that in London, so its not even calculated correctly.
As it is, for me the calculator gives me roughly what I was making in Dallas, a bit less (at the top end) than I make now in New York, and a Lockheed entry-level salary if I were to move to Ft. Worth.
That's... aggravating. You'd think their system would treat all locations in the same Core Based Statistical Area as the same. Better yet, treat all locations in the same Combined Statistical Area as the same; in fact, the definition of a CSA is a set of adjacent CBSAs with interconnected commuting patterns.
And the data is all freely available in machine-readable form from the Census Bureau's website [0], so there's no excuse to not use it.
In fact, just this past week, as a personal project, I've written a bunch of code to parse a whole ton of census data, combining CBSA/NECTA data, data from Summary File 1 (i.e. population, sorted by a number of demographics), and Gazetteer data (for land area, so I can calculate population density). Over the weekend, I'm going to take a stab at including data from the American Community Survey too.
Getting rid of the COL deduction by selecting NYC as my location actually makes it reasonable so something tells me not pinning the US salary floor to 1.0 is saving them money and simultaneously getting them lower quality developers.
The kicker is that I'm employed remotely by by a company based in a city whose CoL hit is even larger than the one I currently live in. The NYC range they give is plausible for me as someone who lives in a place that is much cheaper than NYC, but it's not exciting and wouldn't really motivate me to apply.
GitLab's numbers may look right on paper (and they do explain their methodology in the second link, discussing rent indexes, etc), but they're absolutely not comparable to what good people earn in the real world. Good talent commands good wages everywhere. A skilled remote worker is not going to come to GitLab for an average-for-their-area salary.
Even when working locally, talented people make much more than the average for their area. I know this because I've hired many good people and unless they're entry-level (meaning they're good but haven't had a chance to prove it yet), they don't start coming in the door until you're offering at least a 50% price premium over the reported median. In fact, we had a lot of bad candidates come in asking for around that much. The senior people I hired would make more than double the median for their nominal role. The stats on these government reports don't account for seniority, skill, niche demand, etc., and likely include some people that self-report as holding a title when they're really just aspiring to that position.
Once you're a mid-level dev, you should be pulling in a bare minimum of 80-85k, no matter where you live. I say this not as a bubble-dwelling San Franciscan (who surely finds such numbers laughable even for entry-level), but someone who has lived in various parts of "flyover country" his entire life. When local opportunities for at least this compensation are not forthcoming, go contract or remote.
There's no reason for good people to leave money on the table, and GitLab doesn't appear to get that.
They're paying talentless Wordpress dev prices for their mid-tier devs, by local standards. This is in a mid-sized midwestern US city. LOLWUT? No one decent in my city would accept a job there.
"In developing the compensation formula above, we looked at the compensation of our team members which had been set in the past (without the formula), and found out that there was a statistically significant correlation between compensation and the factors that are now in the formula. We purposefully chose to look for correlations with metrics that are probably causal and definitely relevant in people's lives (the rent!). This also has the advantage of letting us work with data that is readily available publicly, as opposed to trying to scour the web for market compensation rates for all roles in all locations. Perhaps surprisingly, there was a stronger correlation between compensation and rent index than with the more general cost of living index available through Numbeo (or the cost of living with rent index, for that matter); and so we moved ahead with the Rent Index."
And, for US locations, BLS data is readily available publicly. While that may not have been a suitable source for a worldwide formula, it would have at least been a suitable reality check on the validity of the formula you came up with to see if it reasonably approximated the variations in market rates within the US.
You're also right that we need the calculator to work worldwide, and I suspect that that may be part of the reason here that the calculator works well on that scale and then not always as well as it should on more local scales. We'll continue to explore how to get better on both scales; the challenge is always that we want to keep things as simple as possible also.
I've made two issues based on your comment here and the one where you shared specific data for Sacramento (thanks for that!):
- https://gitlab.com/gitlab-com/organization/issues/23 to cross check BLS data with the calculator.
- https://gitlab.com/gitlab-com/organization/issues/24 to address the global vs local question.
A) What's to stop me from getting hired in a 0.21 COL area and moving to San Francisco or Washington, DC? Are you going to fire me or pay me $20k a year because I moved?
B) My labor is not worth less and my work is not lower quality because I move to SE Asia or Eastern Europe. This is idiotic.
Nice to "write everything down"
By offering people medicore, local salaries, they are losing a massive opportunity to clean up on the great talent in remote areas.
Why would someone want to live in a low-end city (assuming they are mobile) - when they could live the same 'quality of life' in a much cooler place?
Assuming a degree of mobility - the whole point of living in a 2cnd tier place is that you can save a lot of money, which makes up for the '2cnd tierendess' of the place.
Montreal is 1/2 Boston. There are a good batch of great devs in Montreal. I could double my salary and move to Boston? I'd probably just do that. And still save more.
If they paid a 20% premium over other Montrealers, they'd be able to attract the best talent - and still save a lot of money over Boston/SF/NYC.
Paying 'regular market wages' for remote localities is not a winning proposition - it doesn't take advantage of the fact they are great startup, reasonably well financed etc..
But what neighbourhood you live in Boston is a choice.
Picking up and leaving a city is not a choice for most people.
Also the 'cost of everything except housing' is pretty consistent - everyone pays roughly the same a gallon of gas, and an identical basket of groceries.
That said, acknowledging that a lot of things are different from when I was starting out, I can't imagine walking into my first tech industry product management job as a remote worker.
They seem like nice folks, but as an experienced remote worker (with a history of both remote employment and remote contracting), I wouldn't bother to apply based on what I currently know.
Their base is off of NYC, apparently, and they adjust based on location; from what I infer from that, if they are really middling for NYC, their modifiers are all wrong for the way market wages actually vary by location; in Sacramento, the adjusted range is below public sector pay for similar roles (salary alone, not considering benefits, etc.), much less private sector pay.
The thing is, their basic methodology is arguably somewhat sensible, but they could (at least in the US) use BLS numbers for job categories by location to get modifiers that actually reflect local markets and keep their pay consistent with respect to local markets. By choosing an index that evidently is a poor proxy for variations in market pay, they end up with pay that doesn't make sense.
Depending on which of the 5-6 applicable job titles listed by the Bureau of Labor Statistics's Occupational Employment Statistics [0] one chooses to apply, my salary is between 40% and 120% higher than the "average mean wage" (itself an inflated statistic) in my area.
This is true not just of myself but of all the good candidates I've hired. Good people don't work for average rates, especially not good people who are capable of doing remote work.
GitLab is doing itself a big disservice by targeting the "average" local wage.
There's a very important difference between: "SFO is very expensive so we have to pay people who live there more" and "we can pay people who don't live in SFO less"
I just checked the calculator for a major German city and I can say they won't be recruiting anybody away from the likes of Siemens. Rocket Internet maybe.
I love the Gitlab product and what they have done to Git hosting. But, their salary structure is really screwed up.
Also, I'm a little surprised by the anti-GitLab sentiment on this thread. I thought the consensus was that they had bad luck but didn't do anything particularly more wrong than anyone else? (I may have missed some more analysis of the cause of the failure.)
This is almost completely on their admin staff, maybe other people aren't willing to say it, but I will. Test your backups. Or at least make sure they're non-zero in size. It should really be Operations 101.
Whether you do this automatically or manually by setting a reminder on your calendar once a week or even month, doesn't matter. Something this simple would have solved their entire issue. I do this and we run a much smaller shop than GitLab. Heck, if we were larger I'd have hot spare database servers in another datacenter in case the primary got nuked by disk failure, network outages or mistakes.
"Automated failover can be achieved with pacemaker alongside STONITH network management. Keep in mind that application servers need to be prepared for transitioning to the new network addresses.
In this situation you can also opt to synchronize the database via a database specific protocol instead of DRBD. In the documentation for each database you can find out more about the options for MySQL and the options for PostgreSQL." https://about.gitlab.com/high-availability/#filesystem-stora...
I'm just genuinely unsure what a better outcome would have been here. (It's certainly a process failure that no backups existed other than the manual 6-hour-old snapshot, but I'm not sure you can do much better than automating that.)
That's what lead to the problem. We were trying to fix it, but ran the wrong procedure on the primary instead of the secondary
Thus wiping the primary, instead of what might have been left on the secondary.
The secondary was already removed at that point.
Basically the procedure was the following:
1. Secondary falls behind too much, stops replicating. At this point you need to manually re-sync the whole thing
2. A re-sync requires an empty PostgreSQL data directory, so this data was removed
3. Re-sync doesn't work, leading to the other problems
4. At some point team-member-1 thought previous re-sync attempts left data behind, so team-member-1 wiped the data directory again to be sure; except team-member-1 ran this on db1.cluster.gitlab.com (the primary) instead of db2.cluster.gitlab.com (the secondary)
> So in other words, out of 5 backup/replication techniques deployed none are working reliably or set up in the first place.
It's not true that having zero tested working backup/restore strategies happens to everyone. It's a catastrophic failure in process. Let's not blame any specific engineers, but it seems totally appropriate to blame the CEO (who was the subject of the puff piece!) and decrease your trust in the company appropriately.
Maybe being fully remote helps to let stuff like this "slip through the cracks". (Not great phrasing, but I don't think anyone made a conscious decision "loosing X hours of data is ok", and nobody questioned what goal the current practices could (not) achieve.) I don't know, but it seems at least a question one might ask.
(Or are we just saying that they should have been taking backups every 15 minutes or hour or so?)
Anyone with more experience with large databases have anything to add or any concerns with this sort of scheme?
More frequent backups would of course help, if their impact is tolerable. They also need to be tested to actually exist and work.
At least LVM snapshots apparently are cheap enough that they can be done out-of-schedule just to get slightly newer data to staging, so they likely could have been done more often (but they probably weren't thought of as backups, which is why 24 hours seemed enough and nobody had a prepared plan to get back to production from them).
Similarly, Azure-side snapshots are mentioned as not enabled for the database hosts. Maybe that's not viable to do (they had performance issues with Azure, and I don't know how much overhead they case), maybe just something they forgot to set up.
Others have asked "why is there only one replica", which also seems like a good question (but my experience with database replication is close to non-existent, and maybe the higher load of more replicas would have caused other issues. Don't know.).
My point is more that I don't have the impression that the 24 hours are a figure that they arrived on by evaluating what "service level" they could achieve, but more a result of someone at some point setting up a backup with some interval. I don't think 24 hours is a figure where they can say "that's the best we currently can achieve", or even "that's what we planned for", but "that's what we have because that's what we have and nobody has paid closer attention". There is at the very least a cultural angle to it, which is why how they work could be relevant.
In the event of accidental deletion, the most recent snapshot will be restored and the transactions up to a certain timestamp will be replayed on top of it. If done correctly, this can prevent all but a few minutes of data loss.
AWS Aurora (and possibly other database-as-a-service providers) has this functionality built-in.
Then as someone else mentioned you can stream your replication log to storage elsewhere giving you the ability to do point in time restores.
If you look up the doc, they have like 6 different places where they looked for backups and each point is like "We should have these backups, checking for them now... woops, it hasn't been working."
The only reason GitLab's data loss wasn't even more disastrous is that an employee just so happened to take a manual snapshot 6 hours before the incident occurred.
Now, I'm sure we've all been in situations like that. I don't think it necessarily reflects on the individual technical employees of GitLab. I think it says more about the organizational and management resources at the top. It was their job to ensure that the appropriate resources were committed to data integrity, and they failed to do so.
90% of us probably work at places with similar problems, but publishing "the secret to [managing technical employees]" fresh on the heels of such a spectacular organizational failure is probably unwise.
writing things down is not the problem... failing to read the things they write down is the problem. they probably don't have time to read, because they are too busy always writing. they can't find what they need to read in the sea of endless wasteful and pointless drivel that never should have been written down in the first place. you're all idiots.
How is their remote working practices at all related to the database disaster?
For that matter, how are either of those related to source control and rebuilding from old source? What would rebuilding source help with when you just deleted your production DB?
This post is now fodder that can be used against me the next time I advocate for remote work at a company.
Edit: it took 10 minutes for two people to pipe up on Twitter, one specifically suggesting remote work made the ops failure more likely:
As a remote worker myself, I'm always keen to hear about how teams make it work. I'm also a huge advocate for distributed teams (and nobody having a commute), so personally I'm really glad this link was shared today.
Transparency is fine. Eventually moving on is fine. But right now people are interested only in one topic when it comes to Gitlab.
Good grief.
Also, nice cameo by the office cat.
The core message (mixed with my own takeaway) was that you have to consider all of your offices, even HQ, more like just another field office or coworking site--no location is "central" compared to others. As long as you consider accommodating remote people to be a separate task, it's a task that can be deprioritized. Ideally, anyone in your office should be able to work remotely at moment's notice with little-to-no change in procedure.
Much of his presentation was outlining concrete techniques towards making this actually doable. He still has the slide deck online.
http://oduinn.com/blog/2014/11/09/we-are-all-remoties-nov201...
In practice, of course, real life was imperfect and there's no question that you take a productivity hit over people in the same room. But if you do want a heavily location-agnostic organization as a core value, his take is a nice start.
I always tell people on my team that if it isn't written down, it doesn't exist. When you get into the habit (and learn how to manage all that information) it really saves your bacon.
The other thing that would have saved them from the backup drama was learning how to document and date your to-do list. Suddenly someone notices that you've had a test process for backups on the to-do for over a year and they bring it up at the next meeting.
And another thing: in team meetings, people can write their own meeting notes so everyone becomes responsible for documenting their responsibilities and what affects them. It's easier to do this remote than at a stand-up, because you're already at your keyboard.
Furthermore, I won't be surprised if they have seen more concentrated spam attack, after the news of this data loss surfaced.
This blog post mentions a whole bunch of issues that are being worked on, this list can also be found at https://gitlab.com/gitlab-com/www-gitlab-com/issues/1108.
> Furthermore, I won't be surprised if they have seen more concentrated spam attack, after the news of this data loss surfaced.
Not yet. Since Akismet has been enabled for snippets it seems the amount of spam is gone, or at least not noticeable.
We usually tend to add every single bit of information that we attain to our handbook[0].
Other than that, we try to over-communicate over issues, slack and email.
That is the backlash, don't say you've figured out the secret then make a near catastrophic mistake.
Nah... no thank you. I think I will get my management advice from a company that is not totally broken. I don't care how transparent you are, or how remote-worker friendly you are, if you can't do the basics right. You are in the data storage business! Shut down the company and refund the money to the investors.
Then rm -rf the paper....
Unless there are 2x a year restore tests, I personally assume a 60% backup fail rate.
Downtime happens to pretty much every service out there. In this case the company was incredibly forthright and so we can make fun of their stupid mistakes, but really most mistakes are stupid when you look at them -- when you make thousands of decisions a day, some of them will seem silly in hindsight. We just never learn about most of them.
It's difficult and expensive to build and maintain a solid system, and even if you want to, time and financial pressures often just don't let you, on top of the issue of just communicating the need for solid engineering, as it usually only becomes apparent when the problems start occurring.
I had a customer once in the 90s take a 30 hour outage that cost them nearly $6M in fines because some asshole put a budget freeze on anything related to cleaning, including tape drive cleaner carts. The dopey ops guy kept using one tape on multiple drives, making them do nothing.
I could personally rattle off a dozen stories like this at late stage startups, Fortune 10 and .gov.
The only reason many businesses are alive is luck and reliable SAN.
However, the interview seems to suggest that "write everything down" is the way to solve this problem and was what allowed for all their growth and success. So the solid process they have built is to write everything down, which they obviously didn't do or they wouldn't have had a 7 layer disaster recovery failure.
I agree... but I guess I read that coming from the perspective of someone who isn't a super fan of distributed teams. Many teams think that futzing around in slack or hangouts is enough. "Writing things down" is practically discovering the wheel to some places!
First, no one has the discipline to write much of anything down.
It's a very boring process and it's always going to be low-resolution. Your most meticulous documentation writers will get fired for failing to get their "real work" done. If you personally recognize the value of the documentation they furnish and thus refuse to fire them, all of their peers will feel that they are dead weight, which is still a ticket out of the company.
Second, after all that work, no has the discipline to read much of anything that you've written!
They skim. They glance. They Ctrl+F. They don't read. When you're in a pickle and you can pick out a life-saving bit of documentation, it's amazing, but that happens quite rarely and requires a lot of energy.
How many times have you pulled up docs, tried to follow them, gotten a really confusing error that you spent hours trying to troubleshoot only to find out that there's a one-sentence explanation tucked away in the third sentence of the fourth paragraph on the page you originally pulled up? This just happened to me _last week_, and frequently the most frustrating problems are small things like that.
People don't read. It's nothing personal, they just don't read. It takes a lot of cognitive energy. People are biologically programmed to conserve as much as energy as possible. Good programmers are both lazy and dumb!
If you want documentation that means something, it needs to be part of the process of actually working. I don't mean you need to add "write docs" to your checklist, I mean meeting the operational standards should be the only way things can get done in the first place.
The operating procedure needs to be married to the actual completion of the task, and that means setting good baseline project standards and setting reliable enforcement on those standards.
Code should be self-documenting to a reasonable extent. Tests should be mandatory. Peer reviews and signoffs should be mandatory. Internal company discussions should be recorded and referenceable. Documentation only works when it's self-generating.
In short, it should be run like a mature open-source project with an open IRC channel, mailing list, bug tracker, commit history, mandatory tests, maintainer signoffs, merge processes, code and style standards, docstrings and good automated documentation generators, and so on.
There is an easy solution to dealing with people who refuse to read things. (Hint: It doesn't involve recording hours of meetings.) You need standard operating procedures to document what people do at an appropriate level of detail. Period.
Operational procedure is different than code documentation.
The goal is to marry the SOP and the actual completion of the task, to block off the shortcuts and require a minimum expenditure from external discipline/motivation reserves to get people to follow those SOPs.
This is why it's baked into the company culture. It's very common for someone to ask where something is in the handbook or if an issue has been created for something.
> It's a very boring process and it's always going to be low-resolution. Your most meticulous documentation writers will get fired for failing to get their "real work" done. If you personally recognize the value of the documentation they furnish and thus refuse to fire them, all of their peers will feel that they are dead weight, which is still a ticket out of the company.
Fwiw, everyone is responsible for maintaining the handbook/our process and procedure documentation. The docs team isn't on the hook for it, nor is it the sole responsibility of engineering.
> Second, after all that work, no has the discipline to read much of anything that you've written!
After enough reminders, you'd be amazed at how quickly people learn to RTFM at work.
> They skim. They glance. They Ctrl+F. They don't read. When you're in a pickle and you can pick out a life-saving bit of documentation, it's amazing, but that happens quite rarely and requires a lot of energy.
It's true that people skim the handbook (the guide with all of the "Here's how you get access to Twitter accounts" stuff), but runbooks are actually looked at when stuff hits the fan. I think it's important to differentiate these two things since they have different purposes. Imo runbooks should be as lean as possible for that very reason.
> Good programmers are both lazy and dumb!
This level of documentation is helpful for non-developers who make up a significant part of many organizations. We're not just talking about documenting code here.
> If you want documentation that means something, it needs to be part of the process of actually working.
100%, this is the only way it works.
I find that in practice, with non-mission-critical activities, especially documentation, when everyone is responsible for getting it done (And making it useful), no-one is.
7 layers of backup processes, that they had written down, all failed and went unchecked, by any of their employees across the 160 locations.