Our work drives complexity. Complexity drives stress and anxiety. How can we prevent this cycle from occurring at the root cause?
In 2015, after years of constant back pain, my wife convinced me to visit a doctor. I was 27 years old and considered myself to be a healthy person, so I had been ignoring the pain. On that doctor visit, I was diagnosed with an autoimmune disease: Ankylosing Spondylitis.
The shock of the diagnosis meant that I didn’t ask my doctor any of the million questions that were swimming around my head, but as a software engineer, I was used to looking for answers online – so, I turned to the internet. I do not recommend doing this, but for me, it was the beginning of a journey of discovery.
I followed a kind of scientific method, running small experiments to find what could help me to control the pain. I changed my diet, the way I exercised, and even the type of shoes that I wore. After all those changes, I was having fewer episodes of pain, but they occasionally came back even stronger. So, I went to find the root cause.
I found stress and anxiety. I realized that when I felt stressed or anxious, my body started to feel tense, and I would spend the day after lying down in bed. So, what was the cause of those feelings? Most of the time, they were work-related. The technology (consumed and created) was a driving factor of complexity in my life, and if it’s been affecting me, it’s probably affecting you too. The only difference between us is that I had the warning sign of back pain. You could be ignoring these feelings until the moment you burn out.
The impact of complexity
When I faced a complex task, my stress levels went crazy. But why does complexity play such a significant role in stress and anxiety? Complexity is hard to change, requires too much effort, and is a waste of time, motivation, and money. It can also often be uncontrolled, which tends to lead to low-quality software. All of this leads to stress. Complexity demands a high cognitive load, so the effort to take any small decision or action is massive. This can drain the pleasure of everything and cause procrastination.
Finding the cause
If complexity is such a troublemaker, what can be done to prevent it? Firstly, you need to know what is causing it.
I noticed the following three causes in the software development world:
- Inherent complexity;
- Project-lifecycle-induced complexity;
- Self-inflicted complexity.
This is the best kind of complexity. It is related to the problem and it is where the intellectual challenge exists. It is imposed by the nature of the problem we are trying to solve. Simplifying it may be a challenge, but it will be a good one.
Anyone who has participated in a software development project knows that it is not a walk in the park. Requirements change, deadlines can be short, unpredictable technical challenges arise, or scope changes.
All those things are normal, but it is important to pay attention. A distraction may result in being hurt by outside influences. For instance, it could lead to technical debt, and that is future complexity.
Complexity is created when we naively add it to our lives. I noticed that it was quite common for my team to try and predict the future, so we would implement a feature ‘just in case’ it would be needed one day. After attending a conference, reading an article, or watching a YouTube video, I would try to use the technology I just saw. I was finding a problem to my solution.
In those moments, I was adding complexity to my future and my team's future.
Being aware of the complexity’s impact, I started searching for role models. Apple is one of them: a brand associated with quality, perfection, simplicity, and user experience. Another example is Lego: a simple toy, but powerful when combined with imagination.
Both companies have one thing in common: simplicity. And if these brands thrive from it, why can’t we?
Besides branding, simplicity has many advantages:
- It is trustworthy;
- It reduces the cognitive load;
- It makes things more effective;
- It induces a sense of calm that reduces stress.
So, if simplicity is the solution to all that stress and anxiety, what can be done to simplify?
The first question to ask is: how simple should things be? The answer is that simplicity depends on the context. A medical device should be simple to my doctor, but I do not need to be able to use it – the same way my doctor does not need to know how to use Development IDE.
Sometimes, we must leave a given level of complexity in place. For example, it is common to swap confirmation buttons in the context of delete operations.
Another question is: will I seem lazy if the result is too simple? Absolutely not. Fighting complexity is hard, and we need to fight harder to keep complexity under control. But, in the long term, it will pay off.
Simplifying as a team
Fighting complexity alone will not work. Since the stress we’re discussing is work-related, and since, as an engineering leader, you do not work alone, you need a way to bring everyone to your side.
When I was thinking about this, I went to the Agile Manifesto to look for something that could help.
I found what I was looking for in the 10th principle:
'Simplicity – the art of maximizing the amount of work not done – is essential.'
The essence of this principle is to prevent us from going down the wrong path; to prevent us from bringing unnecessary complexity into our lives. So, if the best way to promote change is to lead it, what practices can you put in place to implement simplicity?
One way is to iterate as fast as possible and gather feedback as soon as possible. As soon as you and your team understand that you’re doing the wrong thing, the sooner you can prevent the stress that occurs from working on the wrong thing.
One of the practices you could adopt is pre-mortem meetings. A pre-mortem is where you challenge the team to find a way to kill an idea or a project. Everyone should go into attack mode and try to find the problems. By the end of these meetings, you will see that most ideas will need to go back to the drawing board or even be sent to the trash can, but this creates a culture where failing and learning is acceptable. When you foster this kind of environment, everyone wins.
Another practice is to involve the customer as soon as possible. Start drawing solutions using pen and paper and validate those mocks with the customer in quick iterations. By having that feedback before your team starts writing code, your product will be more effective, and the customer will be happier. The happier the customer, the less stressed yourself and your team will be.
When proposing a new solution, it is important to ask yourself the value of it. By asking the simple question of ‘Do I need that?’ you can prevent the creation of unnecessary work for yourself. Principles like YAGNI (You Ain't Gonna Need It) and KISS (Keep It Simple, Stupid) also teach us this.
Learning to say no
Besides questioning the value of everything, learn to say no. This is one of the most difficult things and I sometimes struggle with it, still. By putting yourself into stressful situations because you don’t want to be perceived as rude, lazy, or pessimistic, you are engaging in self-inflicted complexity. So, refuse invitations, express your disagreement, explain that you don’t believe in that deadline. These are all actions that can prevent you from pain further down the line.
I hate the expression, ‘Think outside the box’. It implies that you should be thinking without constraints. But constraints are liberating, and it’s possible to be creative with them in place. Personally, not having constraints causes me anxiety. Without them, I feel like an author staring at a blank page. In software, a constraint can look like a deadline, a legacy system, or even the project budget.
This journey taught me that being healthy is not just about diet and exercise. Being healthy is about our mind. But this is something that cannot be achieved with a two-week diet or a two-week vacation. Being healthy is a way of living – and it starts with controlling what is affecting our day-to-day, in our work and in our projects, and preventing ourselves from reaching a state of no return. Simplicity is contagious. If you lead with it, your team will follow, and your product will reflect it. As an engineering lead, your team is counting on you to be the role model and the first to question the value of everything. Now is the time to ask yourself: do I need that?