A Magical Meeting Story from Designer, Builder and Speaker Jonathan Berger
Welcome to Magical Meetings Stories, a series where I chat with professional facilitators, meeting practitioners, leaders, and CEOs across industries about their meeting culture. We dive deep into a specific magical meeting they’ve run, including their approach to facilitation design, and their tips and tricks for running meetings people thrive in.
Today’s story is with Jonathan Berger, co-founder, and EVP at Let the Music Pay. He designs and builds products and teams. His tools of choice are design, development, and copious amounts of communication. Jonathan has spent the last few years working at the intersection of design and development, which often puts him in a product role on Agile teams. These days he spends most of his time in a text editor (Vim) or Adobe Apps (Illustrator), but in past lives, he’s also been involved with animation, video editing, politics, writing, and critical theory.
This story is a little bit different from the others in the series in that it’s not about a single meeting, but rather an effective default meeting schedule (or recipe) Jonathan utilizes when building teams. Applying this “responsible recipe” to your meetings will result in minimizing wasted time, maximizing maker- time, and makes for a nice scheduling default for projects.
“If you need people to prep for the meeting you’re doing something wrong. Prep time is theft time.” – Jonathan Berger
Protect Makers’ Time
Jonathan and I spoke about his meeting format and what originally prompted it. He created the recipe when he recognized, over and over, that a team would try to figure out problems that other teams already figured out. He explained he comes from a place of “the realist ideology of Convention over Configuration.” He identified that many teams were trying to reinvent the wheel, and individuals would bring their own personal experience from working on teams and attempt to reach compromised democracy. Instead of wasting all this time, he saw an opportunity to minimize trivial decisions and avoid expensive negotiations and put a productive structure in place in order to save valuable time and resources (and keep projects moving). “We see this kind of existential threat to developers of being pulled away for other stuff because they’re smart and interesting and have answers to a lot of things, and they don’t have natural defenses around protecting their time,” Jonathan explained.
The overarching purpose of this meeting recipe is to protect makers’ time (in this case, primarily data scientists, software developers, and designers), and recognized they didn’t want to spend all their time sitting in meetings when they could be working on their actual projects: “So the responsible recipe is the output of that. The responsible recipe says ‘Hey engineers, makers, if you give me three hours a week to do the kind normal administration, I will give you back 37 work hours a week to do your thing. And this will be sufficient. We know there are exceptions, and occasionally you’ll be pulled into a few extra meetings. But as the normal standard operating procedure, this is the promise to you: that if you give me three hours, we can run an effective team that can respond to change, that can be responsible, that can do all the right stuff.’”
Let’s take a closer look at Jonathan’s meeting recipe to learn what makes it magical.
The Responsible Recipe
Below is the structure Jonathan found that keeps meetings to ~3 hours total (or ~7.5% of the workweek), minimizing waste and maximizing making time. More information can also be found on his blog post on the same topic. The structure consists of 3 different types of meetings and is based on a typical two-delivery team, generally aligned around a single backlog and including 2-6 engineers, a designer, and the product owner. This format can work in-person or virtual (or a combination), depending on where your team is located.
Prep Time is Theft Time
As opposed to many other meetings, this format has an anti-emphasis on homework and pre-meeting prep. “If you need people to prep for the meeting you’re doing something wrong. Prep time is theft time,” Jonathan says. If someone commits to a 45-minute meeting, it goes on their calendar and subtracts 45m from their workweek. In if there’s, say, 30m of pre-reading, does that make it onto their calendar? Or do they squeeze it in during the time that should be spent working (or, more often, not at work at all)? He believes they shouldn’t have to also commit to an additional 30 minutes of meeting prep that isn’t on the calendar. If meeting prep does need to be done, he recommends scheduling a 15 minute (or however long is necessary) study hall as a convenience, for the work to be done then. “This way it’s on your calendar and not this weird ghost time.”
The Meetings
1. Daily Standup: 5x weekly, 10 minutes each
This is a short, team-wide orientation meeting. Three quick questions are covered each day:
- What did you do yesterday?
- What are you doing today?
- Are you blocked on anything?
2. Iteration Planning Meeting (“IPM”): 1x weekly, 60 minutes each
The IPM is a weekly tactical planning meeting. Its aim is to ensure that the backlog is in good shape and that all the team members are in alignment. Ideally, the meeting is on Monday, and questions like the following are covered:
- What are we going to do this week?
- Do we have a shared understanding of the requirements in this week’s tickets?
- Are we all aligned?
It’s not a meeting to assign work, but rather a coordination meeting that allows any given engineer to pick a story off the top of the backlog, and for the team to be confident that it will be executed in a sufficiently consistent and meaningful manner.
3. Friday Afternoon Meeting: 1x weekly, 60 minutes each
Jonathan started doing traditional Retros every Friday but found this Friday meeting to be most useful when rotating among three meetings: the Team Retro, the Tech Retro, and Release Planning. Whereas the IPM is very tactical, the Retro meetings are more so reflective – a time to look inward and/or vent. In general, successful teams tend to need that not as frequently as every week, which brings in the third rotating Friday meeting: Release Planning. The purpose of this meeting is to zoom out and look at the 30,000-foot view of big projects and goals. Below are more details on each meeting from Jonathan’s blog post:
Week 1: Team Retro
The Team Retro is a chance for the day-to-day members of the team to reflect on how things are going, celebrate successes, voice frustrations, and suggest Action Items. While there are plenty of variations, the classic Retro format is to throw three columns on a whiteboard:
- “Smileys”, or things that are going well, represented by the expected emoticon 🙂
- “Frownies”, or things that are going poorly, represented by 🙁
- “Mehs”, or things that don’t fit cleanly in either category, but bear mentioning :-/
After ~25m of going around the room and throwing out Smileys, Frownies, and Meh’s, the team might spend a few minutes identifying items that have a common theme, and then spend the rest of the time suggesting action items, either for each item (starting with the Frownies) or, if time is short, on a theme-by-theme basis. The action items are recorded and assigned to individuals, and their progress is followed (often at the start of the next Retro).
Week 2: Tech Retro
A Tech Retro is for and by developers. While pair-programming is essentially continuous code review, it can still be useful to take some time to step back and look at the codebase. Tech Retros often take the traditional “Smiley / Frownie / Meh” format but focus exclusively on the codebase. This is a great time to talk about modeling decisions and suggest refactors. Often the action items resulting from tech retros are a long list of chores. Try to keep each one to a manageable size, and make sure at least a few of them make it into the backlog for the next iteration.
Week 3: Release Planning
“Release Planning” means different things to different Agilists, but in this context, it’s a loose title for a long-range planning meeting. While the IPM is a short-term tactical meeting, it’s important to occasionally step back and look at the big picture. What are the product’s medium- and long-term goals? Are we on track? What should our next milestone be? The Release Planning should be attended by the whole team, and by the stakeholders like clients and CEOs who may not be part of the day-to-day workings of the team. It’s a chance to review epic story tracks, dates and deadlines, and to make sure that everyone has a shared vision of where the team is going—and that it’s a place worth going to.
What Binds the Recipe
Jonathan and I also discussed what makes this meeting recipe possible. Jonathan cited a few things: trust, psychological safety, and that it won’t work in an adversarial or non-maker context. It’s not going to work in a phase of a project that is very oriented towards discovery or framing, he explained, and that it’s most effective at delivery phases for teams with a consistent amount of effort. Teams who know what they are, and aren’t changing or reorganizing weekly. It also requires a consensus around methods (or at least a willingness among the team to try a method with minimal debate) and isn’t stuck in long-term investments or slow to change. The team and team members need to be able to have relatively short iterations, he explains.
Outputs and Results
I asked Jonathan about the specific deliverables and outcomes from this meeting format. The main positive output is a delivery team that can focus on delivery, which minimizes overhead and reduces risk. Going back to the makers, Jonathan notes that so much time is wasted in internal communication and meetings because the makers would rather be making. The management side also depends on the delivery team being effective and hitting their targets, so they benefit as well.
Best Practices for Facilitating Retros
Jonathan and I also chatted about another blog post he wrote which goes into more detail on facilitating Retros: 7 Best Practices for Facilitating Agile Retrospectives. In summary, these are the 7 best practices he outlines:
- Explain and Enforce Format
- Write Everything Down Verbatim
- Categorize Carefully
- Action Items Should Have Intent
- Action Items Should Be Falsifiable
- Action Items Need a Single Responsible Party
- What Happens in Retro, Stays in Retro
Potential Pitfalls
I asked Jonathan about any potential pitfalls or risks of this meeting approach. He said there’s a risk that it can be interpreted as too rigid, and highlighted the importance of keeping the intent (protect makers’ time with as few administrative meetings as possible) and flexibility (the meeting recipe can and should be customized to each team’s unique needs for the best chance of success).
He also called out that there’s no built-in mechanism to correct for distractions – although the idea behind this meeting recipe is to avoid distractions, they may still creep in and if they do, there’s no mechanism to explicitly call them out.
Pride
When I asked Jonathan what makes him most proud about this meeting process and the recipe he said:
“I think I’m proud of how fractal it is. The principles that it employs to engender good communication among these other meetings are the same principles that drive the composition of this as a technique. And to get away from the super abstract to the really critical. I’m very proud of the fact that it makes people happy and effective.”
Looking Ahead
We ended our conversation on my favorite topic – what he would do next if he were to be extremely bold. He says he would want this recipe and meeting structure to be better known and branded because while it doesn’t solve every problem out there, it is a real, healthy solution with an equilibrium point. Hopefully, this conversation inspires other teams out there to start implementing and utilizing some of Jonathan’s meeting recipe in order to drive less wasted time and more making (and maker) time.
Do you have your own Magical Meeting Story to tell?
We’d love to hear your wizardry! Share how you are creating magical moments in your work below.
