Honeycomb’s Kelly C. Gallamore on Open Space-Style Discussions

• 

  Ted CarstensenPlatform Director
  Heavybit

In this Q&A, we hear from Kelly C. Gallamore, Marketing Associate at Honeycomb, about Open Space-Style Discussions and their impact on events and conferences in the developer tools space.

Tell us a little bit about yourself, where do you work and what are you focused on these days?

Kelly: I jumped into the hive over at Honeycomb last spring, and I landed in Team Marketing. Like any small company, I help with many aspects of marketing, but my main focus is the world of events. I am the lead organizer for o11ycon. My first attempt at a career was as a Cinematographer. I love storytelling and building community by making stories and/or adventures.

What is OSSD and where does it come from?

Kelly: o11ycon2018 was an emergent one-day conference. Our main goal with the short time that we had was to bring the hallway track front and center. To do so, we borrowed, begged, stole, and liberated from Open Space Technology (OST). This meeting style gathers a bunch of humans around a root idea, gives them space to self-organize and develop their own meeting agendas under the umbrella of that idea, breakout into groups to discuss these ideas, and finally collate a set of findings and/or calls-to-action to share with the whole community at the end of the day.

o11y
adjective | ol·lee \ ˈä-lē \
Definition

1. a measure of how well internal states of a software system can be inferred from knowledge of its external outputs
2. a cognitive philosophy and practice of asking questions inside software systems to elucidate how those systems are actually functioning

The 1’s in o11y are pronounced like olly or ollie. This truncated word is an homage to a11y [accessibility in software].

Team o11y chose OSSD, an acronym for Open Space-Style Discussion. We experimented with the skeleton of OST, bringing some discussion prompts and clear time-boxing to our day. We want to celebrate the power of enablement that is possible when a group self-organizes, but we also wanted to drive as much discussion as possible to actionable goals and findings under the umbrella of observability. OSSD is our flavor of OST.

We invited a bunch of passionate, adventurous, intelligent, capable people together to one kitchen, but our team did all the grocery shopping beforehand.

Here are some reference materials that we studied:

• Open Spaces Technology: Wiki
• The World Cafe
• Some Chef guides to Open Spaces
• This video on Open Space Technology

In your view, what are the ingredients for a successful OSSD session?

Kelly: Team o11y held several practice sessions in order to best enable our volunteer facilitators for o11ycon. We had some great success with how we did that, but we also have room to improve next time. We used the following tools to best enable these sessions:

• Set the tone of discussion culture at the beginning of the day
• Meeting zones with analog means of note-taking
• Internet for digital note-taking
• Notebook and pen to encourage humans to get their noses out of their laptop
• Playbooks for facilitators
• Dedicated facilitators for as many sessions as possible to make space for healthy discussion
• A digital forum (we used a shared google drive) for uploading findings, complete with an easy to use template slide
• A time-boxed session at the end of the day for one person from each group to share 3 minutes with everyone about their discussion

These are the resources we built for our OSSD, for facilitators and participants overall.

I have to credit Rachel Fong and Chris Sun, my teammates at Honeycomb, for generating most of the material in those resources. Art credit for o11ycon and the OSSD slides goes to my teammate Chong Han Chua. Rachel Chalmers, our o11y MC, set the tone for the day at o11ycon.

What should organizers look for to know if they were successful or not?

Kelly: Data.

Getting data from our attendees is one metric we have for success. We shot out a feedback survey shortly after the event. We got some full support for some things, and we got good ideas for how we can improve next time.

Another key component for me for measuring success comes from the expectations in the first place. We had about 150 humans in the room at o11ycon. Looking around the room, I saw many many people actively engaging in conversation. People hanging out in the “hallway track” were few in number. The hallway track was the many discussions. Few people were on their phones or laptops. I saw smiles, laughter, and art-making.

While I had hoped that would happen, my expectations were set to observe and find what kept them from playing the game. To me, the day was a success based on the amount of active participation alone. For the future, we only seek to enable that more. Especially the art-making. Art-tifacts are powerful.

Another way that I know we were successful: the findings session was interesting and engaging. Because of the mechanics, more people at the conference actively participated as voices for their groups.

Team o11y may have brought the groceries to the kitchen, but the ones who did the real work were the people in the room.

They brought their brains, they played within a format, they contributed to a common group goal. For me, that sharing is success for all of us.

Have you implemented OSSD before your work at Honeycomb?

Kelly: Personally, I have been participating in groups or meeting like this for a long time. I just did not have this name for it. I come from an arts background: big art, small art, paid art, volunteer art. Art that is a movie, art that has a script, art that is just a bunch of people coming together to do something, only to make that something up once they come together. From my art background, and from some training as a public speaker, I like to gather humans to brainstorm. From that brainstorm, I like to drive the group to a common goal with a set of actionable tasks that we can share (or for which we find resources).

I love when groups enable themselves to identify problems, identify solutions, and implement solutions.

To me it is the ultimate celebration of chaos… to try to take control of chaos and ride it knowing failure is a given.

Are there any common mistakes or failure modes to avoid?

Kelly: When a house is literally on fire, the OSSD tactic is a less efficient form of discussion. Harrison Owen, whom the internet recognizes as the lead developer of OST, has two really solid, short paragraphs about when not to use OST in his brief user’s guide, and I agree with him.

OSSD’s are really meant to bring people together over a common goal or problem that needs creative examination – when the course of action is unclear to the community. Sticking to the goals of bringing together people who are passionate about an agreed upon topic (or umbrella), facilitating breakout space in which these humans can break apart the topic and discuss/explore/find differences or commonalities over those pieces, and letting them self-organize to reach goals or calls-to-action to help push that community forward… that backbone can make for a successful OSSD event.

While the four principles and one law of open-space technology discussions are important to this format, we rooted our day with the following ground rules to set a tone for the community:

If the larger group contains people who will use language that shames, push their way into hogging the mic and hogging space from others, and are there with defensive attitudes, the discussion will not be successful for the community. They will disintegrate the community.

We found that setting the ground rules and having dedicated, empowered, practiced facilitators for as many groups as possible enabled more healthy, productive discussions.

Is there anything specific about developers and developer communities that you think allows OSSD to be successful?

Kelly: I am not a developer, and I have never been a developer. With that in mind, one thing I have learned about developers is that they tend to be a class of creative people who use their skills to build automation and systems to ultimately solve problems. They have to be creative to continually try to build new solutions. In all of my life experience so far, I find that for any maker, creator, builder, human who is a problem-solver, there is one key component that can make that problem-solving most efficient and successful.

The healthiest start for problem-solving is to correctly identify the problem in the first place. I get the feeling that developers know that to be true.

I understand that there is a work culture around developers that is often unhealthy, and that needs to change. That concept is literally what I get from @mipsytipsy and her reasoning behind building an observability product in the first place: developer work-life has room for improvement. Ownership of software is one key mentality that needs to shift to make work better for engineering teams overall.

As someone who has worked in the heavy-lifting, below-the-line, oft-misunderstood (by top management and audiences) world of filmmaking, restaurants, and other startups, I know that culture changes come when groups organize well, identify the actual problems, and break the changes into actionable digestible chunks. OSSD is a format to bring developers together, with each other and with other engineers, where the path to break down cultural problems in software development is not yet completely clear for all who need to be involved. It’s a format that can jumpstart, enable, and empower a community.

Like most humans, I think developers want to be heard. Their collective experiences and feels, when given a forum to be heard, can contribute greatly to community solutions and changes in culture. I also think that I understand the developer community is pretty tight. If part of that group believes in the momentum from a successful OSSD, they can help it grow.

OSSD is merely a garden. It’s up to the people who participate to help it grow and be productive. Developers, to me, seem like great gardeners.