Subscribe
Search

Reflecting on the first 6 months working at GitLab


GitLab all-remote

Table of contents:

I am joining GitLab, the world where everyone can contribute to live six core values (also known as CREDIT). 🎉

Being through various roles in the recent years, with all the broad experience gained, I am pretty sure about this choice and without doubts truly believe in the success of the company. I am joining the Professional Services Team to help our clients deliver the best products using GitLab’s DevOps platform. Reducing time to market by accelerating the adoption of modern software delivery methods is our (and, of course, mine) main priority.

Thoughts to write my observations on the first few working months came to my mind on the day I joined (back in Oct, 3 2022) when I was travelling to Rotterdam to meet my fellow colleagues. We had couple of other joiners on that day, I met my manager, as well as PS Director (who hired me) flew over from the US to meet us in person and welcome, and we all admitted that it was quite unusual to meet all together (in #all-remote environment) on day one! 😜 Being inspired by fellow colleague Michael Friedrich in this article I’d like to reflect on recent weeks being part of the GitLab Professional Services Team, touch on my onboarding experience and eventually talk a little bit about the things I do. Here is the view from the window on my first working week #all-remote! 🤙

Hiring process #

Previous years I’ve been in consultancy, working on super broad set of things (from building and implementing Azure Landing Zones to refining SDLC processes, embedding security etc) and were looking to narrow that down to certain area of interest and become subject matter expert, sort of “the guy to go to”, to get things done. I was not sure either to stay in the Architecture role or shifting towards Engineering with a way more hands on or rather revert back to Solution or System Architecture / Engineering with a bit of business touch. What I knew for sure is that DevOps and Application security resonates with me, I’ve been involved in several projects of different size and maturity so far and was quite comfortable and interested in pursuing it further. I had a huge storm in my mind going back and forth (that was also quadrupled due to political issues in my home country, invasion and lack of abilities to see relatives), trying to figure out what exactly I wanted to do (i.e. going back and locking myself with vendor’s technology as how it was when my career started or not). On June 28th I submitted my application for the Sr. Professional Services Engineer role at GitLab. On the same day I got a phone call from Kelsey (who has been really helpful during the whole process) at ~ 8pm CET (CEST) while walking around the neighbourhood, it was really strong wind but we managed to talk about the role and the process.

Fast forward, I’ve successfully finished several interviews. One of them, the technical assignment, was to implement GitLab and GitLab Runners. So it’s a combination of IaC and configuration management. Initially I thought to pick Azure Bicep to roll out required infra in Azure, but then I switched to terraform since it is widely used in GitLab for self managed GitLab instance (which is basically one of my duties here in the role). I am still a big fan of Azure Bicep (take a look at this Azure Bicep Workshop) though. Long story short, I used GitLab SaaS with my personal account to exec terraform using GitLab CI (shared runners) with the code taken from the repo (no secrets were submitted to the repo though 😜) and provisioned couple of resources in Azure (i.e. VM, KeyVault) and leveraging null_resource provisioned GitLab with simple shell script. That was enough, also the technical assignment had time limitation so I chose shell script over Ansible or anything else. My work as well as documentation is still available here. I was doing my technical interview in Baden-Baden, Germany (don’t ask about itinerary) on the way to our trip to Greece. It was in a little cafe next to a gas station and from what I remember they had this wonderful music boxes:

Fast forward, a while later while visiting Greece’s Island Santorini 12 years after our marriage with my wife and children (we even managed to rent the same place where we were during our honeymoon back in 2010) I got a phone call with New York’s callerID saying that I’ll be offered Snr PSE position! Yay! That doubled my holiday emotion and made that trip unforgettable. I’ll definitely keep it associated with something really bright from the past! ❤️

Me having drink for the new job @ Perissa Beach 🎉 🍺 🥳

New job, getting drink

TaNewKi welcome call 🦊 #

Besides wonderful experience during all my interviews with People Operations, team members and hiring manager I got another interesting way to interact with future colleagues and feel what it is exactly to work at GitLab before my actual start - attendance of TaNewKi Welcome Call. It’s a pre-onboarding call that is hosted by People Operations. The call is open to all current team members, hiring managers. Super happy that I was able to make it in one of the offered day, met some folks joining on the same day as well as made some friends and outlined common interest (i.e. chess ♞). TaNewKi is a play on the abstract Tanuki i.e. Japanese raccoon dog you will find in GitLab’s logo. By the way, there is a little story behind the logo (the current logo has been in use since 7.13). Afaik there were two finalists of logo, the current one and this:

… just kidding, that vintage logo is from the times when branded login page became possible in GitLab Enterprise Edition (more info here), the new (current) logo looks awesome. Thanks to designer Ty Wilkins! 🚀

Onboarding issue #

On day one everyone gets access to the onboarding issue which contains ~ 200 tasks that have to be completed within the first month. That is a combination of getting to know the company better, provisioning access to various tools and services, finishing required courses and passing exams as well as getting to know your remote mates. GitLab uses the donut app that randomly links two co-workers to have virtual coffee. In the first month I’ve made around 10 new connections outside of my team (various roles, - talked to engineering and sales; legal and marketing). I’ve seen this initiative earlier, but I was surprised how seriously it is taken by team members. By the way, we typically do not call each other GitLabbers as it might confuse due to the fact that the company includes both the GitLab community and people who work at GitLab (like myself). There is a list of misused terms that might be useful to quickly scan. 😉

The onboarding experience was awesome, I was given an experienced buddy that helped me to navigate through the information (Slack, handbook, applications in Okta etc). Most of the mandatory activities were familiar (i.e. time sheets, PTO agreement, expenses etc). Since everything is in the handbook I started to read it before the actual join so I saved a little bit of time for later, for more complicated tasks.

At GitLab I also started to think a bit of context switching between work iterations. Previously with a similar way of working (especially during Corona time) when working from home became mandatory I used to run or cycle during lunch (having roughly 30 minutes exercise with a little sandwich or salad at the end was really helpful). At GitLab I added chess to the mix… (but it could be very addictive, be careful 🤣).

At the end of my first month at GitLab I was almost done with the onboarding issue (I was missing a couple of certificates), but that was done on purpose as I wanted to gradually learn things so they are not flushed on the next day. I completed them a week later (if I remember correctly). I’ve added certs to this post as well. And, eventually I was ready for the market (well, for GitLab’s market to start working on projects).

Certifications #

Over the past several years I’ve been doing mainly Microsoft certificates due to previous employers requirements / incentive programs. GitLab has several learning paths and offers several certificates. For me during onboarding the goal was to obtain a PSE certificate. This certificate has several prerequisites (a couple of associate certificates, specialisation and professional, as well as several workshops to be completed / checked as well as challenging knowledge checks). These are the certs that I’ve got from GitLab so far:

Full list of courses and certificates can be found here.

Handbook #

The GitLab team handbook is the central repository for how GitLab runs the company. At the time of writing this article it includes 2k+ pages, everyone can contribute via merge request (also known as “MR”). Handbook (also HB in some occasions further) is a large company’s knowledge base, source of truth and, I’m pretty sure, ChatGPT is gaining replies from it! 🤣 Even having assigned onboarding buddy I was able to cover most of my questions by looking into HB. Basically HB contains information on most everything (I can’t even think of anything lacking), to give some examples, - from history and publicly available OKRs to how to expense things, what equipment is best and ergonomic for full remote, how GitLab is being monitored (even broken down into details saying version of prometheus and DB config), what is the procedure to engage with professional services, cost of licence and so on so forth. It’s huge, it’s constantly changing (again everyone can contribute) and it became one of the major bookmarks especially for the first weeks. I’ve bumped into several pages with outdated information that fixed myself during the first days (with webIDE), it was a pretty cool experience to see how everyone can contribute and how much trust employer gives to its employees.

16 personalities #

We had mix sessions with a couple of other joiners in the first week. We talked about work related matters, but also learnt about ourselves, our types and personalities. I found myself Assertive Protagonist along with other teammates.

Protagonists (ENFJs) feel called to serve a greater purpose in life. Thoughtful and idealistic, these personality types strive to have a positive impact on other people and the world around them. They rarely shy away from an opportunity to do the right thing, even when doing so is far from easy.

Protagonists are born leaders, which explains why these personalities can be found among many notable politicians, coaches, and teachers. Their passion and charisma allow them to inspire others not just in their careers but in every arena of their lives, including their relationships. Few things bring Protagonists a deeper sense of joy and fulfillment than guiding friends and loved ones to grow into their best selves.

- Protagonist Personality

Me

People and collaboration #

GitLab is a really diverse and awesome environment. It is safe and it is the place where people respect each other, value the vote, transparent and super efficient. Here I first heard about asynchronous communication (well, I’ve heard about it previously, but never seen it in action). All the meetings are having proper agenda (if not then it should not be a meeting rather email or slack message); notes, there is no one assigned to make those notes, but due to the nature of company (everyone can contribute) anyone from the call (or outside of the call if it is concerned to that person) can make a note, add question (i.e. asynchronously that can be asked / answered during the actual meeting even if the person can’t attend). Calls are recorded for the benefits of those who were not able to attend or would like to listen again due to distractions or any other reasons.

Working with GitLab Issues on daily basis to manage self work or customer’s project helped to quickly figure out the set of features and … 🥁 … fall in love with it. I’d be honest, I was ignoring GitLab Issues previously, giving preference to some other tools, but that was a mistake due to lack of knowledge about its capabilities. If you are like me, don’t wait, give it a go (here is the link to GitLab Issues). This is basically what we call (well in the World) dogfooding. Believe it or not, but it helps very much on the projects even with tough engagements where someone on the other end could be a complete introvert. I love labels! Labels are awesome. If time permits I encourage you to take a look at the open issues and see how they can beautifully define scope of work, progress and overall ease to follow and understand what has to be done!

Family and Friends first #

Family and Friends at GitLab are the highest priority. Well I’d say this is common across most of the companies I’ve been working. But what I could not imagine is that there is one day per month GitLab allocates for Family and Friends. One. Full. Day. Go and meet your friends, play with your children, spend time with your partner etc.. Whatever suits you best and is possible to plan. That’s really awesome. The day is known in advance and can be well planned. With that said GitLab has publicly visible shutdown, virtual offices are closed and meetings are rescheduled. Again, as this is well written in the handbook and known to all the team members, it’s really easy to communicate and avoid surprises.

Other than that being and seeing how my son is growing is really awesome. My parents wouldn’t have such a privilege, I couldn’t imagine that either back 10-15 years ago when starting my career. That is completely different, life changer. Remote work is fun, especially when Family and Friends day permits to do some fun together:

Values #

GitLab’s six core values are 🤝 Collaboration, 📈 Results, ⏱️ Efficiency, 🌐 Diversity, Inclusion & Belonging, 👣 Iteration, and 👁️ Transparency, and together they spell the CREDIT we give each other by assuming good intent. The following emoji are being used widely within the org:

Collaboration Result Efficiency Diversity, Inclusion & Belonging Iteration Transparency

One of my favourite values here at GitLab is transparency. Previously I have never worked in such organisations where everything was public by default and I found it really useful, this helps to get clear way of working and direction of the organisation / organisation unit, helps others contribute from day one, prevents gossips, saves a lot of energy to find information and overall I like directness / blunt to the point (I am based in The Netherlands and I found this in every dutch person I am working with is super direct and blunt to the point, I guess the roots of directness / transparency is coming from our our CEO Sid Sijbrandij being dutch). Back in Feb, 9 2023 layoff at GitLab was announced and I’ll never forget how things were transparent and open during that time, including all further communications, reasons behind that action etc. No dual standards, everything according to its own rules and values in the roots.

The cool thing is that you start following and getting the idea underneath and it’s a real added value even before joining the org (the onboarding team starts to share whatever is useful before the first day). Some of my first steps during the onboarding was to provision information about myself in the team page and making my GitLab’s profile public what is, basically, inline with transparent core value (there is even my merge request for change in team’s page publicly available)! 🎉

The CEO #

I was following Sid Sijbrandij (there is a handbook page dedicated to GitLab’s CEO) for quite some time since I used GitLab. Sid along with co-founder Dmitriy started the company back in 2011, there is the first commit, so technically this is the birthday. There are a lot of videos available with Sid @ GitLab Unfiltered, there is one of those I like (lecture to students in Stanford) on how we work at GitLab (especially the Q&A part that covers some of the caveats). I think it’s just worth watching it to learn who the GitLab’s CEO is. Highly recommend it!


My duties #

Over the years GitLab evolved from a source code program transformed to DevOp platform. So basically, git stores source code; a backlog can be managed with Issues; with CI/CD build, test and deploy; with various features extend, customise and build its own way of working required to the org, on top of that integrate out of the box bunch various OSS tools that can help in engineering journey further (security scans, quality tests, performance etc..) and … eventually repeat everything all over again (iterate).

GitLab DevOps Platform

GitLab is written in Ruby on Rails (there is Why we’re sticking with Ruby on Rails). I worked a bit with ROR back in 2014 and was really impressed with its approachability and how easy things could be. The Internet even remembers this blog was written in php first (yes, yes!), moved to ROR at some point with some JS and eventually ended up in GitLab Pages (if interested, read about it here). Can’t wait to get your memes around this topic in the comments down below (how about this? :trolldance)… nah, just kidding.

GitLab offers its cloud version (or SaaS known as gitlab.com) where everyone can register and start working (there are also commercial tiers), there is dedicated GitLab (where GitLab’s engineers manage fully isolated single tenant of GitLab instance for the customer) and there is self-managed GitLab that can be installed and run by individual or organisation. While Omnibus might resonate with some of the readers this is not how the majority of GitLab customers operate self-managed GitLab. Example would be the following Reference architecture: up to 3,000 users of GitLab:

Reference architecture: up to 3,000 users

Long story short, while we maintain this full catalogue of PS services, I can be a dedicated engineer injected into the client’s team to fix some issues or help on GitLab adoption, automation or just do some ad hoc work. I can be an implementation engineer with a requirement to run GitLab on-prem or in the cloud. On kubernetes (instead of VMs) and / or with cloud native services (i.e. database tier, redis etc). Having infrastructure rolled out is not enough, there is networking involved, installation and configuration of GitLab application (components) as well as installation and configuration of various open source dependencies like PostgreSQL, haproxy for load balancing, redis, prometheus etc. At PS as well internally we use GET that simplifies roll out of IaC (via terraform) and with Ansible configure nodes and connect the dots. There is broader knowledge involved than just knowing GitLab and how each component works with each other. I can be a migration engineer moving backlog with users and commit history from GitHub (:trolldance) to GitLab or between GitLab’s (i.e. from onprem to SaaS). I can be a runner implementation engineer helping to build proper runner infrastructure and scale them based on org requirements. Or helping Engagement Managers to scope PS engagement.

Overall I’d say juggling multiple projects with various scope of work might be challenging, but it helps to advance my skills and pushes above boundaries helping me to stay competitive on the market as well. I think it’s a good combination and can be considered a win-win for both parties!

Am I happy and doing what makes sense to me? Yes, I am!

Plans for this year #

Resources #

Thank you for reading! 👋

comments powered by Disqus

Related Posts

Building GitLab demo - part 1

In these series I’d like to share my thoughts on building quick and approachable GitLab demo using as much as possible features and capabilities with less effort and keep cost slim as well. You …

Continue reading...
Static site with Hugo and Gitlab Pages

The intention of this post is to document the process of building this web site and outline some great resources I used along the journey. This is a static site based on Hugo and runs using GitLab …

Continue reading...
How to build and deploy to Azure with GitLab

In this short post you’ll find how to prepare your GitLab to deploy to Azure.

Service principal #

Generate Service Principal (aka App Registration) using azure CLI (either builtin shell or local …

Continue reading...