The Complicated Relationship Between Doing and Thinking
A consultant colleague provided me some feedback on a post and some relevant examples from their work with clients. It got me thinking about the dichotomy between doing and thinking. Let's examine.
I wrote this post a while back but must have gotten distracted and forgotten to post it. I’ve made some light edits today, so it's more finished and ready to publish. Thanks to my colleague Davin for the comments that led to this post and some feedback that helped improve it. I'm sorry it took so long to post it, Davin! 😅
This post is particularly relevant to readers who have had positive experiences being more outcome-oriented and wish to share these ideas with others. It’s not easy! I share some common pitfalls and ways to approach helping others to experience the benefits. It is longer than most email readers can handle, so I suggest clicking through and reading on the site.
Why Don’t More People Use Outcome-oriented Thinking More Often?
I recently received lovely feedback from my colleague, Davin Ryan, on an older post. It was a post about the role cognitive biases play in skewing us towards reactive, short-term choices and how, because the cause is bias, we can be unaware of the effect this is having on our ongoing decision-making, trapping us into ‘busyness’ and producing inferior results. The post provides some insight into why I think we can fall into repeating patterns of work that lead to poor results.
Davin shared with me the following:
I love the first part of this as my current client struggles with the same problem. They think it is better to be busy and decide on the outcome later than to decide on the outcome first and figure out how they are going to measure it. I constantly hear the phrase 'doing something is better than more investigation or understanding right?'
One project failed because of this very reason
They built something for the dev teams that no one wants to use
It was nice to hear this feedback because of its positivity and because Davin’s experiences represented more evidence of the patterns I have observed working with clients and firsthand during my many years leading technology teams. It also describes much of my behaviour and traps I am still prone to fall into today if not careful.
I constantly hear the phrase 'doing something is better than more investigation or understanding right?'
In response to Davin’s feedback, I shared that ‘Being busy and deciding the outcomes later’ sounded like the cowboy painting targets around their bullet holes. Wherever we end up, we can build a narrative around that being what we intended.
My hypothesis, which is the theme of this publication, is that, overall, the way work is approached skews too far towards activities, and introducing more outcome-oriented approaches to work would benefit everyone.
Davin’s approach with his clients supports this perspective; here are some practical approaches he’s taken when such situations present themselves:
I mentioned to my client that was struggling 'what doesn't get measured, doesn't get done' I helped them use a combination of Flow metrics and customer feedback to show them how to stay on track and course correct along the way
With another client I re-introduced the concept of customer feedback and how to do it efficiently so they didn't have to rely on their own assumptions and guesses about what success/good looks like
What you can see from Davin’s approach is that he is not telling them to ‘be outcome-oriented.’ He is identifying problems they are facing and finding ways to overcome those that help them address their more significant issues.
How Did Davin’s Example Play Out, And How Did He Help His Client?
Davin found that some hard truths were difficult for the client to confront because they were wrapped in the perception of blame, consequences, and job stability for the people involved. The lack of engagement in a broader context, that is, the outcome being sought and the heavy bias to action made the waste associated with this difficult for them to see:
What they did do astonished me. They created busy workshops of more than 30+ people for many hours, where they ignored deep diving into the problem (as that was too sensitive to dive into) and came up with ideas (because ideas are fun and the easy part) which were 'essentially guesses around the problem that no one wanted to face' but then came the reality that they could not execute on any of it (they pretended to and made loose non-committal promises).
Getting people together to work on the problem seems sensible, so why did this fail? According to Davin:
The barriers were just a few: they were not organised in such a way that anyone could 'own' the improvements'; no one had the skills, experience or curiosity to execute. Nothing out of the workshop was ever acted upon.
After realising what had happened, with some understanding and empathy (as they were dealing with some PTSD) we tried to help those impacted teams understand the situation. We guided them on a path to collecting real metrics and measuring their pipelines so they could without a doubt figure out what the real problems were.
As a result, Davin reports that they:
managed to reduce deployments frequencies from 6 months to just a few days. Amongst the solutions were proper ownership and focusing on outcomes and user feedback, Metrics were ultimately the easy path because no one could argue with them and they didn't directly blame anyone so people often didn't lose face which was the 'root cause of why they were in this situation in the first place' - its seldom ever the tech that is the problem...
Davin makes a great point that framing in terms of outcomes and measurement can also help shift the focus from judging people to focusing on the problem. This, in turn, can help people feel safe and be able to operate for the benefit of the organisation rather than out of fear and their own preservation.
The Contradiction of Actions in Learning
Taking action is essential to learning. Being outcome-oriented is not an alternative to taking action; it's a frame that can help us decide what actions to take.
As outcome-oriented thinkers, we need to concede that, in some respects, Davin’s client's statement can sometimes be correct—sometimes, simply taking action can help you learn. Taking action without pausing to consider the outcome may help you get where you need to go. We also saw as Davin delved into the details of this particular case, we found the situation was more intractable and being action-oriented was contributing to more wasted effort, so equally, there are times when the approach must change.
Our bias toward action is also influenced by our cognitive biases, so it's essential not to be judgmental as someone trying to help. We can all find ourselves in a situation where our cognitive biases lead us to think similarly to Davin’s client, and sometimes, that thinking would be suitable for the situation. The real challenge for all of us is knowing when to take which approach.
Blind action can help us learn things that can help us. Trying something and failing or succeeding gives us feedback. We often implicitly know what we are trying to achieve, and our actions are often highly relevant whether we think consciously about the outcome or not.
Now, I don’t advise making a habit of working this way, but I won’t tell people doing this is always harmful or that they must be outcome-oriented. These are both too binary and can become an obstacle for people considering practising outcome-oriented approaches. What you are telling them is often contrary to their lived experiences. They have done things without the burden of making the outcome explicit and had success.
For someone to value this approach to thinking, you need to share how it benefits them. What the value of exerting this effort might be, and what risks it may mitigate? What we are trying to mitigate is the compounding effects of only using an action-oriented approach to working, as I explain in this post:
Let’s explore in more detail the ways that can become barriers to doing something that sounds so sensible: to think about what we are trying to achieve before we try to achieve it.
What Are the Pitfalls When Switching to Outcome-oriented Thinking?
When someone’s frame for decision-making has been primarily activity-oriented, this tendency can lead to missteps when switching to outcome-oriented. This can manifest in a few ways, which I will expand upon for paid subscribers:
What Are the Pitfalls When Switching to Outcome-oriented Thinking?
Outcome-orientation as Bureaucratic Process Step
Outcome-oriented Thinking As The Only Way
Outcome-oriented Thinking As Unnecessary Hurdle
Fear of Outcome-oriented Thinking Leading to Analysis Paralysis
How Outcome-oriented Thinking Helps Us Make Better Decisions
The Role We Play In Helping Others Improve Decision-making
If you’d like to increase the impact of your software teams, you'd be lucky to work with Davin Ryan. Connect with Davin on LinkedIn.
If you like this post let me know by hitting the ❤️ button and let others benefit by sharing it:
Have you tried to help others think in terms of outcomes, but they have yet to see the value? What did you try, and how did they respond? What, if anything, helped them reach a breakthrough? Let us know in the comments.
Let’s explore the details for each of these pitfalls so we can avoid them when coaching others on moving to a more outcome-oriented approach to work:
Keep reading with a 7-day free trial
Subscribe to Great CTOs Focus on Outcomes to keep reading this post and get 7 days of free access to the full post archives.