Achieving good Rhythm, a well-tuned distribution of "feels good" across time, is at once the most visceral of sensations and the most difficult to reliably prescribe.
Affecting rhythm, therefore, is a fundamentally experimental effort.
There are three broad levels to think about, and each has its own possibilities and limits. There is the individual maker, a team of makers, and an organization that hosts, funds, plans, and manages that (or those) teams.
At the outer circumference, the org has the fewest possibilities for positively influencing rhythm and the most possibilities for negatively influencing it.
I know some senior execs who’ll take this idea hard, but it’s pretty obvious: you can’t tell people when to "feel good".
Instead, at the org level, your greatest impact comes from your ability to provide support, including but certainly not limited to the fiscal, for your teams and your makers to find and form the rhythms that work for them.
I want to offer a couple of ways the org can negatively influence rhythm before I throw out a couple of ideas for positively doing so.
- Mandating regular synchronized cross-team structural meetings, the hardware of Scrum’s sprint, say, or quarterly hold-everything-while-we-release-train, these might be easier for you, but they’re a disaster for the rhythm of the teams and makers under you.
- The reliance on regularly scheduled "all hands" sessions, I’ve seen these on a monthly basis, is also a major rhythm-breaker. These are often coupled to a goal of "purpose", which we’ll speak of later. Use them sparingly, if at all, and not on any particular schedule.
These two techniques are common. They both mistake "meter" for rhythm. They both orient towards convenience for senior staff at the cost of powerful demotivation for everyone below them. They are "idols of the schema", ideas that are great in the abstract and deadly in real life.
What about some positive influences at the org level? Here, again, are a few ideas for you to think about. It’s just a few, and I’m just going to sketch them. You can likely do better than these. The secret sauce: wanting to.
- Drop org-wide onsite hour requirements. If individual teams need core hours, let them do it, not you. Ship every work machine already rigged for remote work and remote conversation, including camera and headset.
- On Monday afternoon, give 90 minutes to an outside presenter — your community bristles with people willing to do this. Voluntary & remotable. Topics can range all over, but I’d aim for roughly a quarter of them to connect to "humans finding delight while making something".
- Create adequate and varied downtime space, and encourage its usage. Varied includes: gaming space, resting or meditative space, project space, and food space. Provide budget for decor, and hand it to the teams freely.
Again, these are just a few ideas. Emphasize experimentation, voluntarism, and a strong support for people finding their own best rhythms, not fitting in to some other person’s idea.
Let’s talk about what individual makers can do about rhythm, we’ll come back to teams in a second. Here, of course, we get far more active, less cautious, and inevitably both more intimate and more technical — these are makers we’re talking about, and that’s how that is.
- Take time to explicitly reflect every couple of days about when and how you got "feels good" at work. (If you haven’t "feels good"ed in three days, become concerned.) You can’t change what you can’t see, so you have to make an effort to pay attention.
- Try TDD, if u haven’t, in a special way. Do it on a leaf dependency class. If you don’t have a leaf class, learn how to make one from your current code focus — that’s a little harder, but ask me or one of the others about it. TDD is full of rhythmic "feels goods".
- Try a couple of arbitrary celebration techniques and see what happens. Walk around the block. Or go see one of your friends in the org. Or watch a work-irrelevant video. Anything that feels like a small reward, once every couple of hours.
- Need a break but feel guilt? Go pair or mob, doesn’t matter what the code focus is. Ride along on someone else’s juice, and get a "feels good" when we get a win, rather than just yourself.
- Take a small chunk of work, a story, maybe. Don’t jump in, but take some time to break it out to a list (or tree) of steps. Each step you cross off will give you a "feels good", instead of delaying it until story completion.
As before, these are just some of the things you can do to find the right distribution that works for you. Experiment, lots and lots of experiment. Reflection, lots and lots of reflection. Do this for a couple of weeks, and you’ll have a pretty good grip on the rhythm you need.
We come to the team level. As you might expect, it’s a middle ground. The team space is the natural place for us to build culture, and the domain of rhythm is about a cultural of option, variation, and space — both mental and physical.
- Stop meeting so damned poorly with so damned many for so damned long so damned much. There’s a whole (irritated) muse about this waiting to be written, but I’ll give you a couple of pointers to get you started.
A. Get serious about time. Start on time. All meetings are either 5 minutes, 25 minutes, or 55 minutes. Period. There are no longer meetings than that.
B. Work outside meetings to get attendees thinking about the issues, the problems, the solutions, the options. Meetings should almost never make decisions, but are best used as idea fountains.
C. Vary structure, leadership, style, and regularity. There is no one way, especially in meetings, and as soon as we make our meetings all look alike we kill much of their value.
- Build mental & physical support for Haykumeer protocol, voluntarism, pairing, and mobbing. "Hey, come here!". Small spaces, adequate for 2-4 are essential. Large monitors rigged for remoting and box-swapping.
- Focus on story-splitting, and consider taking a "pull & swarm" approach. Pull a story and get the entire team on it, as soloists, pairs, mobs, or all three. Aim to ship one story every day and a half. Every finished story is a "feels good" to everyone who worked on it.
- Show the working system every 2-3 days. (Don’t schedule it, use Haykumeer.) Showing gives us early, both wins and losses. The wins are "feel good"s, and the losses save time, allowing more wins. Insider tip: this is a great way to lend your product people rhythm.
- Adopt an aggressive fish-eye lens for working. You want maximum zoom for what’s just in front of you, with minimal detail & resolution squished out to the borders of your view.
Okay then. We’ve seen three levels to consider when we start thinking about rhythm, the org, the team, and the individual maker. In each, I’ve tossed out, not so much simple advice, as ideas I hope can trigger folks to come up with their own advice.
The keys are awareness, openness, variety, human judgment, and experimentation.
That’s not a coincidence, of course: those are always the keys. 🙂
I hope, after this huge baggy novel of a thread, you can at least see what it is I’m trying to point at with "Rhythm".
Getting good Rhythm, a well-tuned distribution of "feels good" over time, is incredibly difficult to achieve through formula. This is exactly because it reaches us at such a deep level. But reaching us so deeply is what makes it such an important topic.
It’s chilly here today, but I got a space heater and two warm dogs, and it’s a beautiful sunny day out.
I’m out soon for a Tiger Patrol with the troops, we are the thin furry line, and I hope you, too, have a bright shiny day with some trusted friends!
Listener Support and How to Be On the GeePaw Podcast
If you love the GeePaw Podcast, show your support with a monthly donation to help keep the content flowing. Support GeePaw Here.
You can also show your support by sending in voice messages to be included in the podcasts. These can be questions, comments, etc. Submit Voice Message Here.