Information sharing at technical meetings (aka “meetups”) consists almost exclusively of presentations. Although we all understand the value of having an expert share expertise with the rest of us, our cultural bias towards one-to-many communication results in many lost opportunities for cross-fertilization of knowledge and cultivation of connections among the group.

In contrast, a many-to-many medium of communication such as a discussion or clinic provides an environment in which knowledge, ideas, and solutions can emanate from, and be received by, anyone.

I am not advocating replacing presentations with discussions. Rather, I am advocating an optimal balance of the two. Where this optimal point falls will depend on the group.

We are all familiar with presentations, so I will mainly talk about discussions and clinics here, and what they offer that presentations do not. First I will talk about discussions in general, and then clinics in particular.

Multiple Sources of Information

It’s rare that a single person possesses all the knowledge in the room. When anyone can speak, we are more likely to get more high quality information. (Of course, we are also more likely to get more low quality information but the group can usually recognize and neutralize it.)

Dialog vs. Monologue

In a presentation, the information is assumed to be flowing in one direction, from the speaker to everyone else. Any discussion is normally for clarification of that unidirectional information flow.

In contrast, in a more conversational medium, people are more likely to participate, resulting in greater depth and breadth of the information flow, as ideas bounce from person to person.


There is a synergy in discussions that is absent in presentations. In discussions, one person’s contribution can raise other questions or responses that can provide better information or lead the discussion to a valuable place that would not have otherwise been visited.

Greater Variety of Subject Matter

Even if a meetup includes two presentations, the topics covered are narrow. Including discussions even for, say, fifteen minutes, makes it more likely that people will find something in the meetup that is more relevant, and therefore more interesting, to them. Imagine, for example, the beginner who attends their first meetup, encounters specialized presentations that they do not understand, and then never returns, concluding that the meetings are “not for them”.

Community Development

People who may have not uttered a word in months of presentations may feel more comfortable doing so in a discussion. They should be actively encouraged, even if it’s to ask a question.

There will likely be “wizards” in the group, members who are recognizably much more knowledgeable than the others. It is natural for the others to feel intimidated and refrain from speaking. Wizards should step out of the way frequently, and the facilitator should encourage everyone to take part.

From discussion springs familiarity, and from familiarity springs friendship and community (not to mention jobs sometimes). It even enhances productivity, in that a relationship has formed such that people will feel more comfortable consulting each other outside of the discussions.

Clinics, in Particular

The clinic is a specialized form of discussion where people share their problems, challenges, and discoveries.

The key benefit of the clinic is that participants are likely to receive the information that is most valuable and helpful to them at the time.

In addition, the entire group is involved in finding the solution. Everyone is “on call”. This can result in greater engagement and energy.

I describe at the bottom of this article my experience facilitating an internal organization Ruby clinic.[1]


The clinic can be totally free form, but I recommend a meta-discussion at the beginning where people describe the topics they would like to discuss, and the group plans the discussion schedule. This is kind of like the opening of an open space conference but on a micro scale.

Advance Notice of Topics

It can be helpful for the group to propose topics in advance of the meetup. This has the following benefits:

  • ambiguities can be resolved before the meetup
  • some of the session planning can be done in advance
  • people can research the topics in advance
  • opportunities to refine or combine topics would be identified earlier


It’s helpful to have a shared screen. This is automatic if you are using collaboration software, but if you’re in a physical room together, you’ll need a projector or large shared monitor to be most productive.

Whether you have a single machine which will be shared by everyone, or everyone uses their own computer, I recommend bringing a wireless keyboard and mouse to the clinic; it lowers the barrier for other people to take the driver seat.

Level of Effort

One of many great things about clinics is that they require zero preparation. The group may want to propose topics in advance, but it’s not absolutely necessary.


At minimum, clinics can be used as a fallback activity when unable to find a speaker. However, I would argue that having a clinic for part of every meeting would be valuable and interesting for most groups.


There is no real minimum time, nor a need for its own sake that the time be consistent from meeting to meeting. For example, if a meeting normally has two presentations, the clinic could be limited to fifteen minutes. If there is only one presentation, the clinic could be expanded to fill that missing speaker’s time slot.

Clinics for Dev Teams

Clinics aren’t good only for meetups – they can be even more valuable for development teams, where in addition to the shared languages and frameworks, they work with the same organizational code base and environment.

Cautions and Counterpoints

There is a risk that the clinics would gravitate towards beginner issues that would bore the more advanced users, or advanced subjects that would be incomprehensible to the more beginning users. Facilitators need to keep a close eye on this. If it’s a short clinic this might be fine, but if it’s a substantial portion of the meeting, it could drive people away. Other options could partially replace the clinic, such as a supplemental beginners meeting once a month.

The topics chosen (if there are enough to select from among them) could be selected to balance against the presentation. For example, if the presentation is very advanced, then the the more beginning clinic topics might be selected for discussion.

Darin Wilson points out: “The Q&A format can be good, but I think you have to put some effort into managing group dynamics. The trouble with any Q&A session is that they self-select for folks who are comfortable speaking out loud in a group setting. The larger the group, the more pronounced this effect will be. Also, if you have one or two individuals who really like to hear themselves talk, they can end up dominating the discussion. If you have a smallish group that already knows each other, this can be easier to manage. But if you have a larger group and/or folks don’t know each other very well, the moderator will probably need to make some extra effort to make sure that everyone feels welcome to participate, and that the discussion isn’t dominated by the over-talkers.”

I agree that this is definitely something to look out for, but more applicable to general discussions than clinics. If the goal is to provide solutions, then there may indeed be a couple of experts who possess most of the relevant information. The facilitator needs to balance the need for solutions with the need to cultivate universal participation.

Joseph Glass says: “I’ve found clinics to be very engaging but they also require more “crowd management”. With a well-prepared presentation, the quality largely depends on the speaker, and will be pretty much the same wherever it’s presented.

“Clinics on the other hand depend on the quality of the participants. It might turn out to be a fantastic conversation of people sharing expertise and forming connections. Or maybe one over-talkative participant will hijack the conversation into irrelevant tangents. It can be a bit of a gamble unless you know the community you’re working with or have a really good moderator.”

Indeed, a really good moderator is the key. Perhaps that is a whole ‘nother article. Anyone want to write it? :)

Philippines Ruby Meetup, January 2020

I suggested experimenting with this clinic format to the organizers of the Philippines Ruby Users Group. They agreed, and roughly half the meetup was allocated for it.

It turned out that only one person had a question, and several people answered it in complementary ways. Then there were no more questions. What to do? We morphed it into a general discussion. It was all engaging and interesting. Sometimes things don’t go the way we expect. That’s ok, we can adapt.


I describe in this article a formula that has worked for me, but of course there is an infinite number of combinations of attributes of a clinic, and your optimal mix may differ from mine. Any discussion can be engaging and informative, but for me the essentials of a clinic are:

  • help people get the information they most need at the time
  • strive for universal and balanced participation
  • balance the mix of levels of expertise for the questions within the clinic, and with the presentations

Presentations definitely have their place. There really is value in someone who has deeply researched a topic sharing their knowledge with the group. However, meetups can be improved when the one-to-many information flow is supplemented by the many-to-many flow provided by discussions in general, and clinics in particular.


[1]A few years ago I was working at a network services company. At the time, they were automating their software testing to use Ruby and Cucumber. There were whole teams of software testers new to those technologies, and even programming in general. They were provided training, but after that training they were on their own. In addition to my own assignments to write software, one of my tasks was to help them get more productive in their programming.

They would sometimes come to me when stuck, and when they did, I dropped what I was doing. It felt great to help them, but I knew they needed more than just firefighting to be really productive. I was unable to get authorization for us to devote the time we needed for more intensive collaboration, so I scheduled weekly Ruby lunchtime “clinics” on our own time. People shared their challenges, questions, and conquests. We met in a meeting room with a large shared monitor. I brought an external keyboard and mouse with me for use by whomever was “driving”. At the beginning we had a discussion of topics to cover. That gave me the information I needed to optimize the use of our hour together.

I encouraged them to show things they had learned, and to help each other. As time went on, their knowledge grew, and to my delight this happened more and more often. These sessions were my fondest memories of working there.

This article may be improved over time. To see its revisions you can go to its Github commit history.