Mindset Over Madness
How to practice mindfulness in the software business
Developing software is complex. Where there is complexity, there exists chaos, complication and self-evidence. We quickly grasp onto the self-evident (aka the “obvious”) and our human minds ignore and/or bury the chaos and complicated. If you take a moment to stand still, you will quickly see. This is no different to the uncertainty associated with when a thunderstorm will occur, how severe it will be and at what location it will take place. Estimating the exact weather conditions is a challenge due to the ever-changing atmospheric conditions. However with the appropriate measurement tools and models the produced data can reduce our uncertainty. This is also the case with software development, although the “tools” are commonly referred to as methodologies, frameworks and processes . One might also argue that the existing methodologies, frameworks and processes are not robust enough but that’s a story for another time.
“When I’m consulting I’m focusing on having the right framework for that agility. If you understand how the framework works, the content that flows through it is irrelevant.” — Vered Netzer, Transformation Leader at ThoughtWorks
Software is hard. From my experience, software is hard because true innovation doesn’t come with a template, manual or tools that guarantee a particular output. True innovation means someone has not solved the problem in the same way you have and you’re taking a huge risk by making it happen. In other words, software is surrounded by uncertainty. Also the word “engineer” in software engineer, by definition, means a person who applies the principles of software engineering to the design, development, maintenance, testing, and evaluation of computer software. For this reason, it is easy to be distracted by focusing on implementing the framework correctly, rather than applying a framework that focuses on solving the problem, because the latter is more difficult.
In this article, I’d like to humbly share two of my own experiences to demonstrate how the madness and uncertainty within software development can be better managed with mindfulness and by leveraging methodologies without losing focus of the problem that is trying to be solved. As a forewarning, these learnings are neither a silver bullet nor a “one size fits all” solution but it helped both myself and the teams I’ve worked with to navigate the storm of uncertainty more effectively. I will leave it to you to explore and further formulate how this may or may not help you through the next stormy day.
Experience №1: The famous “I don’t know”
I often get the answer “I’m not sure” or “I don’t know” when asking an engineer or developer how long a certain task or piece of work would take to complete. However, unless this engineer or developer has never implemented something before, I find it hard to believe that they have no idea. After all, they do know something; they have experience developing something in the past. This brings me to a situation I still remember so boldly. I was working with my team on a client project to deliver an MVP of a new innovative software product. For context, I wore the hat of a product manager in the scenario below. It was late in the day and I recall getting off a call which resulted in a request to change some of the existing requirements, based on some new information that was learnt through user feedback. Once I had finished writing the requirements for the enhancement work, I spoke with one of my developers and the conversation went something like this:
Me (Product Manager): Explained the context and details of the enhancement then asked “How long do you think this piece of work will take?”
Developer: “I don’t know”
Me: “Why don’t you know? It’s important for me to get some idea, otherwise I will not know how to plan the distribution of work across the team amongst a few other things.”
Developer: “It’s too hard to estimate that. I’ve not done that before.”
Me: “I’m assuming you’ve done something of similar complexity so you do have some knowledge. Could this work take 2 weeks, a couple hours or something else?”
Developer: “Definitely not 2 weeks. Umm, I’d say about 2–3 days but that’s not a guarantee.”
Me: “Great, that’s helpful. I understand it’s not a guarantee, can you tell me some things that could go wrong or that you’re not sure about?”
Etc.
The conversation went on but I’ll stop here because what is important to notice from the above was that after an explanation about the developer’s existing experience and knowledge, in addition a prompting question, we arrived successfully at an estimate. The majority of methodologies and frameworks that have their own specific techniques around how to estimate but the commonality is the practice of estimating. In this experience, you may have observed that there was no mention of a specific technique. It was about the use of effective communication in order to arrive at some reasonable estimate by the developer and in turn also informing other decisions to be made.
Experience №2: Getting comfortable with failure
Note that getting comfortable with failure is not to be confused with failing blindly.
There are two common symptoms associated with not being comfortable with failure. We either constantly strive for perfection and can never be ok with good enough or phase or we crumble and our world has ended when we fail because we just can’t it. In the world of software development, there is nothing but constant failure and to survive with the slightest chance at being successful. You may be familiar with the Agile “fail fast, fail often” or “fail fast, learn faster”. According to Thomas Watson, IBM’s founder,
“The way to succeed is to double your failure rate.”
But the topic of failure is a controversial one because some organisations do not tolerate it. But that’s no surprise. Failure has a lot to do with mindset (eg. how we deal with it and what to do when it happens) and the context which the failure occurred. I recently had a conversation with Dino Talic, Head of Product at Open Agent, about product development and his role. What was most interesting to me was how he described his role and challenge. He said,
“My role is to help my team get comfortable with uncertainty.”
For some context, we were discussing the challenges of developing software products and the naturally opposing forces between the uncertainty of software development and the certainty that people expect by nature. As part of this conversation, we came to agreement on a few points:
- Focusing getting the framework/methodology/process right instead of focusing on solving the problem demonstrated discomfort with uncertainty, and therefore failure.
- Getting comfortable with failure needs to be continuously demonstrated by the leaders of a business
- Encouraging a “failure-friendly” (eg. a willingness to be wrong) culture is necessary to grow but its equally important to recognise that not all failure is equal and comes with consequences. There must be learnings gained, shared and acted upon from one’s failures.
There are also those who believe that failing fast and often is foolish. Last week, Forbes shared that
“ ‘Fail fast, fail often,’ is not only being used incorrectly as a cousin to “Lean” and “Agile,” it is creating a culture of people aiming for the short-term,... Instead of calmly and intelligently iterating, employees race to complete something (failing) while racing to the next objective as quickly as possible. (failing, but quicker.)”
I can see where they’re coming from, however, I think the misunderstanding stems from the human expectation that we can just take a concept, apply it and then it magically solves the problem. This couldn’t be further from the truth. This is where one’s mindset (eg. critical thinking) plays an important role. A particular mindset will either make or break an individual, especially in difficult situations. For example, “employees race to complete something” and “racing to the next objective as quickly as possible” is simply being irresponsible. Developing successful software is just about making it to the finish line; it’s about getting to the finish line with the delivery of some value and benefit that your consumer is willing to pay for. That is the responsibility of those who develop software. Ultimately, it is not about agreeing with the waves of trends rolling by. Instead, it is about aligning yourself with the reality that failure exists and just sometimes cannot be avoided because there’s always something we don’t know enough about. Therefore, a mindset where one accepts the existence of failure exists and finding ways to learn from that failure is the best way to get comfortable with it.
Methodology Does Not Void Responsibility
When it comes to building successful software products, juggling problem solving and tricks our mind plays on us is a challenge. But we need to recognise that as professionals developing software, we have a two main responsibilities when it comes to software. One of those responsibilities includes applying the most appropriate techniques, methodologies, etc. to solve the problem. The other is to not be ignorant about the fact that our job is to actually solve one or more problems.
Methodologies, frameworks and processes are not a silver bullet. With an ignorant mindset, one might get the impression that they are making progress just by using a certain methodology, framework or process but the reality is that it will not magically solve our problems. Too much focus on getting the process right also detracts from the energy of solving the actual problem. It is the responsibility of those building to software products to solve the problem because the unspoken truth about software is that it’s problem solving. That’s what true innovation is about — discovering an opportunity that comes with both intrinsic and extrinsic rewards. Methodologies, frameworks and processes also do not exist to void our responsibility to deliver software that solves problems and ultimately delivering a benefit to the consumer. They simply provide guidance and structure in the chaotic world of software.
Here are a few principles that worked for me and, perhaps, you may find useful:
- Brainpower over methodology, framework and process
- Embrace failure by learning then trying again
- Get results with effective communication
- Act bravely, not ignorantly
- Use your mind as a tool, not a limitation
Remember there is no manual or template for true innovation and problem solving. Software engineers apply principles of software engineering in order to design, build and maintain software products. It’s a science and art.
Learned something? Hold that 👏 to say “thanks!” and help others find this article.
Do you want more? Follow me or read more here.
This story is published in The Startup, Medium’s largest entrepreneurship publication followed by + 370,771 people.
Subscribe to receive our top stories here.
