One of my favourite ideas is "goals are like pulling strings". Basically, when we say we want to do something like being able to deploy our software multiple times a day, it's best to see that not as something worth doing in of itself, but as a proxy for all of the practices we need to make that sustainable. In our multiple deploys per day example, that might include:
- Comprehensive testing so we're sure the change we're deploying has a low chance of failure
- Monitoring and error logging so that we know if a deployment is causing issues (either direct errors or performance regressions)
- An automated deployment and user-simple deployment process, because it's unrealistic to spend multiple hours a day deploying software
Looking at lofty goals through this lens can help us make sense of the initial discomfort we might feel. If we understand that the reason we feel uncomfortable is because there are things missing, it becomes as easy as identifying what's missing before moving on. Even if we don't ever end up hitting our goal, we're most likely still in a better place because of all the incremental steps we've taken along the way.
For extra fun, consider building a capability map in the form of a string-pully-diagram:
You'll find that when you do this, it becomes easier to map dependencies and unearth why we're feeling uncomfortable, as opposed to just feeling it. Thus in a similar way to trees and abstractions, the best time to start doing this is 10 years ago, the second best time is now.