What I learned as a Development Director Shadow at GitLab
At GitLab we have a development director shadow program which allows any GitLab employee a deeper look into the day-to-day operations of an engineering director.
Last year I had the opportunity to be part of GitLab’s CEO shadow program. I got tremendous value out of it, and learned what CEO’s do and how they operate. This year, I went ahead and signed up to shadow Wayne Haber, our engineering director for growth, security, and data science. This experience has provided me more insight on how another part of GitLab operates.
In this program I was exposed to most of Wayne’s meetings in order to learn what an engineering director does, how they do it, and how they make decisions. Exploring more leadership positions has given me perspective on what my growth path should be.
Starting the program
I learned about the program by posts on the slack channel for the Secure stage development team. My experience started with an introduction call the week before, where I prepared for the program by:
- Obtaining access to Wayne’s calendar
- Going over what is expected of the program
- Discuss what Wayne is currently working on
Notable Meetings
As an engineering manager shadow I attended many of Wayne’s zoom meetings in order to gain perspective of his day-to-day.
The below are some of the notable meetings I attended:
InfraDev/Engineering Allocation
In this meeting a variety of different VPs and engineering managers discussed error budgets, reliability, and security.
The SLA requirements, security issues, and corrective actions were discussed. We went over what issues are currently affecting our error budgets and must be remediated. Root causes were analyzed and then a plan was made for remediation.
This has shown me the efficiency of having all the information on a single document and then discussing proposals to correct. This makes the meeting flow much easier than not having any data beforehand.
Anti-Abuse Planning
In this meeting, I gained insight on limits that should be set in order to alert when we believe abuse has been performed on the system. Then we can examine illegitimate usage from free accounts.
I was able to learn how abuse is detected, and what we are doing to detect the new innovative ways in which malicious actors try to obtain free compute for crypto mining from our system.
Product Meeting
In this meeting, Wayne happened to be a guest speaker introducing himself and his responsibilities, counterparts, and top priorities. It was nice to understand his biggest challenges after almost 3 years at GitLab and how he handled them.
Notable Merge Requests (MRs)
I assisted with reviewing a number of merge requests and issues. Wayne would send me a few each day to show what he has been working on, so that I can provide feedback.
Going through these issues allowed me to prepare for meetings and have a deeper understanding as to what is going on in the organization.
Engineering Internship Working Group
This MR contained information on starting a new working group for our engineering internship. I provided my thoughts on the process for establishing a working group, and what information should be provided in the handbook.
ModelOps has been renamed to DataScience and Anti-Abuse has been moved in
This MR showed me that some development teams were being renamed for others to better understand their purpose. ModelOps maybe a confusing name, but data-science is very clear.
Anti-Abuse was moved under DataScience since it analyzes patterns in the data in order to determine abuse.
Preventing Abuse
In this MR, I was able to gain some insight as to how we identify and continue to advance abuse prevention of GitLab pipelines.
This is a problem in many companies, due to users taking advantage of free runner cycles for cryptocurrency mining.
Issues with Logging In
This MR was a reported issue on certain browsers and plugins not causing errors in the GitLab login process. Although uncommon, there were still occurrences, so it is important to investigate.
I suggested in each failed login we record the browser, add-ons, and OS version, so that we can test compatibility and keep metrics on what browsers experience issues.
Conclusion
On the last day of the shadow program, I met with Wayne to discuss what I have learned and ways we can improve the program. I went ahead and suggested the following:
- Director should continue to report a list of merge requests and issues of interest daily — This provides the shadow with something to work on and look into each day aside from meetings
I really enjoyed my time as an engineer shadow and will continue to seek guidance from Wayne! I got to see aspects of the company I would have never seen without going through this program.
Thanks for reading, I hope you enjoyed this article! If you want to see similar articles like this, checkout my other stories.
Feel free to find me on twitter 🐦, My posts consist of travel, philosophy, tech, comedy, and some cool things I find.
