TBM 294: Close the Loop. Stop the Drift

Great/healthy teams:

• Don't let problems fester.

• Close the loop on open questions.

• Integrate perspectives, code, insights, beliefs, etc., often.

• Put in the time to foster shared understanding.

• Address dissonance head-on.

• Limit the number of "open threads."

• Use forcing functions and enabling constraints.

• "Pull the Andon cord" earlier rather than later.

• Break big things up into smaller, meaningful steps. Work small (but think big).

• They are biased toward constantly asking if they are doing the highest-leverage work possible and course-correcting quickly if not.

When you look back on the last week or two, you almost always have evidence of meaningful steps; if you don't, you do something about it. This is why you can "just tell" things are healthy and flowing when you're on a team like this. You don't need fancy metrics—stuff that matters happens. And there's minimal dirty laundry and accumulating baggage. When something breaks, it is obvious because most things are working vs. shrouded in all the other broken things.

In last week's post, I covered the concept of migration (in the context of bullet journaling). The basic idea is that you force yourself to revisit your open threads instead of letting things slip. The creator of bullet journaling, Ryder Carroll, writes:

The purpose of Migration is to surface what's worth the effort, become aware of our actions, and to separate the signal from the noise.

I couldn't think of a better way to describe the habits of healthy, effective teams. Closing the loop helps you do important work, become more self-aware, and figure out what to pay attention to.

But what happens when things slip?

The team slowly loses its edge.

Instead of dealing with loose ends in the moment, the team adds tasks to to-do lists. Sometimes, those to-dos happen, and sometimes, they don't. Instead of dealing with decreasing confidence, new concerns, or new blockers in the moment, the team makes vague commitments to "take that offline."

Goal specificity drops. Instead of crisp goals that are a bit spiky and opinionated, the team falls back on vague and open-ended goals. Updates become a bit more optics-oriented and skirt around where the cracks are forming. That critical metric the team has been waiting for—eh, maybe we can do without it.

In the past, the team would cut scope if it had trouble integrating its work end-to-end and getting something into production. "Let's stick to that forcing function!" But recently, they've gotten into the habit of just punting things. "We'll sort it out next sprint!" In the past, if there had been a dependency on another team, a manager might have organized a joint sync or maybe even a collaborative problem-solving session. Now, to keep people busy, managers try to proxy the team and deal with that kind of stuff one-on-one. The number of "just because that's how things work around here" and "it is not worth bringing up again" increases.

It is easy to see this as a dereliction of the team, a loss of sense of urgency, or a stop in caring as much as they used to. But in most cases, based on what I've seen, it is more like doing the right thing—the intuitive thing—is progressively getting harder.

When the company was smaller, bringing up disconfirming information or throwing plans into doubt might have been rewarded and appreciated. "I'm not so sure about this anymore" was the right thing to say/do and was incentivized.

When it was easier to get answers to pressing questions, people were more likely to ask those questions.

When involving an architect was an informal ask (instead of a big performance), teams were more likely to pivot based on new information. You can expect people to push back and make a stink for a bit, but if those things continue to be difficult or even get harder, people will pragmatically adapt.

When the optics of a process become more important for a company than the outcomes, conversations, and decisions triggered by a process, you're in for a rough time.

I'll always remember chatting with an engineering director obsessed with publishing burndown charts. I asked what decisions had been made based on those burndown charts. What happens if things slip? What happens if the team needs help? What happens if the scope has increased?

The response was not encouraging. In her mind, her job was publishing the burndown chart. I asked if leadership confidence was high in her team, and unsurprisingly, the answer was "not very high at the moment." But in her defense, every time the team had raised issues and asked for more support, they had been rejected and denied that help. So, in her mind, publishing the burndown chart showed leaders the results of their actions. You can probably sense the wicked loop that was in play here.

You end up with the burndown chart to hell…

It's not just the accumulation of baggage. Sometimes, it is the frequency of change ("new baggage" and "taking the trash out").

Being agile is great, but no team can withstand constant strategy shifts, constant reshuffling, constant efforts to micromanage work, etc. Say a team has to deal with the elephant in the room every once in a while. It takes effort. It's challenging. But they get it done. If you have the elephant in the room to deal with daily, no team can roll with all those changes. Imagine waking up every morning and having to reshuffle your schedule completely. At a certain point, your will is going to flag. This is a big reason why some teams that were formerly great at frequent integration and course correction eventually get burned out.

So with that, some questions:

• If you feel you have a handle on things at the moment as a team, what should you be stubborn about to ensure you don't let things slip?

• Is there an opportunity to build some shared understanding with your team around signals that things might be slipping?

• Most people can relate to the idea that things slip, so there's a chance they might engage with the idea of making sure they don't slip. Who is up for helping?

• Where are you letting your team processes run you instead of your processes working for you?

• Where is the greatest area of dissonance on your team at the moment? How might you invest some time to reduce that dissonance?

• What loops are sitting in your head, taking up space, that are difficult to close?

• What forces make it less worth it for you to do the "right" thing? What is the "just because"? Forcing functions are always a little uncomfortable. How do you create more bandwidth to deal with that slight discomfort and turn it into a positive? Are you experiencing too much change—either magnitude or frequency—to get settled?

Have a good week!