Normally, I wait until at least the half-year mark to do a reflection post, but this year for the 4th quarter, I am doing a rotation for the Acting Chief of Staff to CTO role, which deserves its own post. So, I’m doing the first reflection post now to cover mid-June 2022 to the end of October 2022.
If you’re a first time reader, you may want to read one or more of my previous reflections posts.
Staff reporting line
In my last reflection post, I talked about being promoted, and then trialling reporting to a Senior Manager.
At the end of the quarter, we agreed that a Staff Support Engineer can report to a manager, but would likely be more effective and therefore should report to the next level. You can see some of the reasons why we believe a Staff Support Engineer should report to a higher level in the merge request where I created a Staff Support Engineer page.
As a result, we decided to make the change permanent. Though the Senior Manager I was reporting to got promoted, there’s no Senior Manager, so I’m still reporting to Lee Matos, who is now a Director.
One of the big upsides is that I get much better visibility into the bigger picture and strategies that our senior leadership within Support are thinking about. I also have my skip level with our VP of Support.
OKRs
I mentioned before that we’d never had Staff-led OKRs, so it’s worth providing a bit more detail on what’s been happening in that area for me.
Q2 Docs OKR
Super happy to report that we attained the Move troubleshooting content to relevant docs pages that I took on as an OKR in our second quarter. However, achieving the OKR is not the same as completing it. So, through the next quarter, I continued to work on issues and asked others from the Support team to assist. We recently finished the epic!
Since it’s marked with “CEO Interest”, I even got to report to our CEO on its conclusion.
The effort involved 14 source pages and a much larger number of target pages, the 74 linked issues, and 18 Support Engineers plus 2 interns; not to mention all the Technical Writers doing reviews and helping us add guidance to the Troubleshooting topic section of the documentation style guide.
The final result is that we went from 19 troubleshooting pages to 4 pages with actual content (not redirects) by integrating the content into the relevant parts of our documentation.
Getting this epic completed was definitely a collaborative effort so thanks to everyone involved!
Q3 onboarding OKR
During the third quarter, my manager and I settled on getting feedback and improving Support Engineering onboarding. It had been over 2 years since we made a larger revision to our team’s onboarding.
Back then, the big change was that it had been broken up from one lengthy list of things into separate training modules. As part of that, a bunch of the content was revised as well. But even then, it was based on what the people involved had heard from whomever spoke to them about onboarding and their knowledge/experience.
For the first time, we decided to be more strategic in gathering the feedback. I created a survey with 8 five-point scale questions and 6 open-ended questions, then sent it out to the 6 most recent hires, and later, the new hires that had started that quarter.
While we encourage new hires to submit merge requests to help improve onboarding, they’re typically comfortable fixing links and inaccuracies, but not changing the list of tasks or guidance on how to complete onboarding. For example, I made one merge request to the company onboarding that isn’t even listed in the action items since it wasn’t Support team specific. I also re-organized the on-call training modules based on one person’s feedback that there was a lot of redundant information. It was great to know, because it’s not the sort of change I’d expect a new hire to do themselves considering you’d have to be familiar with the on-call roles.
Overall, there was a lot of positive feedback. More than one person said it’s the best onboarding experience they’ve ever had!
So, hurray! No major changes needed to onboarding overall. Still, there’s always room for improvement, so I ended up with 15 action items that I completed by the end of the quarter.
Defining the Staff Support Engineer OKR process
Not long after I was given my first OKR, I reached out to other Staff-level individuals who are assigned OKRs to get a better sense of how they go about it. After 2 quarters completing OKRs, it felt like I had enough to add OKR guidance to the handbook.
What’s a little funny is that one of the directors mentioned to me that we don’t have OKR guidance for managers in Support (yet). In practice, the managers typically work on the OKRs that the senior leadership team has defined, whereas my OKRs are decided by my manager and me. In light of that difference, it makes sense that there would be a bit more guidance for Staff Support Engineers that want to take on OKRs.
What is a Staff Engineer?
Last year, when I was looking to get promoted to the Staff level, one of the big questions was:
what does a Staff Support Engineer look like?
As I’ve been working within the role and helping to define it, I’ve been trying to figure out the answer to that question.
The thoughts that came out of the discussion and AMA on becoming a Staff Support Engineer has really helped, but reading The Staff Engineer’s Path book has been reinforcing some of the ideas, especially the one where the role can vary a lot depending on who you are and what your organization needs.
“Staff engineering roles come in a lot of shapes. There are many valid ways to do the job. […] It’s up to you to discover and decide what your role is and what it means for you.” (Chapter 1)
If you’re in a position where you’re looking at a Staff-level role (whether from the individual side or the manager side), you might find the book helpful as well.
Pajamas migration days
This year, the UX team started running a Pajamas migration day once a quarter (Pajamas being our design library). Basically, the idea is to migrate a component (such as a checkbox or dropdown) that doesn’t use our design library to start using it.
I’ve been participating since UX started doing them and I’ve been trying to get other Support team members to participate as well. It provides exposure to our design library, plus our frontend, which not many Support team members usually do fixes for (typically it’s backend). It was super helpful for me, enabling me to even fix a bug issue for a customer as soon as I found it.
The last couple quarters, I managed to get other Support team members to participate. In the most recent quarter, one of them even submitted enough merge requests to take advantage of expensing a meal!
Deeper into the product counterpart relationship
I’ve mentioned before that I’m a Support counterpart for a number of groups. While most of them haven’t changed a lot and I do sometimes get pulled into incidents that can take up a fair amount of time, otherwise, I’m not sure how much more time I’m really spending on the counterpart part of my role. Instead, I’ve been trying to be more strategic about it.
- Over a year later, finally brought about Group Managed Accounts End of Life by working with Product, Development, Sales, and customers to move customers off of it. Allowing Support to deprecate “special” considerations as well.
- Continue to do reviews of designs, such as login redesign and 2FA disable.
- Helping with working out MVCs in discussion with the Product Manager, Designer, and/or Development Engineers; such as Domain verification, SSO identities editing via API (which landed in 15.5), and User deletion warning modal.
- Identifying Support efficiency issues, such as Ensuring Auditor can view everything (which also increases security by having less Admin accounts).
- Identifying high impact issues based on Support costs, and working with Product to prioritize, such as Improving 2FA recovery where the main feature should be released in 15.6.
I recently also brought up the idea of having a small amount of resources slated for Support Priority or Efficiency issues with the Product Manager of Manage:Authentication & Authorization, Hannah Sutor. She threw out 10%, which was amazing! It may not seem like a lot, but getting anything is more than what many support teams get (if other people are to be believed). I’d like to think it’s in part because of the relationship I’ve built with and the expertise I’ve provided to the team. The Auth team is going to trial it without me (ironically enough), and I asked my backup to keep track of how it’s going until I return to my regular role.
The more I got involved with the Auth team though, the more I felt like I wasn’t spending enough time with some of the other product groups I’m listed as a counterpart for. As such, over the last few months (a year?), I’ve been trying to find others to take over a couple of them. (Seriously, I have 5 counterpart roles and that’s way too many. We suggest 2 max.) Having to find coverage for all the roles has allowed me to find potential replacements for at least 1 group. Hopefully, the managers can help find someone for at least 1 more.
Vancouver meetup
I can’t forget to include some of the more fun social stuff!
During the summer, I organized a meetup in Vancouver for August. The last time I did a meetup in Vancouver, we had 7 or 8 people. This time, we had 15! It was a little more work than I expected with the size of the group, but it was great to meet all the new folks in the area, especially since we didn’t have our company meetup this year.
But we didn’t get any proof in the form of photos.
Oh well, next time!
Out in the field: Support Driven Expo 2022
The last Support Driven Expo was in 2019 when I attended with one of my teammates. At the end of that one, I flagged it as a conference that our team should be presenting at. This year, we got 2 presentations in! (I got one, and my teammate, Greg Myers got one.) With the extra tickets, we got 2 other team members to attend as well.
In case you missed it, you can see the slides and transcript of my presentation.
You can also see notes from sessions I attended live. I may do another notes post once the recordings are up.
Instead of a reflection on here, you can see the take-aways from all the GitLab team members that attended.
Coming soon
That’s a lot of stuff, and hopefully, I didn’t miss anything significant.
One of the things I’ve talked about a lot lately though is how I track work and encourage others to do it. Over the last few months, I’ve helped a bunch of people with their promotion documents as well. I’ve created resources for team members within Support, and GitLab, but I’ve gotten questions from people outside of GitLab too. Stay tuned for a blog post.
See you next quarter!
I’ll do a reflection post specifically for the Acting Chief of Staff to CTO role shortly after I’m done as well, so expect another reflection in about 3 months!
