Day One
This is my first DevOps Days and third conference overall. It is the first that has caused me to really engage with my peers at a conference and get involved in discussions. The “open spaces” concept that most, if not all, DevOps Days have was a new experience for me, one that initially left me, a stoic introvert, slightly anxious.
Today there were three sessions, and in each that I attended there were roughly 10-20 people involved. Each session started with the facilitator introducing what their idea for the space was and giving a little background on themselves, after which we would go around the room (always clockwise amusingly) and introduce ourselves and what we each hoped to get out of or contribute to the discussion. I attended first a discussion on DevOps culture, an aggregate group encompassing team building and the cultural challenges involved in bringing about change in large corporations. I spent most of my time in this session silent, outside of my brief introduction as a small company employee constituting half of the DevOps team. Outside of some initial venting about company politics and glacial pace of changes, there were some genuinely interesting concepts and problems presented around managing management, getting buy-in from the engineers, and slowly implementing change from the ground up and from the top down.
The second session I attended was a smaller group, and one that I felt I had a bit more of a personal association with. This session was around mentorship and on-boarding, and heavily focused on both sides of the mentor/mentee relationship. This topic was quite interesting to me as onboarding has been an important topic to me lately.I feel it is a key component to early retention work; if you can’t get people up to speed and make them feel welcome in a new role, you have little hope of retaining them unless they survive the trial by fire that a lack of training usually entails.
The rest of the group was focusing on the problems around mentorship: how to structure the relationship, how to handle differences in personality and conflict, how to work with peers and management to ensure that there is an understanding about how the mentor’s work output will be impacted. I, having never really had a mentor figure, was kind of surprised by how prevalent this practice evidently was. One of the group was in charge of mentor assignments for her organization and was able to go into the formal structure that they had established, which was quite interesting. Mentors and Mentees were initially assigned at random, with the understanding that they could, with no risk of repercussion, request a new mentor for any reason.
I was particularly surprised by the responses when I asked about how in-depth and involved the mentorship programs were, as I had been thinking of them as a bootstrapping process to on board new employees, not an ongoing career development role. One participant said that her organization expected at least an hour a week of mentor time, while another went over how her group had a more formalized multiple times a week system, including an informal lunch session to review progress. I am not sure how I can apply these learnings as of now, it would be tough to attempt this at any kind of formal level within an engineering team of our current size (20ish total).
The third open space I attended turned out to be the most interesting for me, as I was the only participant with zero experience in the matter and was surrounded by some of the people who literally wrote or are writing the book on the subject. This space was around blameless post-mortems and the end of root cause analysis. The core ideas are very familiar to me, I have been reading a lot and listening to podcasts with a wistful sense of ‘Wouldn’t that be nice’. This open space ended up being essentially some discussion of in-depth talks, while mostly focusing on explaining the core concepts and pitfalls directly to my exact use-case: initial implementation in a growing organization and working to effectively encourage buy-in across the organization. These conversations gave me a handful of new ways to think about approaching blameless postmortems and incident response as a whole in my organization. I think the first step is going to be identifying incidents that warrant an attempt at a postmortem initially and from there working towards formalizing the procedure. While I think tooling will help this, I think that might be part of a bigger shift to alerting/monitoring/incident reporting unification.
Overall I was rather pleased with my first DevOps Day experience. The talks were well put together and though provoking. The ignites brought me back to my days of running AV for CRYPTO and their drunken ‘Rump Session’ at 9PM the second night of the conference. I think the big winner for me was the engagement from the open spaces, but that’s something everyone says after attending a couple. I am excited for day two.