3 things I learned in my first month at GitLab

Emily von Hoffmann ·
Nov 2, 2016 · 3 min read

I rang in my first month at GitLab in spectacular fashion, by meeting up with team members for our NYC World Tour stop. The only real surprise in meeting team members in person — after weeks of daily Hangouts — is height (hopefully by force of my personality, several people remarked they thought I’d be taller.) Here are some other big takeaways from my time here so far.

MVC applies even to marketers

The product team at GitLab lives and breathes the principle of “Minimum Viable Change” (MVC). This meant nothing to me in my day-to-day as a writer and marketer, until I joined GitLab and got an engineer as my team lead. We don’t apply the exact same language and principles to our content projects, but I believe that the spirit of MVC still informs our work. For example, our team lead Sean explained his simple test for reviewing our merge requests — he asks himself, “is this better than what was here before?” If the answer is ‘yes’, it gets approved. We now operate with the attitude that it’s better to jump in and do the work, than ask for approval, which not only makes us faster but increases our sense of agency over projects. We don’t need to establish consensus among innumerable team members before making a documentation or handbook update live on the site; if someone thinks of an improvement, they create a subsequent merge request, and the same rule applies. This feels like a radical way for a team of writers to work, but so far it’s all upside.

Feedback flows thick and fast

Because we work remotely and with relentless transparency, it occasionally happens that an issue thought to be uncontroversial develops an accordion-like comment section. We have team members in 34 countries, with a vast range of first languages, professional backgrounds, and experience levels, but the same intense drive to make GitLab better every day. I quickly learned to never read into perceived “tone” online, because nearly 100 percent of the time, questions are asked in earnest by team members and users who want to be sure they understand. By the time I experienced this, Sytse our CEO had armed me with a mantra for just such an occasion, and I repeat it to myself with abandon: “If you’re getting feedback you’re doing it right…if you’re getting feedback you’re doing it right…if you’re getting feedback you’re doing it right.” As a new employee, this also empowers me to chime in with my own questions, and I trust that my team members will always let me know how I’m doing.

Intimidation is your only enemy

The first (open) secret I learned during my time here is that learning Git basics is pretty easy. Checking out a new branch, tracking a file, committing changes, pulling from and pushing to the origin – these are the only functions I needed to master to do routine marketing tasks, and they became no problem after a day or two. Every non-technical person at GitLab could likely write a similar story about trepidation and triumph, because we have to successfully apply these commands to complete our onboarding process. I haven’t since experienced the level of apprehension I felt when I opened up the terminal on my first day; the same applies to when I created my first issue and puzzled through the norms of our workflow. It’s also really true that gamifying anything is an awesome way to learn (my favorite right now is ShortcutFoo.) This is not to disrespect the amazing work the developers on our team do; myself and another team member are starting to learn Ruby, and I’m sure I’ll have complicated feelings to report on that later.

Until then, git at us on Twitter, check out our job openings, or add to our issue tracker.

Edit this page View source