Reflection: The second half of my sixth year at GitLab

Hard to believe it’s been 6 years, and I certainly didn’t imagine working outside of Product and Engineering at any point until it happened. Check out the last reflection post if you’re wondering what happened in the first half of the sixth year, namely how I wrapped up my work in Support, and moved to the Chief of Staff to CEO Team, now called the Office of the CEO (OCEO).

What my work looks like now

When I worked in Support, we often talked about how the majority of what we did was “reactive” (as a reaction to some situation), though we strove to be proactive whenever possible. In many ways, being in the OCEO is similar, except that we tend to be reacting to larger things, and on a longer term.

In general, the team does whatever our CEO, and our Chief of Staff (CoS) to CEO, need. There’s some stuff that we regularly work on, such as OKRs and quarterly updates, but we spend the majority of our time on “projects”. The Directors on the team do a lot of program management work on initiatives that our CEO identifies as needing additional resourcing from our team. I also usually describe their project work as “revenue impacting”.

At the Staff level, I tend to take on more internal facing projects, and support our CoS. I sometimes half-jokingly say that I’m the Chief of Staff to our CoS. While I occasionally do work for our CEO, most of the work I do is to support our CoS, and the things she identifies as needing additional resources. I also provide some support to the other OCEO team members.

Summit

When I started the new role, I was told that my number one priority was to take over organizing the Unconference portion of our Summit (our company in-person gathering). The closer we got to the event, the more I ended up involved in it. The last few weeks leading up to Summit, it took over my work life.

Unconference

The unconference was the largest part of what I had to do. The person I took it over from had create a project for people to submit sessions by creating issues, but much still needed to be done. Aside from trying to get us to 300 sessions (ultimately, it was 254 not including volunteering and code challenge collaboration drop-in), I needed to organize them.

I ended up adding a “triage bot” using the triage gem to make sure issues were labelled properly, someone was assigned, and to help post notices on the issues.

I also had to flag for and get various people to review certain proposals depending on the topic: Health & Safety, DIB, People Group, and Legal.

Of course, later on, I had to schedule them. Unfortunately, there were a few hiccups, like there being very little time between when people were notified of when they would be unavailable (on their excursion) and my having to create the initial version of the schedule. A lot of change ensued. There was also confusion about the schedule because the sessions were loaded into the event app we had, but last minute changes didn’t make it into it, and were only on the spreadsheet.

With the size that we are (the company is over 2000 now), we most likely need sessions to be finalized sooner and be part of registration, so that rooms can be better allotted. I had to do my best to guess at how many people might show up for any given session, and it just didn’t always work out.

Despite the issues, overall, I think it was a success, and I heard a lot of great things about the sessions.

Product section/stage gatherings

Since there was nothing on the official schedule, I put in a bunch of work to get permission to organize Product Section/Stage gatherings.

Basically, there were a bunch of sessions where people would be together with their division/department. However, a lot of the work in Product and Engineering revolves around specific parts of the product (which we categorize by Section > Stage > Group). So, I wanted to make sure that there was an opportunity for people within a Section or Stage (depending on the size) to get together.

I had the relevant product and engineering managers decide on what they wanted to do based on the guidance I gave them. So my focus was on getting the information I needed to put them into the schedule and rooms that were available.

I also took the opportunity to meet the Auth group team members that I had been working with when I was in Support. I heard from others that they appreciated having the time set aside for these get togethers, so I consider them a success.

And so many other things

I ended up involved in a bunch of other things relating to Summit:

1. Answering questions and managing the main Slack channel, and updating info doc (which was very time consuming to say the least).
2. Engineering posters session: I took this over close to Summit, where I had to gather the posters, liaise with the printer, get the invoice paid, make sure the room would be set up the way we needed, and that sort of thing.
3. Assist with Code Challenge planning and logistics, and communicating with the engineers during the event.
4. Volunteer. I did a shift as a wayfinder.

It was really tiring, but it was great to finally meet so many people that I’ve been working with over the years. To provide a comparison, the last time we had a Summit (equivalent), there were about 50 people at the Support team gathering. Now, the Support team is over 150 people. And there are a ton of people outside of Support whom I hadn’t met. We estimate that 10% or less had been to a Summit prior to the latest one.

Handbook

The main thing I’ve been working on, aside from Summit, these last few months is our handbook. As of the end of January, no one really owned the handbook, so after discussing it with my manager, I took over. However, I was not familiar with the tech stack, nor do I really know Golang or Hugo, so how much I could do on the technical side was limited.

In the short term, the main thing was to keep things running. I asked for volunteers and established the “Keep main green” group as part of the escalation path (internal).

Then, I created a maintenance and maintainership epic to identify and start working on the issues that we really needed done. In particular, we needed to get the handbook to a fast, stable state.

When I took over the handbook, it was unfortunately not in a great state. The two main issues were:

1. “Brittleness”: many pages are built using YML files stored in the older www-gitlab-com repository’s data folder, and often changes to them would break the handbook build.
2. Slowness: the main reason (as I understand it) we moved to Hugo is how fast it can build a large site, but our pipelines were consistently taking more than 10 minutes.

Thankfully, in May, Darby Frey (one of the backend engineers in Incubation) managed to get 3 weeks to work full-time on the handbook. He managed to take care of the most critical issues. We had a few other people contribute a bunch of improvements and fixes too.

I also decided to focus on the handbook in those weeks doing what I could. I worked on getting things into a consistent state, triaging, and getting our linters in order. In particular:

1. Implement the vale linter and add relevant rules
2. Update markdownlint rules to be mostly consistent with product documentation, and removing the exclusions (and for the internal handbook) which involved fixing 12900+ errors
3. Update our Codeowners guidance (internal)
4. Add triage guidelines and a triage bot
5. Reorganize and update our content writing guides.

We’re still working on some of the leftover issues, but it’s in a much better state now. We can even start considering monthly maintenance tasks. It’s also close to the point where we could conceivably have another team take over.

Everything else

Of course, there are other projects, work that happens regularly, and work to support others.

Small projects

I don’t know that you’d call these “projects”, but they’re fairly discreet things that I worked on:

1. CEO shadow content review pre-relaunch: The CEO shadow program was on-hold for a time, so I reviewed a lot of the content ahead of the program restarting. I also did the first “teach” week to help guide the first (full 2-week rotation) shadow.
2. Move Group Conversations to be asynchronous: With help from one of our EBAs, and our CoS, we moved our Group Conversations to be async, and from a Google doc to GitLab issues.
3. TeamOps wrap-up: Since it was previously owned by our team, I met with the new owner (Education Services) and worked with them to wrap-up any outstanding items and fully transition things to them.
4. SaaS wording update: SaaS was often misused to mean “GitLab.com”, our multi-tenanted SaaS offering, so the team worked on getting it updated across the company, where in some cases, we made sure the relevant teams were aware and had issues open to address it.

That’s not an exhaustive list, though that’s most of them.

Regular work

Some things happen regularly, which I help with, namely Company OKRs. Our CoS leads the process, and I mostly support her with:

1. entering them into GitLab,
2. flagging things for review,
3. helping to update our handbook if the process changes, and
4. getting and compiling updates.

There are other things like helping with the production of the Quarterly Kickoff and Assembly video, which mostly (for me) includes helping with prepping slides, attending recording sessions, and reviewing the recordings.

As with almost any position, there are also things like doing interviews for positions we’re hiring.

Support others in their work

Often I’ll work on smaller tasks that needs to be done for the team, or provide support to others both within and outside of the OCEO team. It’s a mix of things people specifically ask me to do, and things that I volunteer for based on my expertise and interests.

1. Acting Chief of Staff to CTO (sort of): basically, provide some projects support to our CTO for a few weeks.
2. Help one of the OCEO Directors with moving a GitLab.com compliance initiative along.
3. Help rename the Chief of Staff Team to OCEO.
4. Assist with Accessibility Report (VPAT/WCAG) by evaluating whether some of the existing WCAG issues are resolved (internal).

Again, not an exhaustive list, but they’re the more notable ones from the last few months.

I also continue to mentor some folks, be an onboarding buddy (which included our VP of Support), and review and provide feedback on promotion documents. Outside of GitLab, I’m still participating in the Aspire mentorship program as well.

Other happenings

There’s a bit less than usual in terms of the work I’d have done in 7 months, but part of that was the fact that I took a more significant vacation. My partner and I finally went to Japan, specifically the Osaka, Kobe, Kyoto area. We also spent a couple of weeks in the Netherlands, though I did work a few days while we were there.

Between the two personal trips, I was glad I got the chance to attend Code4lib BC, which was the first in-person one since 2019. At C4LBC, I presented a version of my ‘public handbook builds trust’ talk.

What it’s like

Many people have asked me what it’s like working in the OCEO, especially compared to being in Support and Engineering.

The OCEO is a much smaller team (less than 10, compared to over 150 in Support), and because we work on different things, we don’t meet with the same regularity. In Support, I was in a video call with other Support team people typically once or twice a day. That made sense, because we were working on more or less the same things. In comparison though, currently, I’m in a meeting with the OCEO team members typically once a week. It’s nice not having quite so many meetings, though I sometimes miss the extensiveness and level of collaboration that is inherent to doing Support work.

I spent years building an understanding of how certain parts of the product work, and it feels like that’s now being wasted a bit. At least I can still keep up some of my technical skills, especially with the handbook work I’ve been doing lately.

Naturally, working in the OCEO means that I end up working with a lot of departments that I didn’t necessary work with before, and often with senior leaders in the company. Communicating with senior leaders can be and is typically very different, so I appreciate the opportunity, experience, and particularly the guidance my manager provides in learning to do so effectively. Having the opportunity to learn (more often) from those above the Staff/Manager level was one of the reasons I wanted to move to my current position, and it certainly hasn’t disappointed in that regards.

At this point, I’m still not sure whether I want to stay in this sort of role long term. I feel like I can still learn so much more that, for now, I’m not really worried about it.

Until next time

Thanks for reading to the end! Look forward to the next one.