We were very pleased and surprised to see this article pop up (thanks, agilob!) as well as this one, this one, and this one that all arrived on the Hacker News front page in the space of about a weekend. There were also many kind comments left by users, which is always great to see. We’re excited to have a lot of loyal fans (many of whom are also contributors).
While there’s no magic formula for getting people to like you, we think that some of it has to do with the values embedded in your company culture. Your company culture not only defines how your organization works together but it also defines how your team interacts with the outside world. It dictates the underlying philosophies for how you treat employees, customers, partners, suppliers, etc. A great company culture can help you attract great talent and earn respect from your customers and partners. At GitLab, we take our culture very seriously and we are constantly working to maintain it as we grow.
This post outlines the principles that we think make it easier for people to become fans. Naturally, every company culture is unique so these are our thoughts on what works for us. We think there may be some learnings here for your company as well. We could also learn from your culture so please comment on this post with what works for your company or team.
In the past two years we’ve gone from a team of 10 people to a team of 90+, spread across 26 countries. As a remote-only company, there is a stronger need to document and broadly share our policies and procedures.
In this post we’re explaining the reasons why having an open source Handbook works for us, and how it can help you, whether you’re working at or running a company of your own.
We’re starting a series of posts that explore existing and growing trends in version control. This week we’re looking at innersourcing.
As a follow-up/update to a post we did on innersourcing back in 2014, we’ll be looking at what innersourcing is, who’s using it, and how it’s solving some of the biggest problems enterprise developers face.
We're often asked about what it's like to work at GitLab. Every GitLab team member answers this question a little differently. But there were some noticeable themes across each of their answers. We've highlighted some of those key themes that making working at GitLab great.
You might be aware that a fair percentage of the GitLab team are parents, and we all work remotely. Not only are we a remote-first company we recently affirmed our dedication by changing this declaring we are a "remote only" company. We believe that remote working is the way forward, when it’s done right.
In this post, we’re giving you a view into our experiences of remote working as parents—we even asked members of team to chime in with their thoughts. While there’s no “typical” day in the life of the GitLab employee, there were a lot of similarities in what people find great and challenging about remote working.
In this post, I'll give you an update of what we've sponsored recently as well as some insight into our priorities as we welcome more requests for sponsorship.
We’re so delighted with the interest in our tech diversity sponsorship program. Since we announced the program in early February, we've sponsored a number of great events.
Communicating clearly is important in almost every profession, but if you work remotely (or if you hope to integrate remote working into your company culture), it’s indispensable. In this post, we’re looking at how solid communication can be implemented—as in a set of rules, like we have here at Gitlab—and why you should think about doing just that.
In April 2015, we published the Remote Manifesto on our blog. There were 9 people in the company at that time, which means we've grown over 600% during that time, with 54 people on our team as I write this.
“Always start with an issue” says Job, VP of Product here at GitLab. Before you begin anything else, summarize your ideas in an issue and share it. It’s such a simple rule, but the impact is huge.
In this post we'll focus on issues for feature proposals specifically, but the rule applies in any case, no matter what kind of project you're working on. We say “start” with an issue and not “create” an issue, because one might already exist. Make sure to search in All issues (open and closed) to see if your idea has been proposed already.
Webcast soon! Find out more about making the most of GitLab to collaborate on your projects, join us for our GitLab Intro webcast on GitLab Workflow, Thursday March 10th.
2016 is the year of the Tanuki!
The last 12 months at GitLab have been amazing — we are super busy, growing fast, and making a difference to a lot of developers. We feel special, honored, thankful and hope you are ready for even more!
Here is a look back at 2015 graphically. We included some info on GitLab's mascot, the Tanuki, a raccoon-dog from Japan.
We've just created and published our Strategy document to make our choices clear as they relate to our strategic objectives.
Hi! I'm Jacob Schatz, Principal Front End Engineer at GitLab. When I started here at GitLab in December 2015, I felt like I’d joined the cool-kids club. I’d heard about the job on HackerNews, and thought, “I’ll apply for it and it would be awesome if I got it.” And I got the job!
It’s been a fantastic experience, and I’m glad to say we’re hiring more front end developers. We have a unique challenge here at GitLab, working in an “open kitchen” together. We must serve both a great front end user experience and a great developer experience.
If you’re curious about working at GitLab, read on.
Dear open source maintainers,
We want GitLab to be the best place for any software project, whether open source or not, whether big or small.
The letter of GitHub's open source community is clearly not addressed to us, but we're thinking a lot about the issues that were mentioned in it. We see many of these things happening and have been working on them for a long time, not in the least because we develop on a busy public issue tracker ourselves.
Here we would like to share our thoughts about these issues and what we’re planning to do to make things better with GitLab.
We've recently detailed our policy and commitment to open source. We need to think in the interests of the project, while tending to the realities of running a business to support it. I wanted to share some of our thoughts around the decisions behind the policy.
This time last year, from January until March 2015, GitLab participated in the winter 2015 batch of Y Combinator. We had an awesome time and want to thank the people at Y Combinator, our mentors Qasar and Kevin, the YC alumni and our fellow batch-mates.
I’ve just started working at GitLab, and I’m bowled over completely by the kindness and talent of the people I’m meeting. On my second day, I met with Dmitriy Zaporozhets, founder of the software project GitLab and co-founder of my company, GitLab, Inc. We spoke about the release date: it’s same day, each month, always. What is this madness? I wasn’t used to things being released ON TIME and deadlines not shifting. I discovered this monthly release date is at the heart of working at GitLab.
“At GitLab we believe you shouldn’t wait for something to be perfect: Release what you have and do it on a schedule,” said Dmitriy.
What began as an estimated 20 person trip for bonding between our remote employees turned into two weeks, four hotels, five last-minute passports, a 15 person Airbnb, 42 people, all the beer in the Netherlands and an infinite amount of mayonnaise-covered fries… and a partridge in a pear tree. Welcome to the GitLab 2015 Summit in Amsterdam.
Every month on the 22nd a new version of GitLab is released. It always includes major changes, with features, bug fixes and performance improvements. We haven't missed a single month since our inception.
We are completely remote, save for the Experience Center in San Francisco that not a single developer frequents (a 10,000km commute is a bit much for most). We do not have predefined teams and almost everyone works independently (i.e. without someone telling them what to do).
We do not practice any specific agile methodology, but meet the principles of the agile manifesto quite well.
This is a start in describing the workflow that we've established over the past year at GitLab, as it seems to work for us and might for you. It's lightweight and self organizing. It might or might not scale.
At GitLab, we do our best to work together with the rest of our amazing community at every possible occasion. The rest of the community contributes many features, fixes bugs and improves performance. To work together effectively, we try to be open about as many things as possible.
Today we're announcing a move from doing the majority of our development work internally, to almost exclusively working in public issue trackers on GitLab.com. This means that anyone can view and comment on all of our discussion and work. This includes bugs, new features, performance issues and everything else that relates to our products.
Real heroes are sometimes unknown and we can only see their accomplishments. In GitLab we have one invisible hero every month, when we have our monthly release. As you may know, we've never failed to release a new GitLab version on the 22nd of every month.
As GitLab grows, the release process becomes more complex and becoming a release manager is a more difficult, but a necessary job.
Eight working days before the next release, and we start the countdown. A new volunteer "hero" is elected by the team.
Some time ago, GitLab's CEO Sytse wrote The Remote Manifesto. It inspired me to write about it from an employee's perspective.
I started working with GitLab 2 months ago and it has been quite an interesting experience to work remotely with a team that's spread out in the world.
We all have been greatly helped by Scrum and the Agile manifesto. It freed us from waterfall planning and excessive process. But working remotely and continuous delivery need something more.
We at GitLab believe in providing a good service to all our users, be they customers, or non-paying users. In our attempt to support our users, we sometimes make mistakes.
In this post, I'll be discussing two instances where we at GitLab dropped the ball. I'll go through what went wrong and what we did to address our relationship with the affected party. Then I'll indicate how that affected our standing with that party. In the end, I'll mention the process we've followed to address our mistakes.
We have some big UI changes coming with the release of GitLab 7.7, on January 22nd. In this post, we'll show you why we're changing the user interface, how we did it and what we ended up with.
This is a series of blog articles about the process of me writing a book about GitLab. It will contain information about the process with the publisher, about the different state of minds I went through, and how it feels to actually finish this thing!
I started working at GitLab B.V. in October of this year, making this my third month with the company. Working here has been the best professional experience I've had so far, and I would like to share with you how I got here and how this time has affected my view on a lot of different subjects.
People are happy at GitLab. Happy people are more productive [1]. That’s not an easy feat to achieve and something we want to preserve as we grow. This is how we try to make people happy, it may serve as inspiration for your startup (and no more).
GitLab is a fully remote company, meaning that all of us (currently six) work 100% of our time from home or any other place in the world. We're not the first to do this, Wordpress does it on a much larger scale, but it might be nice for high-growth startups to see how we handle it. It doesn't require as much tools or effort as you might think.
Currently we're based in Ukraine (1), Serbia (1) and The Netherlands (4).
Every morning at 8:00 CET (note: you have to know your timezones working remotely) we have a morning meeting with the whole team. Nowadays we use vLine for this, as Google Hangouts was unreliable with more than four people.
