coaching

Day 2: another day, another blog post. I might have mentioned before that this whole blog-post-a-day thing was inspired by National Novel Writing Month, but I didn't mention the other piece: I did NaNoWriMo wayyyy back in 2009, writing a vaguely cyberpunk-tinged exploration of persistent augmented reality gameplay called In Silico.

From that, I learned to turn off my inner editor, and to get into a rhythm. You just have to put in the work. There's no shortcut, though it helps to write what you know (or are interested in). But you're not alone: NaNoWriMo connects you with a network of your fellow high-velocity writers through meetups, readings, online forums, and so on. Many people in that network are professional writers, or aspiring professional writers, and have a lot of good advice: how to get started, how to plan out story arcs, how to write compelling dialogue or action scenes or whatever.

So: coaching. I coach people in two places: as a lead engineer at LEGO, and as a trainer for local sports club Jugger Copenhagen.

These are completely different environments, but it turns out that the basic techniques of coaching translate pretty well between them. That's great for me, as it means I can learn how to be a better lead engineer by being a better sports trainer, and vice versa.

What sorts of techniques? OK, some concrete examples are in order.

What we're about to do, what we're doing, what we did. This is super-useful when introducing a new skill. You show your mentee what they're about to do, ideally with examples in context. Then you point out the important aspects of said thing as the mentee goes through them. Then you help them understand what they just learned. Fantastic. It's spaced repetition meets experiential learning, which means it has pretty broad application.

Retros. To coach better, you need feedback. To learn better, you need feedback. In agile development, retros give a regular, structured space for feedback. That's it. Anyone who tells you "retros must follow framework X" or "retros must happen every Y weeks" is wrong: the framework and cadence aren't the point. Building a culture of feedback is the point. So on the field, I also make space for feedback. How did this practice go? What should we, as a team, do more of? Less of? What would you like to learn?

Periodisation. In sports training, you don't want people to train at full intensity, all the time. That's a recipe for burnout and injury. In the same way, you don't want a product team running at full intensity, all the time. That's a recipe for burnout and poorly-managed technical debt. You make sure high-intensity "sprint" periods are balanced with lower-intensity "active rest" periods: to clean up and refactor, to deepen skills, to reflect. Some frameworks like Shape Up deliberately build active rest into your workflow, so that you plan for it and don't forget.

Community of practice. You should never coach alone. You need other coaches around to bounce ideas off, and to help you grow your own skills. You need to grow people around you, so that they can help fill in when you're sick or on vacation, and also so that they feel like they have a path to grow. This is valid everywhere. Never coach alone. If you're coaching alone, find a way to build that community of practice.

...which brings me to say: if you enjoy something and want to get better at it, practice it in different environments! Different environments lead to different sources of inspiration, which leads to a fuller understanding of the skill. And if you haven't been feeling the enjoyment of learning, applying it outside the daily work grind can give a much-needed boost of energy. Especially if foam swords are involved.