The Power of Thinking About “The Thing After the Thing”

2 minute read | Suggest an edit | Issue? Question?

I’ve long been a fan of The Phoenix Project, and grateful for the ways its introduced so many to DevOps culture and practices. One of my favorite personal “ah-ha” moments came from part of its described Third Way of DevOps:

Improving daily work is more important than doing daily work.

It’s essentially the same principle as compound interest. Any improvement to our approach or process means all future work benefits from that improvement.

I believe in this principle deeply, but at times it’s been difficult to find language to really bring it home for others, and to describe how I myself put it to work in practice.

I recently found a phrase I’ve started using that seems to resonate, and accurately reflects a lot of the success I’ve been able to attain so far over my career. It comes down to this:

Always be thinking about “the thing after the thing”.

For every piece of work or process we touch, there is often a future state that benefits in a compounding way if we take the time, while doing that work, to imagine and improve that future state.

How Does This Show Up For Me?

Here are some examples:

The Thing What I do Because the thing after the thing is:
Planning a meeting Try to set an agenda/goals, be clear about who’s invited and why, and outline preparation Executing a successful meeting that doesn’t waste anyone’s time
Having a meeting Try to always take notes especially on next actions / decisions, to be sent out immediately Clarity and alignment on what needs to happen and how to communicate it
On-boarding to a new org/team Write down problems/questions/missed steps and create an on-boarding guide Helping the person after me, systematizing making things easier and setting expectations that others do that, too.
Coding Think about how to automate getting that code into an environment Deploying that as often as possible for success
Coding Think about logging & operational visibility Better observability when we inevitably need to troubleshoot something
Coding Writing automated tests Pinpointing future bugs or changing code rapidly with confidence to respond to future needs

It’s only recently that I realized how much I owe a lot of my success to this principle, articulated in this way. So I figured I’d write up a post to challenge you to “think about the thing after the thing”, for whatever your team or you are currently doing.

I’ll try to add some more examples here as they occur to me. And if you have favorite examples of your own, I’d love to hear about them in the comments!

Leave a comment