TBM 297: Staying In Touch

Hopefully, I'm back on the road to health and fitness, but I have let things slip since my son was born.

In the before-times, I was obsessed with cycling. I had a GPS, heart rate monitor, power meter, and scale. I kept a digital training log with various metrics and used a specialized analytics tool to cut the data. I also kept a detailed training journal with qualitative observations (e.g., "woke up with a bit of calf tenderness" or "feeling positive about the season so far"). Once in a while, along with racing and training, I would do benchmark "tests"—all-out efforts at certain durations.

I was "in tune" with my body (at least as it related to cycling). This helped me avoid sickness, prevent overtraining, and plan when I wanted to be riding well for certain races. And yes, I was really into it.

After my son was born, things changed. It was hard to gauge or understand how quickly things were deteriorating. The decline was slow at first, but it started to accelerate. My weight didn't increase for a while, and when it did, it did so very slowly. I didn't run into health issues immediately—those things didn't crop up for a couple of years (and when they did, they were often confounding and hard to track down, especially with COVID-19 in the mix). Most importantly, I had lost any intuition for the scale and magnitude of where I was. I had lost touch.

It is going to be a long road back.

I have been fascinated recently by how teams (and organizations) fall into downward spirals. Sports and fitness analogies mostly fall apart because we are talking about groups of humans and complex sociotechnical systems—not a single organism. All that said, I do think there are some similarities worth exploring.

Here's an interesting practice from a recent conversation with an engineering leader.

About eight years ago—before this person's time—the product development organization established a set of "reference feature types." The categories range from minor front-end tweaks with no underlying data model or logic changes to incredibly involved migrations and refactoring efforts. I forgot the number of types, but it was less than ten and more than three. For eight years, they have been keeping track of lead times for work falling into the different categories (along with short, often colorful and humorous journal entries). It is not an onerous or stressful process—and no one gets fired if something takes a long time. The data doesn't need to be perfect to do its job.

"We had some reference points to understand what was changing and a starting point to explore plausible reasons for the shift and do something about it."

Why do they do this? It is a catalyst for making sense of shifts over time. When things that used to feel easier got harder, they had something to point to. They realized it is easy for people to forget what happened last month, let alone last year. New people join. Long-time team members leave. People change teams, and teams morph. Narratives form around why things are harder (or easier) and why things are the way they are without a way to rewind and understand how people perceived things in the past. People change, too! In six years, someone can completely change how they view software development.

This reminded me of the value of combining many years of cycling data with qualitative journaling. Yes, I had changed, and yes, the data was contextual to the season. But it made it much easier to diagnose and address new challenges.

I recently asked a team whether they ever reviewed their retrospective notes. What were you talking about a year ago? I asked them to write down a guess before they searched for the notes in Confluence.

The banter:

What were we working on last year?

Was [Person] here yet?

Was that before or after the reorg?

Was that before or after we started the refactoring effort?

Suffice it to say the guesses were off. The team was genuinely surprised by the notes. "This is like a time capsule," mentioned a team lead. Another team member noted that the team was particularly concerned, at the time, about the depth of customer research they were doing. "I'm not sure we ever resolved that," she reflected. "If anything, we stopped talking about that, even though it was very concerning. Why? Did we decide it isn't a problem, or did we just get tired of talking about it?"

It turns out that humans aren't very good at remembering things, and we ARE good at forgetting things that cause dissonance.

We stumbled on an activity they did as part of that past retro—brainstorming all the team's steps to achieve a challenging goal. Looking back, the team was struck by 1) how they typically have to jump through more hoops now and think less of it and 2) that they even did the activity.

It reminds me of this diagram I made exploring why organizations "forget."

I'll end with a question.

Imagine it is a year from now, and you are trying to understand how your team (and your team's context) has evolved. What are some basic things you can make a point of keeping track of that might help? It doesn't need to be quantitative. How can you help not forget?

Perhaps you can try a retro activity to deeply document what it took to make something happen?

Another twist: send your team a "time capsule" that captures your current perspective. Before you know it, it will be a year from now and you’ll probably learn a lot.