I don't know, now what?
I don't know, now what?
It’s one thing to have openness, but it’s another to be productive while doing so.
The problems that you encounter in software are as innumerable and random as the placement of the stars in the sky. Many folks will over-emphasize the science of software and become rigid with numbers, proof, and evidence in order to work through the problems. Meanwhile some people resort to the art of software and find themselves using instincts for how they solve problems.
Neither of those is inherently wrong. But they also are not always correct. And it’s this dichotomy that presents itself in software and very few other crafts, that makes it uniquely fitting for the mindset of “I don’t know, let’s find out together”. Some may consider this a recasting of the beginner’s mindset. Others may identify this as scientific method, and that is why it is such a perfect tool for us to improve our daily experiences building software.
A beginner’s mindset
The practice of beginner’s mind is based on having openness too information. In software development there is no shortage of information and it’s important to make use of all that context when solving problems. And if we step closer to how we practice a beginner’s mind, we should pay attention to the idea that there are a few ways we can be oriented while achieving our goals.
Regulatory focus theory introduces the idea that there are effectively two ways we usually orient ourselves during problem-solving situations: promotion-focus and prevention-focus. The theory describes these two as very certainly different, and that either of them is used based on the feedback we receive.
In many situations the problems we encounter in software fall into two categories as well: advancement and protection. Advancement is any situation in which the software product innovates or iterates towards successful outcomes for the system and/or the users. The protection category is all of the situations that typically fall under non-functional requirements of software such as data integrity, resiliency, and high-availability.
If we were to take these ideas just on face value, we might mistakenly think they are either/or situations, but this study at Columbia University shows that might not always be accurate.
Both forms of regulatory orientation can work to fulfill goals, but the choice of orientation is based on individual preferences and style.
So if we’re left with preference and style it’s fair to ask “what is my preference?” And this is where motivation comes in to help us choose the style we want to apply to our problems. Based on the two categories of problems we face with software, you would find it interesting to know that there are effectively two motivations within the regulatory focus theory: approach and avoidance. If you consider the ways we receive feedback about our software’s behavior, it’s generally found that success feedback will induce the approach motivation and failure feedback will support the avoidance motivation. Each of us is not locked into one or the other, and based on regulatory fit, we can find ourselves flipping motivations during decision making processes
With a beginner’s mindset, we could now re-frame this question of motivational preference and simply understand that it could be either, at any time. We no longer have to receive failure as a negative feedback, but instead use it as avoidance motivation. Both success and failure feedback can be used in order to improve our decision making process.
Scientific method
Given the descriptions of motivations as approach or avoidance in our decision making process, now we can rely on scientific method to help us understand how to make decisions. The Socratic seminar is one way in which many software development practices achieve scientific method, while maintaining a beginner’s mindset (pair and mob programming). A comforting aspect of the Socratic seminar is what is considered to be the pertinent elements of an effective topic for the seminar. They happen to fit with software development in amazing fashion.
Ideas and values: This element very specifically speaks to the outcome for our software, and the exploration of ideas that result in the best values for the system or users.
Complexity and challenge: All software has complexity and these are open to interpretation. Many times we want to remove complexity, but in some cases it should be accepted. Finding shared understanding of the complexity is the intention of the seminar.
Relevance to participants’ curriculum: Software developers very often have experience of skill that is relatable to the problem, and we seek out the best ways to apply those.
Ambiguity: Forcing the shared understanding to avoid right or wrong answers, creates a better opportunity to explore the problem in order to arrive at the best solution. Allowing ambiguity also de-pressurizes the process, giving members the chance to acknowledge what they don’t know, in a way that is not isolating.
What can we do?
At the core of the idea, we are saying that in order to achieve the best decision for our software, we should use a beginner’s mindset, and understand that there are multiple motivations that can be applied at varying times, and that the scientific method is the best framework for asserting the correctness of our decisions.
And all of this can start when we say: “I don’t know, let’s find out together”. If you are interested in learning how to apply this for yourself schedule some time for coaching with Attainable.