Some days it doesn’t pay to get out of bed
Alex is a lead software engineer at fortune 500 Fintech company. And, as with many Fintech companies that handle automated trading, pushing a breaking change in to production is not only expensive from a “lost revenue” perspective but it could have real compliance and legal consequences as well.
Now, I realise that in the real-world, the software architecture team and the DevOps process should have checks and balances that would prevent something of this magnitude from making it in to production, but, as I said, this is fictitious so let’s just get on with the story…
Alex, is responsible for overseeing the development of their flagship product—an automated trading system. Eager to implement a new feature that would have a significant performance upside, Alex ran through the multiple hoops to ensure his changes were properly tested:
Unit tests – PASS
Integration tests – PASS
Manual tests & QA – PASS
E2E tests – PASS
Alex carried on with the next story in the backlog, until notifications started streaming through on the “Production Issues” group.
After having read of the complaints he knew that it could only have been as a result from the change he had just made. He had introduced a critical bug. It started to manifest as significant discrepancies in trading data, possibly leading to real financial losses and reputations damage.
Then the dreaded call from the CTO comes through.
Initially, Alex approached the problem with a technical mindset, believing that a solution was just a matter of tracing and fixing a few lines of code. However, as the bug proved elusive and the client’s frustration grew, the pressure from both his managers and the client intensified. Meetings became frequent, focusing more on the severity of the repercussions and less on potential resolutions. Each session added more stress, spotlighting the negative consequences rather than fostering a constructive discussion about possible solutions.
Feeling increasingly anxious about this—Alex’s focus shifted dramatically. He began to dwell extensively on the mistake that he had made, ruminating on his decision rather than focussing on a solution.
He was now fully focussed on the problem and what could happen as a result of this mistake. Was he going to get an official warning from Human Resources? Would he be fired? What about finding a new job, would this follow him in his career—oh man, oh man oh man!
His interactions with the team became strained, as he subconsciously started to view their suggestions and questions as critiques rather than as collaborative efforts to resolve the issue. The high stakes and the immediate demand for solutions only heightened his fear of further failure, overshadowing his technical skills and problem-solving capabilities.
I’m sure you can imagine that, in the direction that Alex is headed, things are probably only going to deteriorate further until either he turned it around and was able to focus on a solution or suffered the consequences of not being able to come up with a solution when he needed to the most. This, unfortunately, is what work-stress can look like.
Alex’s shift towards a problem-focused mindset clouded his usual analytical abilities, causing him to fixate on the problem’s potential impacts instead of navigating towards a resolution. This scenario demonstrates how a problem-focused mindset can take root, particularly under high pressure conditions and the personal responsibility for a critical mistake.
So what could this have looked like if Alex’s manager had understood the pressure that Alex was and recognised the symptoms of Alex’s problem-focussed mindset?
Alex pulls it back
…so after a few of the meetings, Alex felt like everyone was criticizing his code. On top of that, he was criticising himself. “How could I have let this happen?”
Then Alex’s manager, Brett, calls him to his office — “This is it”, Alex thinks, “I’m gone”.
“Close the door,” says Brett. Alex bracing himself for the worst, expecting a severe reprimand or even termination. But Brett’s next words take him by surprise.
“Alex, I know you’re feeling the heat right now, and it’s understandable. This is a tough situation, but I called you in here to refocus, not to reprimand you.”
Brett continues, “We all make mistakes, and yes, this is a big one. But what defines us isn’t the mistake itself; it’s how we handle it going forward. I’ve seen your work, and I know your capabilities. Let’s channel our energy towards solving this issue.”
Feeling slightly easier, Alex nodded, still tense but listening. Brett pulled out a whiteboard, “Let’s break it down together. What are the key components affected by the bug? Let’s map everything out and tackle them one by one.”
They spend the next hour diagramming the problem, identifying root cause or the possible hiding place of the bug could reside. Brett even suggests bringing in a couple of other team members who had dealt with similar issues in the past. “Let’s collaborate. More eyes might see what one pair cannot,” he proposes.
Encouraged by the constructive approach, Alex, can’t explain it exactly but definitely has some clarity – his mindset has started to shift from a problem to a solution midnset. The meeting concludes with a plan of action and clear, achievable goals. Brett reassures him once more, “This is a learning opportunity for all of us. We tackle this as a team, and we’ll learn as a team.”
Back at his desk, Alex sends out emails to gather the team. The response: immediate and supportive. The collaborative atmosphere during their brainstorming session was a stark contrast to the previous meetings. Ideas flowing, and with inputs from different perspectives, Alex and his team are able to find the root cause, isolating the bug and develop a patch to fix it.
As they tested the solution, Alex feels a renewed sense of confidence. Not only had he learnt a valuable lesson about dealing with high-pressure situations, but he also experienced firsthand the power of a solution-focused approach. This experience not only helped him grow as an engineer but also improved his leadership skills and resilience.
The bug was fixed by the end of the day, and although the aftermath involved some damage control with the client, the proactive approach in resolving the issue swiftly and transparently helped restore some of the trust. Alex’s manager commended him and the team for their quick response and teamwork, turning a potential disaster into a testament to the company’s commitment to excellence and continuous improvement.
So how did Brett get Alex to switch to a solution-focussed mindset?
Let’s first understand what exactly a solution focussed mindset actually is and then we can look at how I think Brett would have gone about coaching Alex back from the edge.
These principles form the core of solutions-focused thinking:
Focussing on solutions over problems
Adopting a solutions-focused mindset means that we shift how we approach the challenges we encounter. Instead of getting stuck on what went wrong, we direct our energy toward what we want to achieve and to figuring out how to get there.
Leveraging existing strengths and resources
By focusing on what we’re good at, and the resources we have at our disposal, we unlock creativity, we boost our confidence, and instil a proactive “can-do” approach to solving problems.
This means focussing on past success – what had already worked for us, what still works for us, and use these personal or professional strengths to address the challenge and reach our goal.
Becoming resourceful and identifying any training, books, skills, support systems and people networks or any other relevant resources that we can use will help address the challenge.
Using a future oriented approach
By adopting a future-oriented mindset, we focus on the opportunities rather than setbacks, putting us in an optimistic frame of mind and enabling us to overcome challenges and progress towards our goals.
We can use techniques like “The miracle question” and vision boards to maintain this focus and help us visualise and work towards our objective. We’ll go in to these techniques in a bit.
Seeking progress rather than perfection
Striving for perfection often leads to disappointment and frustration because, achieving perfection is typically unattainable in most scenarios. And this can trigger feelings of failure and kill our motivation – if we can get it perfect, why bother.
Instead, we should be focussing on any progress because that starts encouraging us to build momentum towards our goals.
We do this by establishing attainable and measurable goals and we “bank the win” when we can to celebrate the small victories along the way.
Let’s look at some of the techniques Brett used to coach Alex
Now that we understand the principles, we can discuss the specific techniques for helping you coach someone to shift their focus from a problem to a solution mindset.
The underlying thread that joins all of these techniques is that they are here to help us generate ideas when we’re stuck. They elicit out-of-the-box thinking by including ways to identify and generate creative and innovative solutions. Some techniques stimulate the right (creative) brain to come up with the idea and some of the other techniques using distraction to break the normal thought pattern to encourage creative thinking and ideas.
Here are the techniques:
Reframing questions
Changing the way that we ask questions is a technique that helps remove us from our current train of thought by giving us a way to change the context of a question. Essentially, instead of asking what the problem is, we can ask “When does the problem no longer happen?”.
The key to reframing questions is to focus on solutions from the beginning. By doing this, we can avoid getting stuck in the negative mindset that kills creativity and prevents us from thinking, innovating and coming up with effective solutions.
| Description of the technique | Instead of being… Problem focussed | Reframe to be… Solution focussed |
|---|---|---|
| Shift the focus from the problem to the desired outcome (the solution). We do this to stimulate creativity and help us to identify alternative solutions giving a better chance to achieve what we want to. | What is the problem? | What’s the solution? |
| The idea for this transition is that we approach the problem with a more optimistic and/or proactive mindset, making it easier for us to identify solutions. | What are the obstacles? | What are the opportunities? |
| Reframing questions and focusing on the exceptions to the status quo takes us out of the default mindset and stimulates us to identify a variation of the obvious scenario(s) to where the problem is not present. Looking at it differently like this can help give us clues about solutions that might be effective. | What are the causes of the problem? | When does the problem not occur? |
Scaling questions
A scaling question is used to measure progress and identify smaller steps that can be taken to get closer to achieving a goal.
Here’s an example: I like to call this a “Synthetic scale”. The idea is to introduce a fake subjective scale to provoke thought:
- On a scale of 1-10, how do you well do you see this shopping-cart working?
- Really, a six? What do you think it will need to get a 10? OR Really, 10? What are they doing well? What can we do to bolster this score?
Having this conversation gets the interviewee to think about what’s missing or what is not working, or what is working but approaching it from a slightly different angle to promote different ideas.
The main objective with scaling questions is to:
- Break a larger task down in to smaller more easily trackable and SMARTer steps.
- This allows an easier way to track progress over time AND
- It makes progress more visible which can be a powerful motivating factor.
Miracle questions
This a technique borrowed from Solution-Focused Brief Therapy (SFBT), taps into creative and imaginative thinking, which is referred to as the “right-brain”.
The “miracle question” is designed to help clients picture a future where their problems are resolved or their goals are achieved. By asking something like, “Suppose tonight while you sleep, a miracle happens and the problem you have is solved. When you wake up tomorrow, what will be different that will tell you a miracle has occurred?”.
This frees the person being coached to think beyond their current limitations, perceived or otherwise, and challenges allowing them think out of the box and come up with potential solutions they may not have though about otherwise.
Exception-seeking questions
The idea, much like the miracle question, the scaling question and the reframing questions before that, is to get us to look at the whole thing from a different perspective and disrupt habitual negative thinking.
It would probably happen like this: The person in need of coaching, has probably already gone through the obvious (to them) default approaches before starting unravel, and now they’ve reached the stage of being problem focussed. In fact they’ve probably tried a bunch of things and exhausted most of their default options.
This is a great time to introduce “exception-seeking questions” because chances are, they’ll come in handy. As explained above, when asked correctly, they disrupt the habitual (autopilot) thinking and change the person from focussing on the current problem to where, either the problem didn’t ever/hasn’t even occurred OR where the problem was way less severe.
Here’s a scenario to illustrate what I mean:
- Ordinarily, I would solve a problem by looking at how I’ve done it countless times before. This looks at the skills you’ve used to solve this before. But this isn’t solving the problem this time though.
- But what if I looked at the times when the problem COULD HAVE occurred but DID NOT. What this does is directs us to explore the instances of when everything worked correctly to try find what caused that – a complete reversal of the way we approach this by default.
The questions could look like this:
- “The API endpoint is returning a 400 bad request, but you’ve managed to call it successfully before. What did you do differently then?” OR “How has the environment changed since then?”
Three tips for to think of thoughtful and effective questions:
- The person that you’re trying to coach needs to be receptive to this line of questioning. If they’re still problem focussed, they’re going to find it difficult to switch to the exceptions.
- Once we’ve identified an exception that we can use, we need to to encourage the developer (or whoever we’re coaching) to elaborate on the specifics of the exception and how they might replicate or expand on that successful instance.
- Insights gained from the exception should be integrated in to any action plans or future goals to reinforce the lessons learned here.
Coping questions
We use coping questions to remind the person we’re coaching about a time when they’ve coped successfully with a challenging situation in the past to remind them that they have the ability to cope. The idea is to put them in the frame of mind where they were able to successfully overcome the challenge.
We can use questions like:
Do you remember the last time we had a container that failing and you weren’t able to diagnose it? Deep dive in to some follow-on questions:
- What did you do to get started?
- What was your process?
- Okay so once you had the problem diagnosed, how did you go about fixing it?
Remember when we had the application performance issue last year? And then drill down further…
- What were the steps we took that led to resolving the issues effectively?
- Can you recall how we approached the problem-solving process during the database query challenge? What methods from that time can we apply to our current situation?
- Did we perhaps collaborate differently? How did that help get us to a solution? What aspects of our teamwork can we replicate now to address our current issues?
These questions are particularly effective when the person you’re coaching is feeling overwhelmed or despondent and can’t see the wood for the trees any more.
Brainstorming
I can’t think of many people who haven’t heard of brainstorming so most of us know how this works. We create a safe space where people can think creatively and they understand that their ideas are valuable to encourage them to share if they aren’t completely validated.
This is an important idea generating technique and the best ideas are usually ones that haven’t been filtered. Once again, not all ideas will work nor will most of them could work but we share them anyway.
Once we’ve generated ideas, we can start running through the list to select the ones that seem like they could address the challenge. Get rid of the ones that we know won’t.
Validate the remaining ideas one-by-one.
Mind mapping
Similarly mind-mapping is a technique that as technical leaders, I’m sure have used before. You start adding ideas/nodes that relate to the nodes on the map until we have a tree structure branching away from a core idea. It helps identify seemingly unrelated topics that allow us to creatively generate new ideas.
Once we’re satisfied with the tree structure that we’ve generated, we can group homogenous ideas together or do the opposite as long as they’re organised in a way that moves us closer to a solution.
And now, Alex needs to get it done
Now that Alex and Brett identified a list of candidate solutions, it’s time for Alex to choose the right one and get started.
Prioritise the list of candidate solutions – With the list of solution, Alex needs to start prioritising the list using the following criteria:
- If they decided on a particular solution, will they be able to execute? Can it be reasonable and realistically implemented? Are there resources to execute (feasibility)?
- How well will the solution address the problem, will it work with the existing eco-system and will the solution stand the test of time (impact)?
- And lastly how urgently do we need the solution and how quickly can it be delivered? (urgency)
Based on the information in front of him, Alex chooses what he thinks, is the best candidate.
Breaking the solution down in to a list of tasks/goals
Using a top-down approach, Alex broke the solution up in to tasks, into something workable and achievable.
Now he can start understanding what we’ll need to complete and who and what resources will be needed to get to the solution.
As long as Alex knows that he’ll need to stay flexible because this plan may need to be adjusted if something doesn’t work, he’ll be fine.
Now with some collaboration and, if necessary, create spikes to build POCs and run experiments for the tasks that need additional investigation, Alex carried on and got the job done…
…successfully.
And so, in closing…
Everyone learnt something here. Brett was able to bring Alex down off the ledge and once he had a solution focus, Alex found a solution and deployed to production bringing this whole story to an end. He had grown from the experience and now had another in his toolbox for the next time he’s under this kind of pressure.
Brett felt fulfilled because he walked away having made a difference in Alex’s career.
And the problem was solved – well done everyone :)
I’m loving the fact that we’re building “frameworks” not only for the hard-skills but now for the soft skill as well. I love this and I feel better equipped for the next time that I need to really help a peer or a developer in a team that I’m leading, and I hope you do too!
References and recommended reading
While understanding Solution-focussed coaching, I found these books to be quite useful. There was no ways to finished them but they seem to well regarded from the reviews:
- Thinking Solutions not Problems by Benjamin J Boyle
- Brief Coaching: A Solution Focused Approach – goodreads | amazon.nl
- The Solution Focused Brief Therapy Diamond – goodreads | amazon.nl (kindle) | audible.com


