The Rockefeller Archive Center hosted its first DevOps4Lib summit this year on October 7th and 8th. I’ve written about DevOps4Lib before from the perspective of an attendee, but I, and the Digital Strategies team, have never hosted and facilitated an event like this before. The DevOps4Lib Summit is a two day unconference held for discussion and problem solving around DevOps culture and technology. It runs under the umbrella of the larger Code4Lib community and is a direct spin-off of that larger group. This was also my first time acting as an organizer and facilitator for an event like this, and I wanted to take a minute write about the experience.
Contributing in Community
I think I understood only about six words out of every ten when I first attended DevOps4Lib in 2019. I still have my notes from the first conference, and there’s a whole of annotations telling me to “look this up later.” Now, six years after doing DevOps work, reading about the field, and talking to others in the Library/Archive DevOps community I have a better sense of what I know and how the work fits into the RAC community. Then, in March this year at the larger Code4Lib conference, Hillel asked me if we might want to try hosting DevOps4Lib this year. The idea immediately freaked me out; I’m not a natural organizer and facilitator. Despite my fears, the opportunity seemed like a great way to be more involved in a community that I’ve been leaning on and learning from for years.
For me, the most valuable parts of conferences and unconferences aren’t the sessions, but the connections we make within the community. Volunteering to host felt overwhelming in the beginning, but I also realized the importance of trying to give back to a community that is meaningful to me. If I could use my time to help keep old connections alive, and help foster new ones, it would be worth the stress and worrying. So, I reached out to past organizers, leaned on their expertise (I couldn’t have done it without them), and dove into doing the work of organizing the Fall summit. Additionally, I want to thank the following RAC members for helping make the summit happen before I talk about my lessons in facilitation: Bob Clark, Hillel Arnold, Barb Shubinski, Rachel Wimpee, Brigite Requeijo, Norine Hochman, Roseann Variano, Fernando Carrasco, and Jose Morillo. The summit could never have happened without the largely invisible support and experience of this group.
A Crash Course in Facilitation
Doing the organization work (setting up a website, planning the schedule, messaging the community, etc.) was hard, but it felt like that work had a clear need. I was most worried about creating a welcoming space that encouraged conversation through facilitation. I’m still working on honing my facilitation skills, and this was a clear growth opportunity. It became abundantly clear that facilitation was a learned skill in the lead up to the summit, and during my two days as acting facilitator. There were strategies in past summits to help alleviate the facilitation load (like rotating notetakers, jargon detectors, and timekeepers) that I thought existed just to help but are skills to help people feel more involved and engaged in the conversation. It was my job to help provide a light scaffolding of themes, timelines, and structure to prevent chaos and encourage engagement, which might sound easy, but was more difficult than I expected.
Going into the first day, I knew that my job was mostly to provide gentle guidance for the next two days and to create a space that everyone felt comfortable participating in, but that was easier said than done for me. We had a smaller group of about ten people at the summit this year, and my brain immediately told me that meant we could be more flexible about what we want. However, everyone wanted to stick to the original approach whenever I opened the possibility of diverting from the outlined structure. What I should have done is recognize the importance of the past structure, and its ability to help guide the conversation. It wasn’t my job to have propose new structure, but to model a structure that works for the group, no matter the size. The structure provides a psychological safety that makes sure the group gets to the topics it wants to, ensures newcomers feel comfortable talking, and creates an equitable community.
Additionally, it was important for me to recognize that the past structure had been designed intentionally. The openness to beginner-friendly topics, code-of-conduct enforcement, and inclusive language creates a community that isn’t dominated by the loudest or largest institutions. Any attempt to deviate from that structure could lead us down a path of unintended consequences. Luckily, the group bore with me on the first day, and I think we had a constructive two days of conversation once I settled into my understanding of the facilitator role.
DevOps is People
DevOps isn’t just focused on automation pipelines, containers, and security, it’s also about empathy for people doing the work. And hosting this unconference has taught me the importance of recognizing the work that people do behind the scenes to make human structures work so well. Even small, flexible communities need reliable operations to work smoothly and meet the needs of everyone. Personally, I came out of the experience with a greater understanding of how much work it takes to organize these events, and with a renewed energy in staying engaged in a local community of practitioners. I hope other attendees felt the same! Sustained communities mirrors good DevOps practices: continuous integration of people and ideas all in support of ethical treatment of people as they work in an interconnected ecosystem.