Normally, I post a reflection once a year, but so much has happened during the fourth year already that I felt the need to split it up into two and write about the first 6 months of my fourth year to make sure the reflection didn’t get too long.
If you’re a first time reader, I recommend reading at least the previous reflection post about my third year at GitLab for more context. Continue reading “Reflection: First half of my fourth year at GitLab and getting more involved”
I spent 2 weeks being a CEO shadow at GitLab, and thought I’d reflect a bit on my experience. If you’d like a more thorough write up, check out Darren Murph’s takeaways and lessons learned blog post, or check out the CEO Shadow YouTube playlist. Continue reading “Reflection on my CEO shadow rotation at GitLab”
Ever since becoming a Senior Support team member at GitLab, I’ve had various conversations about becoming and being a Senior level team member; even more so after I became a Senior Support Engineer (SSE). A couple of recent conversations made me realize that a lot of team members have questions and we should have a way to share the answers, so I organized “Ask Us Anything” (AUA) sessions on Being and Becoming a Senior Support Engineer. Continue reading “Summary and Thoughts on Being/Becoming a Senior Support Engineer at GitLab”
Notes from the closing key by Laura Tribe from Open Media. Continue reading “Access 2021: Dave Binkley Memorial Lecture: Open Media: Laura Tribe”
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.
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:
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:
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.
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.
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.
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.
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.
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:
I hope to continue being involved in the technical writing, library, and support communities as the years go on.
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
The UBC iSchool reached out to me recently asking me to talk about my path from getting my library degree to ending up working in a tech company. Below is the script for my portion of the talk, along with a transcription of the questions I answered. Continue reading “UBC iSchool Career Talk Series: Journey from LibTech to Tech”
Often, to move up and get a higher pay, you have to become a manager, but not everyone is suited to become a manager, and sometimes given the preference, it’s not what someone wants to do.
Thankfully at GitLab, in every engineering team including Support, we have two tracks: technical (individual contributor), and management.
Continue reading “Choosing not to go into management (again)”
I mentioned in my GitLab reflection that prioritization has been quite different working in Support compared to other previous work I’ve done. In most of my previous work, I’ve had to take “desk shifts” but those are discreet where you’re focused on providing customer service during that period of time and you can focus on other things the rest of the time.
In Support, we have to constantly balance all the different work that we have, especially in helping to ensure that tickets are responded to within the Service Level Agreement (SLA).
It doesn’t always happen, but I ultimately try to reach inbox 0 (with read-only items possibly left), and GitLab to-do 0 by the end of the every week. People often ask me how I manage to do that, so hopefully this provides a bit of insight. Continue reading “Prioritization in Support: Tickets, Slack, issues, and more”
This reflection is a direct continuation of part 1 of my time at GitLab so far. If you haven’t, please read the first part before beginning this one. Continue reading “Reflection Part 2: My second year at GitLab and on becoming Senior again”
About a year ago, I wrote a reflection on Summit and Contribute, our all staff events, and later that year, wrote a series of posts on the GitLab values and culture from my own perspective. There is a lot that I mention in the blog post series and I’ll try not to repeat myself (too much), but I realize I never wrote a general reflection at year 1, so I’ve decided to write about both years now but split into 2 parts. Continue reading “Reflection Part 1: My first year at GitLab and becoming Senior”
Learning (Lib)Tech 
You must be logged in to post a comment.