Happy Friday!

I sat down at my computer this morning wondering what I'd write about today and a conversation I had with a senior leader came into my head that I'm going to share a bit about.

We were talking about ideas and issues and one of the people with us had recently joined the leadership ranks and to everything we said, they'd point out all of the problems in the way.

Eventually, that senior leader stopped and said, "Look, you gotta learn to pick your battles."

They're absolutely right, and it is a somewhat odd thing to learn. Yet, in an odd way, if we don't learn to pick which issues to tackle we get spread too thin and run out of energy before making progress.

With that, let me share with you how I pick my battles.

I pick battles based on answers to two questions:

• Can I live with the consequences of doing nothing?
• What potential is unlocked if this issue is addressed?

These questions don't cover the more expeditious path of making changes in areas that don't require consensus, loss, or complex coordination. Those are more or less free to tinker with, and generally speaking, the areas you want to work in first.

So let me explain a bit more about living with consequences. From previous emails, you'd be right to assume I love the unlovable aspects of software. Testing is one of those areas. Most of my clients know they have major quality issues that testing can address, but they don't want to make changes. So when I'm asked to help with some software project or product I have to look ahead to the quality problems and ask, "Can I live with those consequences?" Most of the time the answer is that I can, and I prepare for outages, support, and a longer release cycle.

That first question, lets me live with a ton of imperfections around me because I can simply prepare for the consequences and move on. Oddly enough, most people have lived through those consequences regularly, so they're more normal than people care to admit.

The second question, this one takes a bit of thought. Thinking through issues and how they interconnect to things two or three degrees away from their immediate blast radius is really important. I then pick from the issues that act as significant factors to many of those 2nd or third-degree things and tie up significant stress, resources, and variability. Those are the ones I might choose to go to battle on.

It can be tricky here to give a good example since the impacts spread so far, but some areas I tend to hone in on that might be interesting to sort of back into this are testing, sprint reviews, and release automation. If you think about those topics and what impact they have, a few steps away, you might find that there is a ton of secondary benefit to addressing these areas. That's what I map out.

Anyway, I haven't really heard many people talk about how they decide what to make their problem and not over the years, so I'd love to hear how you do it.

Sincerely,

Ryan