Evolving Communication Structures With Exponential Scheduling
One of my challenges at Nuna has been setting up team-level communications structures in the face of uncertainty. Going from 0 to 1 means that our understanding of the problem constantly evolves, and with that, our communications structures need to evolve with it. I've managed to grapple with that change through an approach I call exponential scheduling.
Exponential Scheduling
The basic idea of exponential scheduling is simple: whenever we see an opportunity to refactor our communications structure we try a small change, and then repeat that an exponential number of times until we've reached a happy medium.
In practice this means that when we see a communications gap we don't start by putting a hour-long meeting permanently on people's calendar. Instead, we talk for a few minutes, and form a hypothesis about how to fill that gap. Sometimes this means starting a weekly meeting, but other times it has meant sending out a semi-regular newsletter. For the purposes of this article, I'll assume it means setting up a weekly meeting.
Once we have our hypothesis, we try it for 1-2 weeks, and we ask ourselves "was that useful"? If so, we extend it out to 4 weeks and revisit. After that, we do it again, this time for 8 weeks. Finally, after 8 weeks, we make it a recurring part of our schedule.
We can do the same thing in reverse. If we notice a regular meeting has been thin on content, we won't pull it off the calendar, we'll halve the frequency, make a note to revisit in a month, and let that run for a couple iterations. If it's still thin on content, we'll re-evaluate and remove the meeting altogether.
Why I Like This
The biggest reason that I like this is it makes it easy to try out new communication structures. Adding recurring meetings is often met with "ugh, another meeting", and removing them can be met with FUD about the impact on team cohesion. With exponential scheduling, we can mitigate both of those by defining a small, reversible experiment with a clear re-evaluation path in case we're wrong. This helps us capture the upside of making the change, while mitigating downside-risk if we're wrong.
The other advantage with this approach is that it helps prevent calendar overload. In order for a meeting to stay on the calendar as a recurring event, it needs to prove its value 3 times over the course of a quarter. This helps prevent calendar inertia from accidentally filling up peoples' time.
When is this the wrong choice?
As with all tools, this one doesn't solve everything. In particular, this approach doesn't work so well if you are undergoing a re-org and the fundamental structure of your team is changing. In those cases, it's probably worth setting up a default comms structure and then evolving.
Another time when this approach struggles is if the experiment means trying out a new structure or learning new skills. In these cases, the first couple of tries may feel a little bit chunky as you work out the kinks. If you anticipate that happening you can still use this approach, but make your initial experiment longer and set expectations accordingly so that people don't give up after the first iteration.
I'd also speculate that this is the wrong choice is if you're in a position where there are multiple, interlocking communications problems and the incentives are not obviously aligned around fixing them piecemeal. In those cases, I'd speculate that the move is to find a decision maker and work with them to fix the underlying problem. However, that feels like an extreme move, and one that I've never had to use.
Overall, I've found that much like incrementally refactoring your code with small changes, incrementally refactoring communications structures with small experiments has been very useful. It has allowed us to set up resilient structures and has prevented us from accidentally locking in long, useless meetings.
Discussion, links, and tweets
Hey! Thanks for reading! If you like what you read and want more, you can follow me on Twitter.
Tweet Follow @maltzj