My Week as a Development Director Shadow at GitLab

I recently had the opportunity to shadow Wayne Haber of GitLab in his Development Director Shadow Program. The program allows anyone to virtually follow Wayne around for the week and sit in on his (non-confidential) meetings. I was immediately intrigued when I first heard about it in Mrunal Kapade's article.

Read on for more details, but if the program appeals to you and you can spare the time, I highly recommend participating.

My interest in the program was initially based on Wayne’s role. I’ve been an Engineering Manager for 6 years and was recently laid off. I’ve been looking at Director-level positions for my next role so getting to see a week in the life of a Director was a learning opportunity I couldn’t pass up.

Preparation

Before joining the program, you need to go through GitLab’s TeamOps training. This is an introduction to how GitLab works as a large, globally distributed company. I found a lot to like in this course and would recommend going through it if you’re curious about how companies manage remote work. In particular, I liked how GitLab uses extensive documentation and a bias toward action to mitigate the challenges of asynchronous work.

GitLab documents things extensively and publicly, so I was also able to review Wayne’s README, his OKRs, and information about his departments: Secure, Govern, and Growth.

Shadow Week

Over the course of 4 days, I joined Wayne in 14 different meetings. They were primarily 1:1s but ranged across the org chart. I sat in with Wayne’s direct reports, skip-level reports, peers, and his manager. I also sat in on an external mentoring session, a webinar Wayne delivered, and an introductory meeting with a future shadow. Because GitLab optimizes for asynchronous work, meetings only took up about 8 hours of the week.

My role in those meetings was mainly to observe but Wayne also invited me to contribute or ask questions where it was appropriate. In one meeting, I gave my thoughts on the value of certifications. In another, I got to discuss the different (and similar) challenges with communication at the Manager, Director, and VP levels. I don’t have much professional experience with the areas Wayne’s teams are responsible for but other shadows were able to contribute more directly in tactical discussions. 

Outside of meetings, I also reviewed Merge Requests and LinkedIn posts Wayne was working on. Given my lack of context, I didn’t feel like I had much to contribute but offered feedback where I could.

One (seemingly) simple place I thought I could contribute was to help improve the GitLab Handbook. Leaning on GitLab’s bias toward action and concept of “everyone can contribute”, I took it upon myself to fix what looked like a typo where an employee’s title was being displayed where their name should be. What I thought would be a quick fix led down a rabbit hole of data fidelity, privacy, and internal systems. You can see how the issue evolved in the comments on the merge request. 

What I thought would be a straightforward chance to play around with the GitLab product and process became much more complicated and honestly, I loved it 😄. I’ve been asked in recent interviews about how “technical” I am and this kind of thing is exactly where I think my technical skills have the most leverage. My days of writing the most elegant code using the latest frameworks are generally behind me but being able to decipher how a complex system works to help facilitate decision-making is definitely something I can do (and really enjoy).

Takeaways

Everyone’s shadow week will play out a little differently but here are a few of the things I took away from my experience.

Calibrating Expectations

One of the most challenging (but ultimately rewarding) parts of the program is that you are dropped directly into the deep end. You are shadowing Wayne as he performs his job; a job he’s been doing for more than 4 years. It would be impossible to join a 1:1 meeting with Wayne and someone who has reported to him for years and know what was going on. If you push through that sense of confusion, however, there is some freedom in being able to pick at only what interests you. Wayne was clear that I was not being asked to understand or contribute beyond my comfort level. This wasn’t a test to see if I could go from outsider to fully integrated Director of Engineering in 4 days. Instead, it was an opportunity to learn and contribute where I could and not worry about the rest.

It reminded me of when I’ve onboarded new Developers to my teams. I want new team members to integrate with the team practices as quickly as possible but with the very clear caveat that they are not expected to contribute (or even understand) what is happening at first. As long as they are gradually building their knowledge, they are succeeding. 

Observing 1:1s

As a Manager myself, I’ve never had the opportunity to directly observe someone else’s 1:1. I believe strongly in the value of well conducted 1:1 meetings but only get feedback from my direct reports since there is never another manager sitting in. Observing Wayne was both a useful validation of how I approach these meetings but also a chance to improve. As GitLab practice, Wayne and his colleagues use asynchronous documentation to make meetings more efficient. Each of these 1:1s included an agenda pre-populated by both participants in a document that contained the full history of previous meetings. It meant that it was easy to shift gears from small talk to deep discussions because everyone had context from the beginning.

I’m definitely going to update my practices around documenting 1:1s but I’m also curious to see if I can incorporate shadowing. I want to manage Managers in the future and observing 1:1 meetings could be a good way to give and receive feedback.

The Value of Documentation

I got enormous benefit from the information GitLab has publicly available. I quickly realized I could read a quick bio about anyone Wayne was meeting with, review the org structure of one of his departments, or dig into historical changes to the Handbook with minimal searching. On one hand, this added to the firehose of information I was trying to consume during the week but on the other, I would have been completely lost without it.

It’s not novel to think that good documentation makes things easier but I’ve never seen another workplace where documentation is used as effectively. For GitLab, this stems from one of the tenets of TeamOps: having a single source of truth (SSoT). It would take significant time and effort for an organization to adopt a handbook-first approach like GitLab but seeing it in action has at least given me some ideas about smaller practices I can adopt for myself and within my teams.

Conclusion

Overall, I’m still just impressed that this program exists. It’s a real testament to GitLab’s value of being “public by default”. Wayne and his colleagues have adjusted how they work to make it possible for someone outside of their organization to easily be a part of their work. In fact, it wasn’t just possible; it was expected. While I would be very unsettled if I showed up for a meeting with my manager and a stranger was in the room, I was normally greeted with, “Oh, you must be Wayne’s shadow.”

I’m incredibly grateful to Wayne, his colleagues, and GitLab that I got a chance to do this. Because I’m currently between jobs, this wasn’t just a chance for me to learn but also to apply my skills and do something with tangible value.

You will likely get something different out of your week in the program but I’m confident it will be worth the time. You can learn more and sign up here: Development Director Shadow Program.