The Power of Thinking About “The Thing After the Thing”
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