Since I finished the first one, I have been doing a second internship for learning with the Chief of Staff Team to CEO. If you would like to know what an internship for learning is, and why I chose to do one, take a look at the reflection post from my first internship for learning (just internship for short from here on out).
Even though I haven’t technically finished, since I’m done the majority of the work, I thought it was the right time to do a reflection.
Some context
In a lot of ways, I started doing the work before my internship started. During my first internship, one of the Chief of Staff Team team members had reached out on Slack to ask for some help with Objective and Key Result (OKR) related work. He needed help with some content updates, and to enter OKRs into GitLab. I did a little bit of the former, but mostly the latter. When looking over the content updates, I ended up doing some more updates since we hadn’t removed some outdated guidance.
Part of the work that I did, when I was Acting Chief of Staff to CTO, was to figure out how to add OKRs into GitLab in a way that worked with the limitations of the minimal release we had.
Goals
So, for this internship, there were three major goals:
- Work with the Single Engineer Group (SEG) and product manager to determine and prioritize features we need to effectively use GitLab for OKRs based on discussions with the Chief of Staff Team to CEO, particularly the Chief of Staff to CEO, and other stakeholders.
- Make handbook updates when new product features are implemented, and ensure anyone on the team can follow the OKR process.
- Later on, we added, making the GitLab OKR project public.
OKR features
One major issue when I started was how we would cascade OKRs so that they could easily roll up scoring. Because we were limited to a single parent for items, it was difficult for divisions and departments to score their own objectives, while also having the scoring roll up to higher level OKRs. As a result, either there was a lot of overhead in duplicating items, or things were scored inaccurately.
Scoring to multiple parents is not an industry standard though, so we asked for related items to be prioritized. Making items related would allow us to see basic information (including scores) for items that would normally score towards a particular (second) OKR.
There were some other features that we felt were needed to effectively use OKRs, including:
- An organizational view to easily see where an objective, or key result fit in the hierarchy. Though, the product manager pointed out we had a similar feature request on having a “drill down” view for OKRs, which we agreed would be a big step towards what we’re looking for.
- Automated reminders for assignees to update their items.
- The ability to use manual scoring instead of roll up scoring when an objective has children.
However, for these three, we didn’t think they were as critical as related items. Related items was the only one that significantly changed the guidance we provide.
How it went
It wasn’t a lot of work, and it wasn’t supposed to be. An internship is supposed to take 5 to 20% of your time. Originally, we were planning for the internship to last 3 months, but with delays to when we had thought features would be implemented, we stretched it out another quarter. Since it didn’t add more work, it wasn’t a problem. It was mostly important to have someone engaged in order to track on the items we needed, and update our handbook.
I really appreciate that my own manager was willing to let me do a second internship, considering how busy we always seem to be in support. It’s amazing to be allowed the opportunity to explore a different path of work.
As before, the Chief of Staff Team was very welcoming and open to helping in any way they could. In particular, I relished the opportunity to work directly with the Chief of Staff to CEO, which was the reason I wanted to do an internship in the first place.
Probably because I’d been an intern for months already, the other team members also started adding me to some of the team stuff, like the GitLab group (which allowed me to help approve certain handbook changes).
Since I hung out in the team’s Slack channel, I also helped with some “odds and ends” that would come their way, such as removing the default reviewer in our handbook merge request template.
I also took on some TeamOps transition stuff with Laurel’s departure. There were a bunch of handbook updates involved, and some checking in with folks, but overall a fairly small amount of work.
For those at GitLab, you can see a more complete list of what I worked on in the internship for learning issue.
What I got out of it
In addition to what I wrote in the previous one, it was great getting to know the team better. I also got to meet two new team members who joined while I was doing my internship. It’s always nice to get a fresh perspective on things, and have people who work in different ways join so we can learn from each other.
The internship this time around also touched on company level OKRs and OKR guidance, which naturally has a higher impact.
I was particularly excited to make the project public too, since transparency is such a big part of why I love working at GitLab, and it wasn’t originally part of the work we had planned.
Take away
Really, it’s the same as the last time. If you ever have the opportunity to do an internship, it’s definitely a great way to get a better idea of the job is the kind of work you’d want to do.
