README for Bryan May (He/Him)

Who I Am

I am from Central New Jersey, USA. I have degrees in Computer Egineering and Software Systems Engineering. Early in my career, I worked with the US Army as a Civilian at Fort Monmouth, NJ and Aberdeen Proving Ground, MD. I have a patent from my time working as a civilian with the Army.

I transitioned to the private sector in 2017 with Verizon, where I was working as product owner for the enterprise devops platform. During this time I had awesome exposure to enterprise problems including App Modernization, Cloud Migration and DevOps Transformation. I helped manage the complete rollout of GitLab including data/user migration and infrastructure deployment. I built a communication plan for 10K+ developers using the enterprise SCM tools.

I am a student of Agile and DevOps. I have had exposure early in my career to waterfall and painful multi-year lead-ups to integration and testing events that never went to plan. These experiences ultimately drove me toward a career in the DevOps Community; and for this, I am grateful.

What to Expect from me

My Role

I am the leader of the Global Engagement Management organization within the Professional Services department at GitLab. We are responsible for the Global services go to market motion, helping account teams and customers accelerate to value realization and de-risking their journey with GitLab. I'm grateful to work with a team of professionals who have industry expertise to ensure high quality of delivery and amazing results.

My ultimate goal is to help our customers win in the marketplace. They can do that by investing in professional services as the services we offer are of extremely high value when compared to the opportunity cost of embarking on a journey without the expertise and experience of the PS team. My mission is to ensure that GitLab PS brings to market increasingly valueable service offerings to ensure we're able to help customers from all segments and regions. This means making sure we have the right service offerings in place with the right partnerships to sell and deliver them to our ever-growing number of customers.

How I work

I tend to start around 8am ET and officially finish aroud 5pm ET on most working days. I sometimes hop back on after 7:30pm to review west coast team members pings/questions, etc but I'm striving to not do this as much as I can to lead by example of setting work/life boundaries. I check email periodically usually once in the morning and once in the afternoon. I am most reachable with the shortest response time on Slack.

On a daily basis, I use the following workflow:

1. review open slack mentions and posts on certain channels (continously throughout the day)
2. review gitlab todos (usually a few times per day in between meetings)
3. review email (once or twice per day)
4. review personal backlog - I keep this in an offline note. These usually have links to docs or issues, but its my way of keeping track of the in flight items that might exist across technology platforms (g suite, gitlab, email, slack)

I'm a big fan of the documentation-first collaboration technique that GitLab has helped coin. And I really hold transparency as a core personal value, so I'm happy to collaborate on an issue, MR, or google doc (taking notes in real time). I think during initial brainstorming sessions, docs are better than issues as many people can collaborate in real time. Once we have some actions and an idea formulated, I apprecaite using gitlab issues and MRs to ensure we can track them to completion and effectively collaborate with each other given our geographically distributed nature.

Working with me

• If you need my immediate attention on something, at mention me in the most relevant slack channel (avoid DMs and group DMs when possible)
• If you haven't gotten a response from me in over a day on a GitLab issue, google doc mention, etc - at mention me somewhere in slack.
• Please try to refrain from using slack DMs unless there is something sensitive that shouldn't be known by a large crowd. I prefer to discuss in open channels to enable others to have awareness of what is happening around them.
• When brainstorming ideas, building diagrams, creating proposals, etc. please link to the notes doc, issue, or slack thread where the topic first came up. It i important for me to have cross-linked information so I can be efficienct with my time and yours.
• I value continuous improvement, so if there is something that I can be doing better to work with you, please let me know. I love hearing constructive criticism.
• I am an analyst/architect personality type, which can be useful to know when working with me.
• Want to get to know me better? I would love to have a coffee chat! Just slam it on my calendar within my working hours and I'll be there.

Reading List

This list of books has helped me arrive at the role that I'm in today. Its a mix of devops and product management references from thought leaders in the industry.

• Never Split the Difference: Negotiate Like your life depended on it by Chris Voss
• Lean Product Playbook by Dan Olsen
• The Unicorn Project by Gene Kim
• The Phoenix Project by Gene Kim
• Investments Unilimted
• Inspired: How to create Tech products customers love by Marty Cagen
• Sprint: Solve big problems and test new ideas in just five days by Jake Knapp (I haven't actually read this, but the concepts are summarized here: https://www.gv.com/sprint/)
• Measure what Matters - OKRs by John Doerr
• Mindset: The new Psychology of Success by Carol Dweck
• Project to Product by Mik Kersten
• Making Work Visible: Exposing Time Theft to Optimize Work & Flow by Dominica Degrandis
• https://www.producttalk.org/ is a great blog by Teresa Torres about product discovery.
• Opportunity Roadmaps is a blog post about how to shift the thinking about roadmaps from features to opportunities
• Anything by Malcolm Gladwell
• The DevOps Handbook by Gene Kim and Jez Humble