Every once in a while, I watch or hear something that registers itself very deeply in my mind, and which changes the way I look at myself, my goals, or my work.
One item that has a strong impact on my thinking today comes from business consulting guru Eben Pagan. Some years ago, he gave a short talk where he discussed “inevitability thinking.” I found the recording here. I will paraphrase what I think are the key points, from my own perspective as an engineer.
What Is Inevitability Thinking?
Inevitability thinking introduces a subtle but very powerful shift in the way we frame the goals that we set.
Framing goals? Wait. We’ve all set goals in our career and in our lives. They might be financial goals, career goals, fitness goals, or relationship goals. Anyone who has spent much time in the corporate world has probably heard of the SMART criteria, which are used to create more sensible and reasonable goals.
However, when we set a goal, we usually focus directly on the goal itself, and how great it will be to attain that goal. As a result, we seem to gloss over a tangible plan of action in reaching the goal. This makes it all too easy to set goals that, despite our best efforts, remain detached from the intensity of our best efforts. As a consequence, it becomes easy to set too many goals, or to shy away from direct and aggressive pursuit of them. I’ve done it this way, and the results were, of course, very disappointing.
Inevitability thinking flips this problem around. The idea is that you identify a goal, and then ask yourself a key question:
“How can I make this goal inevitable?“
In other words, how can you guarantee that you achieve the goal?
It seems like a very subtle shift, but it is a very powerful one. I think it is powerful because it immediately brings focus to the steps that are necessary to achieve the goal, rather than the goal itself. It is as though this simple change of perspective makes the mind accept that the goal is realizable, and the mind moves beyond that, into an implementation plan.
Goals and Career
As a practical career example, imagine that I am a junior software engineer who wants to become a senior software engineer. How would I do it?
If I focus on the goal in the abstract, I might concentrate on spending more time at work. Maybe I would exert myself on writing more unit tests to make my current software project more reliable. Perhaps I will study a new technology in order to stay up-to-date. I might flounder around, because I am focused mostly on the end point itself. However, I have not accepted the goal as reality for myself, nor have I implemented a thorough plan leading up to the outcome.
Now, if I approach it from the perspective that I must make the goal inevitable, the focus shifts into an exercise in all-out planning towards the goal. An inevitable plan might look like this:
- Set aside a few hours a week to study the skills and behaviors of software engineers. Write notes about what I observe, and make a list of the behaviors that I should be modeling.
- Tweak my professional network so that I am shadowing senior or higher level engineers.
- I start to dress the way a senior engineer dresses at the company. Yes, this means I might have to figure out a mature means of expressing myself without using piercings, jean shorts, or indie band t-shirts.
- If senior engineers host presentations at my company, I will start to work on my presentation skills.
- If senior engineers have certain distinct technical skills, I will take some outside training, or work on side projects that support me in getting those skills.
- If senior engineers are particularly adept at personal or organizational skills, I will start to study and improve myself in those skills.
- I will seek out one of the senior engineers for possible mentoring relationships.
- I might seek out mentoring from experienced people in other groups at my company, so that I can develop a network across organizational bounds.
- Make all the above points into a personal checklist and ensure that I am reminded of this at least once per week.
- Regroup once every month to make sure I am accomplishing the items on the list.
- Get a friend to review these goals with me, who will take me to task if I go astray.
That seems like a challenging list! However, I would imagine that it would also produce tremendous results.
Goals and Projects
If you are reading this, then you have probably already applied this way of thinking in your professional life, perhaps without labeling it as such.
For example, as a software architect, I frequently help my project and program management teams backpedal from a projected deadline into a set of reasonable objectives for implementation teams. This is implicitly using the inevitability thought process. However, since these are corporate goals (and are presumably not optional) it is an expected part of the job. One must produce plans that support goals.
However, there are other interesting ways to apply this thinking, which are sometimes outside the normal scope of project planning.
In the face of production-time bugs, inevitability thinking has shifted my thought process away from simply “fix the bugs,” towards “fix the bugs, and guarantee that they will never occur again.” This seemingly-slight change encourages a more holistic look at the system level landscape, and it seems to drive a deeper and more proactive root-cause analysis.
Although TDD gets much press these days, there are still many organizations that do not employ true TDD. Even in these organizations, when I encounter areas of software with high complexity or a high risk probability, I try to employ inevitability thinking to explore ways in which to guarantee functional integrity of the area of risk. Normally this takes the form of some level of TDD or an automated system-level smoke test.
When a project has obstacles regarding lack of knowledge in certain niche areas, it is often a good idea to bring in outside expertise to help. Inevitability thinking helps to frame this approach as a valid alternative to what might otherwise be thought of as an obstacle or a learning curve.
On a project level, I often employ this same thinking to the broader scope of the project. You can bet that I am not only spending time planning for downstream technical risk, but I am also spending a lot of energy considering the political landscape, the alignment of the project to business goals, compliance issues, go-live plans, and a host of other topics that most other project participants aren’t considering until later stages. This equips me to help direct the implementation efforts, or simply to have a plan ready at the time when it is needed.
Summary
Inevitability thinking has encouraged me to think of goals from the perspective of the steps necessary to accomplish the goals, rather than allowing them to sit in abstract form. However, I have found that this approach does not come for free! Pursuing goals with such a degree of intensity requires more effort than idly pondering them. As a side effect, I tend to set fewer goals, and I have become more selective in choosing goals to pursue. This change in perspective has made a positive impact on my professional and personal goals. I’m curious to learn if others experience similar results.