Learning (Lib)Tech

Wow, 3 years at GitLab. Since I left teaching, because almost all my jobs were contracts, I haven’t been anywhere for more than 2 years, so I find it interesting that my longest term is not only post-librarian-positions, but at a startup!

Year 3 was full on pandemic year and it was a busy one. Due to the travel restrictions, I took less vacation than previous years, and I’ll be trying to make up for that a little by taking this week off.

When I started

It’s only been 3 years, but the company has grown considerably.

When I started, there were 279 people (with 183 team members currently who started before me), and GitLab now has over 1300 team members.

With time, I learnt what it meant to live by the GitLab values, and even though the company has grown and there are "growing pains", the company hasn’t changed a lot. I’m thankful to all the people who have had a major influence on what I think it means to "live the values" though many are no longer at GitLab.

Despite all the changes around me and the pandemic, I’ve only ever had two managers while at GitLab, which helped me settle in, grow, and influence others in turn.

If you want to learn more about my first two years at GitLab, please check out my previous reflections:

• My first year at GitLab and becoming Senior
• My second year at GitLab and on becoming Senior again

Working on (O)KRs

After my promotion to Senior last year, I started being more involved in OKRs (Objective Key Results). The OKRs are owned by managers and they’re accountable for them, but as managers are supposed to do, much of the work itself can be delegated to others.

I was responsible for tracking progress on a joint docs OKR last year, and running the retrospective on how it went in Support.

I also helped revamp Support onboarding by:

• merging the Support Agent (deprecated position) with outdated .com Engineer onboarding,
• creating a console training module,
• reorganizing onboarding content to remove redundancies, filling in missing content, and making tasks more consistent for new team members,
• creating a Documentation training module,
• creating a Code contribution training module,
• and probably more that I’ve forgotten.

More recently, I’ve started working with my manager to come up with KRs that are (not OKRs for the team, but) goals for me to fulfill within a specified time span (typically a quarter).

For example, as part of our efforts to "coalesce" the team so that everyone works on tickets in both products (SaaS and Self-managed), I have an epic to ensure everyone is cross-trained. Training was considered out of scope of the Areas of Focus workgroup that came up with the changes that are coming, but it’s definitely a requirement for fully implementing the changes we want to make. So, I took on the epic as something I would lead this quarter. It’s a bit stalled at the moment waiting on managers, but I’m sure I’ll get it done within the timeline that the managers expect.

While looking at the level of work I was doing, shortly after my re-promotion to senior, my manager suggested that we start working on the next promotion document.

On not getting promoted to Staff

Earlier this year, I wrote about choosing not to pursue the management track at least for now. The main reason was that going into management means shifting your focus to your direct reports, while I believe I can be successful as a manager (having been a manager before), I know that shifting back to a technical individual contributor role might be difficult for various reasons.

As a result, I began to pursue a promotion to Staff Support Engineer.

After submitting my promotion document, it got rejected. It hit me fairly hard at the time. Despite being told I was doing great work, getting the promotion rejected was a blow to my confidence. I also got the news while my manager was away, so I’m grateful to Izzy Fee, another support manager, who stepped in to have the "hard" conversation with me.

In a follow up meeting with my senior manager, it turns out, we weren’t aligned on what we believed are the company needs for Support. So, it wasn’t surprising that it got rejected. Partly, it was my manager and my own fault for not writing the document to talk about how my promotion would fill a company need.

So, pro-tip, if a promotion is reliant on not just merit, but also a "company need", then talk to your manager’s manager before writing your promotion document, not after.

It was a really good discussion nonetheless. We agreed that while I wouldn’t be fulfilling the biggest need that we currently have (being a Staff level engineer who is an expert and can lead training and ramp up of others for supporting Kubernetes and highly-available self-managed instances), I could potentially fill a less urgent but still important need on increasing efficiency. The idea is to help answer question of

how could we handle double the support tickets with the same number of team members we have now?

I’ve been working on a number of "Support Efficiency" pieces, and helping my manager with some of his OKRs that focus on that as well. The best example of increased efficiency, especially with low effort, is when I figured out that limiting self-serve deletion drove up our account deletion requests. In cutting it down by at least half, I’ve saved the company an estimated support engineer’s salary’s worth.

At the moment, I haven’t gone back to revising my promotion document. Instead, I’ve been focused on moving ahead with training, onboarding and training others, and working on the project-type work. I’m also hoping that some of the work I’m doing this quarter will add to the document.

The more I discuss the possible promotion to Staff though, the more I wonder if I really want it. I’m happy doing what I do now, and I don’t want the time I’m not working on tickets and mentoring others to be solely focused on the company need that I’m supposed to be fulfilling. So, we’ll see.

We’ve always said that there’s nothing wrong with staying an intermediate, so I simply need to remind myself that there’s nothing wrong with staying a senior.

Becoming a non-manager leader

I believe my main accomplishment of the last year is becoming a leader (without having moved to the managerial level).

At GitLab, we have a list of leadership competencies with a list on how they apply at the various individual contributor levels within Support.

I don’t review the list regularly, so it’s not like I consider it a list where I check off the boxes to say I’m doing those things. I like to think that instead, I’ve internalized a lot of the GitLab values and became a leader through helping, mentoring, and coaching others; thinking about and actioning on improvements; and most of all, leading by example.

As usual, I continued to help improve training in general such as creating self-assessment quizzes for SAML training and SCIM training, and doing a SCIM deep dive session.

More than that though, I take opportunities to help others identify when they can take what they’ve learnt and spread the knowledge as well. Primarily, I do this by helping others make documentation and handbook contributions, and I often do documentation reviews, especially for newer team members. Of course, that’s just one example.

I also regularly meet with other team members to talk about how they’re doing, and particularly, career path and growth. While team members are generally talking to their managers about their career path, most of the support managers we currently have started within the last 1.5 years, so don’t necessarily have the knowledge of learning opportunities, promotions, and career paths within GitLab that I’ve gained. For example, many at GitLab don’t know that we have an internship for learning program where you can "intern" for another team.

Being an individual contributor can also be a very different experience for some, because we are expected to be a manager of one and many aren’t used to self-leadership and very importantly, making their work known to their manager, especially at performance review time.

I’m sure I could go on, but I’ll move on instead.

Being a leader outside of the "work"

It’s important to contribute and be a leader outside of the expected work as well, which in Support means outside of answering tickets, process improvements, and contributing to the product. I strive to be one of the people who are influential and make an impact as others have done for me, like those I mentioned near the beginning of this post (who outside of my manager were not part of my team).

This year, I become a member of the Women’s Team Member Resource Group’s Learning and Development subcommittee with helping to facilitate learning pathways we’ve created. There’s no official list of members, but I started attending the meetings and help with the initiatives we decide on.

While I hesitated at first since I wasn’t sure I could make it, I’ve signed up to be a Contribute Ambassador for our next event in September. Ambassadors are volunteers that do everything they can to assist the organizers make the event a success. Interestingly, one of the organizers messaged me on the last day for sign ups that she was hoping to see me apply. It was certainly great to hear.

I also wanted to do a fun, more social thing for the team, so at the end of last year, I organized a "secret santa" gift exchange for the Support team.

Again, there’s probably more, and certainly some which I started in previous years that I’ve continued, but I decided to pull out just a small number of examples.

The feedback on being a non-manager leader

While it can be hard to gauge how much of an impact you truly have, I’ve gotten bits and pieces of feedback from both individual contributors and managers in the past few months.

A number of the team members have expressed their appreciation in having a non-manager’s perspective on how to prioritize work, record work done, make work visible to their manager, and move forward in learning and career development.

I often have a "manager’s perspective" because I’ve worked as one, and I do my best to apply coaching skills as well. So, I sometimes have a fairly different perspective and approach to these discussions than other individual contributors on the team.

A couple of the managers have occasionally shared stories with me as well on the impact that I’ve had on their direct reports. Once it was how I strategized and provided options on a possible solution to customer problem. Another time was how welcoming I made a new team member feel.

Of course, the best anecdotes are the ones from the individuals themselves. I’ve had a team member say they look up to me and aspire to work like me. My manager told me he learns a lot from me. Someone from another team recently said they remember how welcoming I was to them when they started (more than a year ago). The most memorable is still this one:

From the positive feedback I’ve received so far, I like to think that the whole aspiring to be a non-manager leader thing is working.

External contributions and podcasts

I have always made sure to partake in some external contributions including conference volunteering and mentorship programs. Somehow this past year ended up being one for podcasts as well:

• Co-guest with Amy Quails from the Technical Writing team on the WritetheDocs podcast
• The Journey into Tech Series Guest speaker on another GitLab team member’s podcast, Brown Tech Bae
• Sharing knowledge and training in support engineering on Customers Support Leaders podcast

I hope to continue being involved in the technical writing, library, and support communities as the years go on.

Here’s to Year 4!

This year’s post is not as linear of a story, but I believe that’s a result of going from a new(er) team member still developing and growing in a role to someone who is more settled into the role, picking out highlights of the year. We’ll see what Year 4’s reflection is like to prove or disprove my theory.

If you made it to the end, thanks for reading! Hope to see you again next year!

Your prize is a happy quokka. =D