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.
Emergencies and incidents
One of the things Senior Engineers naturally get more involved in are emergencies and incidents.
For context, for our team, those are different things. Emergencies are customer emergencies, typically where organizations are running a self-managed instance of GitLab, and Support focuses on troubleshooting and resolving the immediate issue. Incidents are related to our SaaS platform (GitLab.com) where our Infrastructure team calls upon Support to help manage communications. We’re expected to be on-call for one or the other, not both. Previously, GitLab did not provide emergency support for SaaS customers because we have an Infrastructure team handling incidents on GitLab.com. However, the definition of an emergency is based on impact and there may be times something happens where it only affects a specific customer, so it was opened up.
Anyway, I’ve always been on the SaaS communications on-call schedule, so didn’t get much involved in emergencies. Incidents being more communication focused for Support, we didn’t get involved in the troubleshooting aspect much there either.
Once we opened up emergencies to SaaS customers, I was often pulled in when an emergency was triggered by a SaaS customer as I am 1 of only 2 Senior Support Engineers who primarily deal with SaaS in the Americas region. Additionally, as I honed my areas of expertise, I was called upon more if a self-managed emergency came up in an area where I was an expert, typically authentication/authorization or import/export. That seemed a natural progression at least.
Late last year though, I ended up helping to troubleshoot an incident because it was SAML related. Our Engineering Fellow, Stan, made a passing comment during the call that he knew I’d have something set up to help troubleshoot the issue. I am a SAML expert and well-known within Support for it, but I didn’t realize I was known as one widely enough for people outside of Support and the Manage:Auth group to think of me. It was a bit of a surprising, but cool moment for me.
It still doesn’t often happen that I’ll be involved in troubleshooting incidents, but where I never would’ve before, now there’s a rare chance I might depending on the specific issue.
More OKR and KPI work
While our everyday work contributes to the team meeting our KPIs (Key Performance Indicators), we’ve gone through periods where we weren’t meeting them. In the past, I’ve brought my concerns to managers, but I decided to start making my concerns more actionable. A couple of examples, where SLA (Service Level Agreement) in this context means whether tickets were responded to within the expected time:
- Participated in SLA metrics workgroup.
- Proposed ZenDesk view changes based on SLA attainment concerns (closed in favour of another proposal which included the changes I suggested).
While ultimately my example proposal was closed in favour of another, I had multiple managers thank me for writing up the related issues and being willing to take on the work.
Last reflection, I talked about getting involved in (O)KRs (Objective and Key Results) as well. Although that work continues, recently, I also proposed OKRs for Q4. The documentation one made it as an OKR for Q4 though unsurprising since it was a modified version of an OKR that was originally slated for Q3. While I don’t see it as a “big” deal, I’ve never seen another IC (individual contributor, non-manager) on our team write up OKR proposals before, so it was great to see one of them accepted.
Expanding counterpart roles
I’ve been a Support Stable Counterpart for UX, Technical Writing (Documentation), Manage:Access, and Manage:Import for some time now. Depending on the group, I didn’t have a lot of involvement, but over time, as I have gotten to know the team members better, I’ve gotten more questions and pings.
The easiest way to get a better connection has been to have a coffee chat with some of the team members, especially (new) Product Managers. In Manage:Access, I’ve had the most impact:
- working together with the developers on troubleshooting issues,
- discussing feature direction in a couple of cases,
- providing feedback to the Product Designer on mockups and prototypes, and
- helping customers migrate off of a feature that was in beta and being deprecated.
In Technical Writing, I’m familiar enough with the team that I got asked to be one of the “external” (outside of Technical Writing team) interviewers for the hiring process. I was honoured to be asked, and I enjoy interviewing, so I happily accepted. There are a bunch of other things that I continue to do that go beyond what Support Engineers typically do, such as add to the Troubleshooting documentation section of the style guide.
As I had planned to read it anyway, I also ran a book club for the Docs for Developers book that was published last year.
Participating, learning, and mentoring outside of the Support team
Last time, I already mentioned becoming more involved in providing learning and development for the Women Team Member Resource Group (TMRG). Since then, I’ve also been a:
- Mentor in the Women at GitLab Mentorship Program, which I’m signed up for again!
- Participant in a #iamremarkable workshop.
- Panelist on the Women TMRG’s Career Transition Panel session.
There’s also a bunch of other things, but the one other I’ll mention is that I’ve continued to participate in the #postcrossing Slack channel, and did a bit of internal “promotion” as a way for people to virtually travel.
Of course, I couldn’t do a reflection post of this period without talking about the day the company went public.
The events team did an amazing job getting the whole thing livestreamed. I hadn’t originally planned on getting up really early since the stream started at 5am local time, but I realized that it would never happen again, and I’m not sure I’d ever end up in a place that would be going public.
With a bunch of others, I also got to participate in a few recordings that were shown on a video “wall” that was put up outside of Nasdaq in Times Square. I never managed to get a photo of me on the screen, but you can see what the wall looks like in this tweet:
In addition to streaming the whole thing, we got the chance to submit a picture that would show up on the Nasdaq tower!
On top of that, the team put together an extra special swag box.
I also helped virtually by being a “Listing Day Champion”, one of a group that would answer other team members’ questions as much as possible, pinging the events team members only as absolutely necessary. This method of having volunteers answer and filter questions is similar to our Contribute Ambassador role.
After the stream was over, someone later pointed out my desk was on Bloomberg! I didn’t realize my desk picture was in the press kit, but it was a great surprise:
While it took me a couple of days to recover, I have absolutely no regrets with waking up early, and even though it was virtual, I have lots of fond memories of the event.
Just a couple of additional great moments for me:
- Some team members (including myself) who kept cringing at our logo being called a Japanese fox, when it’s a tanuki (Japanese racoon dog).
- Our CEO, Sid, who briefly took over someone’s laptop to say hi to everyone recording a last minute video for the wall.
- Just the overall energy and enthusiasm from team members gathered virtually.
Last hurrah for library stuff
The week after listing day was Access Conference 2021. Being the second year of the pandemic, we had a lot less attendance than the previous year. We got it. People are tired. I certainly felt like I hit a “COVID wall” not long afterwards.
The main thing though is that the longer I’m out of libraries, the more I feel disconnected from the field. I believe it’s a natural thing, but it kind of sucks since I have a MLIS, and always thought that the field could learn a lot from librarians who go outside of libraries. Of course, that requires those in the field to accept ideas from outside of it, which many people do, but many organizations don’t.
I was also disappointed that Code4libBC didn’t happen. I had hoped to just pick a date, spin up a Zoom meeting, and see who would attend. Unfortunately, I got a bit swamped with work around that time, and there was so little response from the library community that I didn’t think it was worth the effort.
So with that, I am likely pulling out of library stuff unless specifically asked to participate. This last section is going against what’s in the title, but it simply means I’m redirecting my efforts and will likely get more involved with initiatives outside of libraries.
The title of this post is interesting because normally you’d think “getting involved” in the organization is something you’d expect someone to do in their first year, and it’s not that I wasn’t already involved with a bunch of things outside of Support. However, I’ve felt that in 2021, and particularly the last 6 months, I’ve been more involved and more consciously decided on getting involved in work that is outside of “the job” (as in what’s written in the job description), expanding my involvement at GitLab.
It’s been really rewarding and I hope I’m able to continue taking on these opportunities.
Thank you for reading to the end!
This time around, you get a sea bunny (Jorunna Parva):