This blog post is
unfiltered
I participated in the CEO Shadow program in July of 2020. It was quite an exhilarating experience.
You will find below:
- What I did during the program
- Why someone should apply to be in the program
- What I learned about Gitlab values in action and effective communication
What did I do during the GitLab CEO shadow program?
- There were 10+ meetings to attend per day over two weeks. Meetings included one on one discussions with Sid's direct reports AKA the E-Group, group conversations, Key Reviews, customers, investors, and media interviews.
- I authored 16 merge requests for the handbook and collaborated with my co-shadows on another ~10. I also created two tasks to track items that were not handbook updates. Approximately half were requests from Sid for the CEO shadows during meetings, and half were ideas that the co-shadows had to improve the handbook based on what we were learning and experiencing. Some merge requests were quite small in effort (5 minutes), and some took a significant amount of time (8 hours to do the analysis).
- Sid asked for feedback a couple of times each week for feedback on how he did, and to ask for ideas from the CEO shadows on the topics that were covered.
- During an investor meeting, an investor asked the attendees a question in one of my areas of expertise: security. I smiled widely on video, which Sid picked up on. He asked me to cover the subject (and follow-on questions) from the investor. It was an excellent opportunity to contribute.
- I joined meetings a minute or two early when possible. Doing so allowed me to network with other meeting attendees who also joined early briefly. Often this was with GitLab team members in which it is uncommon for me to have this opportunity (other than in coffee chats).
Why should a GitLab team member apply to participate?
- You can observe and learn from seeing the GitLab values in action by Sid and the E-Group.
- It is a great way to understand "the why" on how decisions are made.
- The handbook is quite extensive. You can get a sense as to which portions or more or less important based on how often each page is referenced.
- You can better understand the GTM (go to market) strategy and how it guides decisions that impact you and your team.
What are the key things I learned?
In one of the meetings, to paraphrase what someone learning about GitLab's culture said:
You can't train people on a culture. You have to live it to learn it.
Our values guide our actions. Below are each of our values and what actions I observed that reinforced them.
Results
- Our high merge request rate is a competitive differentiator. Our competitors can't release new features nearly as fast as we can.
- Inter-team meetings should be about high impact cross-functional items, not "status on what is being worked on."
Efficiency
- Read presentations and related merge requests/documents/issues in advance of a meeting. Document questions and feedback in the associated notes document before the meeting.
- If necessary, at the beginning of a meeting, go over the highlights of the presentation at the beginning of the meeting. Better yet, record a short video of the highlights and publish before the meeting so that the meeting time can be even more effective.
- When a meeting is planned with those outside of GitLab, document the "Who, What, Why, When, and Where" in advance so everyone can be well prepared and informed in advance of the meeting.
- When you view a multi-page Google document during a meeting and want to see where the speaker is in the document, double-click on their face (or initials) in the top right part of the page. Your cursor will jump to wherever their cursor is in the document.
- Don't be overly regimented about having weekly 1-1 meetings with your manager and direct reports. If you need an additional one because there are important things to discuss that shouldn't wait another week, schedule it!
- In some meetings, there were significantly more items to cover than time available. The team decided to cover the topics in "descending most controversial" order.
Diversity, Inclusion, & Belonging
- An interview with a candidate was nearing the end of the scheduled meeting time, and Sid asked the candidate if they had time to continue. The candidate said they could, but would prefer not to due to having kids at home. Sid decided that the candidate was potentially deferring too much due to being interviewed, so they decided to schedule a follow-up meeting for the next week. Deciding to meet the week after was a great example of "friends and family first, work second.
- Use Zoom in gallery mode, which allows you to see all other participants. Using gallery mode enables you to interpret the expressions and other non-verbal communication (excited, bored, concerned, etc.) of meeting participants.
Collaboration
- Enthusiasm is contagious. For example, there were many instances where people were very excited about topics, including the merge request rate, new features recently released, and plans for future releases.
- The handbook is a guidebook, not a rulebook. Take our values into account when you apply the handbook (and improve it!).
Effective communication
Several topics were discussed asynchronously, especially in merge request threads and Google documents. Observing Sid in action employing effective communication reminded me of these principles:
- Prefer a merge request over an issue. Prefer an issue over a Google document or a Slack conversation.
- It is a judgment call as to when asynchronous communication has become less effective than a synchronous Zoom call.
- Keep in mind that GitLab team members work on many different things. They may have little context on the historical background and your perspective. Provide background and about "the why" to reduce miscommunication.
- Thank people for taking the time to give feedback (especially in merge requests and issue comments).
Responding to feedback
- Be sure to put yourself in the other person's shoes to understand their perspective. Focus not only on what you don't agree on but also about what you do agree on.
- Thank people for giving feedback (especially in merge request and issue comments).
- Be genuine in your response. Don't overpromise how you will address their feedback with the intention of underdelivering.
Want to see some great examples? Look at Sid's responses in GitLab merge request comments, Hacker News threads, and Twitter replies.
Cover image by Chris Montgomery on Unsplash
Guide to the Cloud
Harness the power of the cloud with microservices, cloud-agnostic DevOps, and workflow portability.
Learn more