~ 8 min read

🪞 Reflecting on a fifth year at GitLab

Written by Brie Carranza

A look back at my fifth year at GitLab

Hello, world!

Welcome to the fifth installment in this series! My name is Brie; I started working at GitLab in May 2020. Each year, I take a moment to record my reflections on the last twelve months spent working on the GitLab Support team. You don’t have to read through the back catalog before reading this post but you can if you are so inclined:

✍️ Notes on the fifth year

One of the coolest things from this year was the Async Staff Support Engineer AMA — available as a very nicely edited YouTube playlist. It was very insightful to hear from my three fellow Staff SEs at the time and I am very glad we have those videos to reflect on as time goes by. In 2022, I was one of the people asking questions of Staff SEs so this feels like a “things coming full circle” moment.

As I thought about what I wanted to write about in this post, I found my notes full of questions. I think that’s because part of my style is asking the right questions to help unblock people or situations in order to keep things moving in the right direction.

  • Do we have enough information to make this decision?
    • What are the consequences of being wrong?
    • What are the consequences of waiting?
    • What additional information do we need?

There are often many possible paths forward. In order to determine the next steps, one should determine:

  • What should we prioritize?

In some settings, asking and answering this question requires one to accept that more problems exist than can be addressed.

When I plan what I’ll do during a given day or week, you can tell that I’ve been trying to think about:

  • As an organization, what is our current strategy?
  • As an IC and as a leader, what am I doing to execute that strategy?

I didn’t exclusively write down questions as I prepared to write this blog post.

🐾 Providing helpful next steps

When I’m helping a colleague to help them move a ticket forward, these are some of the things I am usually thinking about:

  • making sure the next steps are clear
  • providing multiple possible paths forward (when appropriate)
    • In some situations, it’s most helpful to propose multiple paths forward. This can happen when there are many critical pieces of information that are missing.
  • making sure the “why” is clear
    • Explaining why helps both parties. Explaining why requires me to show my work. This is useful for identifying flawed approaches and ensures that the person I am helping can solve similar problems in the future.
    • This also involves being clear about how sure I am about my suggestion. I often like to use “confidence levels” when providing multiple paths forward. (This borrows from the notion of credence in statistics.)
  • explaining what to watch for to verify whether the theory has been confirmed or refuted

🤔 “It depends”

One of the jokes about Staff+ engineers is that if you ask them a question, the answer is “it depends”. While this is fair, I found myself making a point to tell people what it depends on (and why).

🖼️ LNO Framework

I have learned a lot about product management during my time at GitLab. As part of my work on GitLab Detective, I have found myself putting these lessons into practice. A good friend of mine who is a PM shared one of my favorite things from this last year. One of the reasons I love it is that it’s very applicable outside of product management. The LNO Framework proposes breaking tasks into three categories:

  • leverage
  • neutral
  • overhead

While the specific tasks that a PM considers to be leverage differ, I’ve sometimes found it helpful to think about how my work is split between these three categories. My goal is to do as much as I can in the leverage category while I reduce and automate as much of what’s in the overhead category as I can. Read The LNO Framework Explained by Shreyas Doshi to learn more.

🌟 Five Favorite GitLab Features

After five years, I have spent a lot of time using GitLab for a variety of purposes and helping others to do the same. I thought a section describing my favorite GitLab features would be fitting.

🔑 .keys

Added in v6.6.0 is the ability to retrieve the public SSH keys for a user via a URL like:

Authentication is not required for this URL. This is super useful for granting someone SSH access to a particular host.

🆕 Create a new project with git push

This one is pretty straight-forward but it’s one of those small conveniences that make a big difference: create a project with git push.

asciicast

The newly created project is private. If you know me, you know I like to minimize the need to move my hands from my keyboard to my mouse. This feature helps me in pursuit of that goal.

🧭 Built-In GraphQL Client

Having GraphiQL built right into GitLab makes exploring the GraphQL API extremely convenient.

While my interest in GraphQL has been nurtured by my time working at GitLab, I have become curious about all things GraphQL. I sporadically maintain a collection of GraphQL notes and code snippets. If you’re similarly curious, I recommend following Benjie and reading through the notes from the GraphQL Working Group.

🎌 Crosslinking

If I had to pick a favorite, it might actually be crosslinking — especially given how useful it is with the GitLab-specific references that GitLab Flavored Markdown (GLFM) supports.

I’d recommend using the docs and real-world examples for a better understanding of the feature if you are not already familiar. The 2016 Tutorial: It’s all connected in GitLab blog post has a few examples, too. This is definitely a feature that I’ve grown to appreciate more over time.

GitLab provides a keyboard shortcut for copying issue references. If you are willing to use your mouse, you can use this bookmarklet to get issue or MR references.

👍 Filtering issues by emoji reaction

When looking through a project’s issues, I can filter the results to only show issues where I have reacted with a specific emoji. I love this feature as a clever usage of emoji that one can build an organizational system with.

🦊 Values

In the first reflection post, I wrote about each of the GitLab values and chose a particular operating principle (they were called subvalues at the time) to highlight. I have wanted to repeat that exercise and this feels like the right year to do it.

🤝 Collaboration

See others succeed

In order to be maximally effective, this operating principle does not describe an exclusively passive concept. I think about this as setting people up to succeed. One interesting way to think about applying this is effective delegation.

📈 Results for Customers

Embrace tenacity

This is the operating principle I cite the most during difficult situations. Sometimes things do not go as expected. I am reminded of “embrace tenacity” when difficult things are required in order to get the job done.

⏱️ Efficiency

Embrace change

Embracing change involves advocating effectively so that the inevitable change is successful. I sometimes refer to this as “effective complaining”.

🌐 Diversity, Inclusion and Belonging

Bias towards asynchronous communication

Take excellent notes when you move an asynchronous conversation to a sync. Are there clear action items related to the reason why the meeting was held?

👣 Iteration

Make a proposal

I am a proponent of clear problem statements. Making and supporting a good proposal usually helps to clarify the problem statement while also moving the conversation forward into problem-solving mode.

👁️ Transparency

Findability

Writing something down or updating a process is good but it’s just the start.

  • Is it written somewhere that people will look when they need it?
  • Can people understand what’s written when they find it?

🔭 A Look Ahead

As I think about the year ahead, there are two things that I can be sure of (because they are true every year):

  • There will be lots of change.
  • When I reflect, I’ll think “wow, what a difficult but rewarding year”.

The fun and adventure comes in figuring out which specific things will change and in learning what particular experiences are tough but ultimately worthwile.

💖 From the Heart

During this most recent year at GitLab, I completed my interim period as manager and resumed my role as a Staff Support Engineer. While this represents a successful period in my career that I am very proud of, all of the change that such a transition represents is the chief source of this year’s “difficult but rewarding” feeling.

This post was written entirely by me. My spelling and grammar check stacks do not currently involve LLMs.