For our company’s fourth quarter (Q4, November 2022 to January 2023), I was the Acting Chief of Staff to CTO. In February, I’m getting back into my regular role as a Staff Support Engineer, while also spending a little bit of time transitioning anything left and ensuring any “loose threads” are tied up. Since there’s quite a bit to write about, and the role is so different from my regular role, I thought it deserved its own post.
Skip ahead if you’re less interested in how I got the role and what I did, and more about my thoughts on the experience.
Applying
I briefly mentioned before that during my CEO Shadow rotation, I became interested in the Acting Chief of Staff (CoS) to CTO role, but never really explained.
Before my CEO Shadow rotation, I didn’t really understand what the CoS to CEO (or their team) does. I got to learn a lot more in just 2 weeks, seeing the CoS and team in various meetings, watching the livestreamed discussion about the CoS’ partnership with the CEO and Q&A, and even sitting in on a candidate interview for a position on the CoS team. The role they serve in the company, and the impact they have really stuck with me. Not only that, the CoS to CEO, Stella Treas, did an amazing job supporting the CEO shadow program and its participants on top of everything else she was doing when there wasn’t a permanent Executive Business Administrator (EBA) at the time.
When the Acting CoS to CTO role was announced before the first quarter (Q1), I seriously considered it. However, I was also hesitant to apply, because the job description says one of the requirements is:
“Capacity to become a senior leader at GitLab.”
In Support, our “senior leadership team” consists of those above the Manager level. At the time, I hadn’t even been promoted to Staff (which is the same level as a Manager), so how could I possibly think of myself as capable of working at the “senior” leadership level, which seemed so far above where I was?
It wasn’t until I chatted with the Acting CoS in Q1, Sean McGivern, who encouraged me to apply that I finally did. Of course, it helped that I had been promoted to Staff by then, and my then manager (Ronnie Alfaro) and director (Lyle Kozloff) were both supportive of me applying and (if accepted) being away from Support for a quarter. It is thanks to the three of them that I mustered up the courage to send in my application.
Being considered
Not too many weeks after applying, I got a message that I was being considered and coffee chats were set up. The selection process involves a coffee chat with the CTO, and a chat with one of the Engineering VPs. I’m not entirely sure how which VP is selected, though for those in timezones outside of the Americas I believe it’s mostly scheduling.
I had my coffee chats with the then CTO, Eric Johnson, and the VP of UX, Christie Lenneville. Both went well, and I was excited to hear they were interested in having me in the position!
However, I didn’t get it in Q2 as earlier applicants get priority. In Q3, my directors thought it would be too busy in Support, and it likely was. Which is why, it took until Q4 for me to be chosen. I’m grateful that our Acting CTO decided to keep the rotation going so that I even had a chance to take it on.
Getting started & onboarding
Normally, you’re supposed to have the month before you start as cross-over time with the current Acting CoS. However, due to various reasons, the announcement that I’d be the incoming Acting CoS was only 2 weeks before my start date. The week it was announced, I was at Support Driven Expo, and the 1.5 week after, the Q3 Acting CoS, Sam Beckham, was out of office (OOO).
Thankfully, Sam created my onboarding issue for me before being OOO, and there were a couple of others who had done the role. Both Sean McGivern (Q1 Acting CoS) and Matt Nohr (Q2 Acting CoS) answered all the questions they could while Sam was out, and Sam was very generous with his time after his return.
I’m very appreciative that they made themselves available as a resource; answering my myriad questions, reviewing merge requests, and being a “sounding board” in some cases. In compiling their answers, I ended up making quite a few improvements to the template issues, especially in regards to onboarding and OKR-related work.
OKRs
Managing quarterly Objectives and Key Results (OKRs) for the Engineering division is one of the main parts of the role, which each Acting CoS does.
It’s one of the first things you need to work on since the retrospective for the previous quarter happens very soon into the rotation. The main thing is pulling together the takeaways and noting any follow up items when reviewing the current quarter, or building the next quarter’s OKRs.
Early on, the most time consuming part is doing the OKR review. I’ve written some OKRs, but I definitely had to refer to our “how to write OKRs” while I was doing the review, since I’m not super practised at it. I may have overdone it a bit on picking on the wording and scoring, but they’re also comments/suggestions and not things people have to fix. The main thing is making sure the OKRs are aligned so that the Engineering (CTO) OKRs are scored properly, and they’re aligned with the CEO (company level) OKRs when it makes sense.
During the quarter, I would check in regularly with the VPs on the current OKRs, flag OKRs that look like they’re behind either from lack of updates or if the work is behind. For some OKRs, such as completion of the TeamOps course and trainer certification, I would update them for the department.
I also submitted additional guidance on writing OKRs, and the timeline on joint Engineering-Product OKRs.
Near the end of the quarter, there’s planning the OKRs for the next quarter, making sure we follow the company timeline, help work on wording, and getting them added to the platform.
For next quarter (Q1), we’ve moved to GitLab, so I also had to figure out how Engineering would structure OKRs in GitLab, since we break down the work sometimes many levels deep, and not all department OKRs are aligned with CTO-level OKRs. It took a bit of work and discussion with the Product Managers leading the implementation and some Engineering leaders to figure out the different options people could use, but we got there in the end. For this quarter, each VP will decide how they want to align and track department OKRs. Hopefully, by Q2, we’ll have the ability to have multiple parents for OKRs.
Getting the next Acting CoS to CTO
The second thing that each Acting CoS does is (at least a minimal amount of) promotion to get more applicants to the program.
It feels really early to do any sort of nudging in the first month, but new candidates that pass the application review are supposed to have coffee chats during the second month of the rotation, and the final decision is supposed to be announced by the end of the second month or very beginning of the third month to allow for “month 0” to happen.
Since “Month 0” didn’t really happen for a couple of us, and a part of December goes towards the holidays, I started on the process fairly early. In addition to promoting the role, I ended up being the person to start the process and followed up to make sure action items got done in order for us to follow the timeline as closely as we could. That didn’t exactly happen due to scheduling and the holidays, but I knew it was going to be difficult.
To make any future transition and rotation easier, I added and improved a bunch of the documentation throughout the quarter, and consolidated all the docs that I could find into a shared drive.
Engineering Leadership Offsite
Normally, one of the regular duties is to help organize the Engineering Offsite for CTO and VPs, in particular, putting the agenda together. However, due to scheduling and most of them attending a GitLab sales event in February, it was decided not have an offsite in Q4.
The miscellaneous regular duties
The CoS is meant to help with cross-division and cross-department collaboration, including identifying those opportunities. I’ve found that difficult to do when only in the role for a quarter, but often, just making sure follow ups from meetings and discussions can help. So, part of the role is to not only attend certain meetings (mostly key reviews, though also CTO office hour, Incubation VP/CEO, Engineering leadership, and others), but to help take notes, ask questions, and follow up on items.
The CoS is also the de-facto primary maintainer of the Engineering Week-in-Review, and is responsible for adding a lot of the cross-department updates.
Projects
You can see a list of issues and merge requests that I worked on.
The more notable ones:
- CTO transition doc: provide an overview and list of key things/resources to help get a new CTO up to speed
- working group rollup updates: where I reviewed the state of things and proposed short and long term plans
- Engineering Week-in-Review engagement: tracked usage/views and sent out survey on readership, use of prefix tags, and proposal of moving from doc to GitLab
- collaboration with Chief of Staff to CEO team on leading working groups MR
Company initiatives and the things I couldn’t get away from
I’m glad that the role wasn’t so busy that I couldn’t continue to participate in company-wide initiatives and the couple of things that are tied to my regular role and couldn’t (I should say, didn’t want to) get away from.
The sorts of things I’m talking about:
- New Auth related documentation page MR
- Pajamas migration day which I’ve done every quarter
- Company mentorship program as mentor
- Team Member Resource Groups, namely Women+
- TeamOps trainer certification
A different time and pace
Support work is very “reactive”. That is, something happens, and you react to it. So, in a normal week, I would spend a lot of time working on a large variety of things, and I would get a lot of pings/mentions. One of the ways I’d help others was to join or lead help sessions.
To try to get ahead of problems and be more proactive in the work, I’m a counterpart for a few teams and product groups, and help bridge Support within itself (because we have a large team) and other teams in a bunch of areas even where I’m not the designated counterpart.
As such, I actually spend more time in “meetings” when in Support. The months that are significantly lower are because of vacation time.
One thing this chart can’t show is how many meetings I had outside of my regular work hours. Support has team members all over the world, so it’s not unusual to have early or late meetings to find a time that works.
As Acting CoS, I had less meetings overall, and less meetings out of hours. Because I had a lot less pings/mentions, I also got more “focused” time. It was a really nice change of pace. I can’t tell you though whether I felt more or less productive.
Rotation length and timing
There are upsides and downsides to having the role as a rotation.
The major downside is that knowing you’re only in the position for 3 months, I (and some of the others) was hesitant to take on longer term projects or initiatives. However, I don’t think the length of the rotation should be a complete blocker. Depending on the project or initiative, we would just need to set clear expectations on what the Acting CoS would do, and if it’s something they would keep doing after going back to their regular role, or if it would be passed on to the next Acting CoS.
Since I was working with an Acting CTO though, I didn’t really try to change this trend this quarter. Instead I focused on what I could accomplish in the quarter, took on issues from previous quarters, and opened a couple of follow up issues for the next Acting CoS to consider.
On the flip side, the major upside is that it provides the opportunity to Engineering team members to work with our CTO and VPs, without committing to a permanent change. While a CoS-type role has certainly peaked my interest, I’m definitely not ready to leave Support, and look forward to taking all I’ve learnt and applying what I can to my regular role.
Expanding my view and cross-team work
Working with the Acting CTO (Ashley Kramer) and the Engineering department VPs (Christopher Lefelhocz, Bartek Marnane, Steve Loyd, Mek Stittri, Tom Cooney) was a little nerve wracking and intimidating at first, but I think that’s normal for anyone who isn’t used to working at that high of a level. They were all very helpful, patient, and thoughtful, so it didn’t take long for me to lose that nervousness for the most part.
I met regularly with the VPs (almost weekly, or biweekly), and while most of the discussions revolved around OKRs, a number of the small projects were based on comments they made.
In attending the key review meetings, and a few other high-level meetings, I got a much better idea of how the Engineering division aligns itself with company and product direction, and what our executives are looking for and asking questions about. Getting that strategic overview is very valuable, and helps put things into perspective. Hopefully, it’ll help me think more about how to align the work that I do in my regular role with the Engineering and company direction.
In the course of my work, especially with coordinating or following up on various things, I also ended up interacting with a lot of people that I don’t normally work with. Many I knew by name, but I don’t know how many knew me, and most I had definitely never worked with, especially Directors and Senior Managers. Aside from Engineering, I also ended up working with numerous Chief of Staff to CEO Team team members, People Business Partners, and Product division folks.
I was also glad to have the opportunity to work with a couple of the EBAs (Jeanette McCarthy and mostly, Marisa Carlson). (I once considered becoming an E(B)A, so I’m always interested in the scope of the work they do at different organizations.)
GitLab’s culture fosters collaboration, and allowed for me to just drop in and ask for things without no apparent resistance, which I really appreciated. People definitely had “short toes”, and willing to iterate by merging improvements and leaving further changes to be done in follow-ups.
The mindset and skills you need
For me, personally, the role stretched how I think of and apply the GitLab values and its tenets.
Many I believe I’m good at, and are very important to the role:
- Manager-of-one
- Ownership
- Bias for action
- Don’t wait
- Make small merge requests
- Be respectful of others’ time
- Low level of shame
- Directness
- Public (even just internally) by default
- Findability
- Single Source of Truth
In some cases, it wasn’t doing something “more” or “less”, but rather, thinking about or applying it differently than what I’m used to. For example, normally, I rely on GitLab mentions (which creates a To-Do and notification for the person in GitLab) for less urgent items that need actioning on. However, many of the people that I interacted with get mentioned on so many things that they basically don’t use GitLab To-Dos. This difference meant that to get something actioned on, I had to rely on Slack pings, direct messages, or sync meetings. In addition to adapting to others’ communication preferences, it feels like a different way of applying the “escalate to unblock” tenet.
I think the thing I struggled with the most is being “give[n] agency”. It’s great when you have plenty of (or too many) things to do, but most of us aren’t in the role long enough to really get a sense of what gaps we can help fill. Some of the previous Acting CoSes have written about this aspect too. In any temporary role, there’s more onus on the “manager” to identify the work that needs to be done. Nevertheless, I don’t think I had too little to do, since having less to do for the role itself gave me the time to participate in company-wide initiatives, and set aside time to learn most weeks as we’re supposed to.
Still, I think the Acting CoS could take on more responsibilities to more effectively support the CTO and VPs. Anyone who takes on a rotation needs to really pay attention to where opportunities lie. If you “see something, say something”. Other times, someone may simply make a comment on what could use improvement, or their desire to see something done differently. You would then turn that comment into a task or project.
Three months or a quarter of the year may sound like a long time, but it’s very little time to dig into things. So, you have to be ready to just dive in. I mentioned people being willing to work with me on things when they may not know who I am, which is great, but that means you have to be willing to put yourself “out there” first.
Another example: Asking questions in a “big” room, or in a room with all senior leaders, is not always easy. You still have to be willing to ask those questions. I think it’s easier at GitLab though where you can write down your question in a meeting document first (instead of feeling like you’re not sure who should go next, or that someone else’s question should take precedence).
To get the work done effectively, you need to be highly organized and able to track numerous things “at once”. Some of the work requires paying close attention to details. It also helps to be a good notetaker. Mostly, I found needing to make sure to keep things regularly updated, and be comfortable with nudging people. Sometimes I felt a bit like a “broken record”, repeating myself, but if the work has a deadline and it’s not something you can do yourself, all you can do is keep nudging people until it’s done.
None of what I’ve said are requirements though I believe they would certainly lead to a more successful rotation.
Take away
While it was a bit of an unusual rotation with an Acting CTO and no offsite, I still learned a lot, and felt like I got a good amount of work done, with much of it spanning one or more divisions and departments. It’s often difficult to see the direct impact, but it’s only logical based on the scope of the work that much of it had a reach.
“Your depth of knowledge and organization were really impactful for me.” – Marisa
(The blog post covers most of my thoughts, but you can see my comments structured differently in the retrospective issue, and some comments from others.)
I would definitely recommend a similar role to anyone, especially at the Staff/Manager+ level, who reads through my blog post and thinks:
“I’d be interested in doing that too, and I think I have the skills to do it.”
Granted, a Chief of Staff can vary significantly depending on the organization. So for those outside of GitLab, have a chat with a Chief of Staff in your network, and if you apply to a role, make sure to read over the responsibilities first.
For those in GitLab Engineering, it’s a particularly great opportunity, since it’s a rotation, which allows you to take back all your learnings to your department. If you’re interested, I recommend having a chat with one of the Acting CoSes.
In doing the role, I’ve become even more interested in moving into a Chief of Staff type role in the future. Though, it’ll likely be another year before I seriously consider it.
Thanks for reading! If you have any questions, feel free to reach out.