We are Problem Solvers
Recently we had a situation meeting here in the office. We gathered all the high personnel, booked the situation room and closed the door. Only the red line was active.
The problem? A client of ours was in dire straits with a software that was previously developed by some other company.
The situation was complex.
One of our senior developers was in a meeting with the client trying to understand the problem and how we could help. He was fuming. The application wasn’t working properly. They were very upset and had no idea on how to solve the problem:
- Should we throw it away and redo the whole application?
- Is it a matter of technology? Should we use some other software development language? .NET, Java, OutSystems?
- Is there a solution at all?!
I know it seems I’m exaggerating… but I’m not.
A few hours into that discussion, our senior developer called me and said, “I think they really need us to think about the problem.”
And that’s how we found ourselves in that situation room.
#What does it mean for us to be problem solvers?
Let me take a step back.
Since the beginning we see ourselves as problem solvers, not task-doers. That is reflected in everything we do:
- Who we hire;
- How we recruit;
- How we treat the others in the company.
This doesn’t mean we can’t do a task when one is appointed to us. It doesn’t mean we don’t write many lines of code, or that those lines of code don’t have to be skilled.
Quite the opposite. We do all those things. It just means that our metric for success isn’t how many lines of code we write. Not even how many good lines of code we write. Our metric for success is how many problems we solve. Regardless of how many lines of code are needed to solve it.
It means that when we have a task to do, we really put our minds into it. We really try to understand what it is meant to do. It means we don’t feel successful if we deliver the best code ever written just to find out it’s in the wrong kind of software or that it will not solve the problem at hand.
It’s important to give the perfect answer, but only if we are replying the correct question.
#What was the correct question to the initial problem?
What does it mean to have a problem-solver mindset?
In the day-to-day activities, what does it encompass?
I’ll use the example from the beginning of this post to illustrate it.
After that initial call and a quick situation meeting, three of us gathered to talk about the problem and consider the possibilities.
I will not dwell into the particular situation here. That’s a topic for some other post. What is relevant is where it led us – the Near Partner team and the client.
It led us to that problem-solving mindset that questioned everything, including if those first questions were the right ones. We stepped aside and questioned the assumptions (Yes, we can’t leave our agile mindset as well!):
- What was the problem the client was facing?
- Is there a technical limitation?
- Is the problem the architectural solution?
- Was it a communication problem with the development team?
- Was the business analysis correct?
- Were the requirements checked along the way with the business team that was actually going to use the application?
The client was on the verge of deciding for a new application. And that was a huge decision with costly implications. The “spaghetti” was so much intertwined it seemed there was no other option.
However, when we all began to talk and ask the right questions, we began realising there might be another solution. Maybe we could re-use part of what was done. Maybe all that was necessary, was to refactor some of the software.
Some of the requirements were not correctly implemented, but the core was there.
Was it perfect? No. But it already existed. It was defective but working.
Were there other options – both in terms of the technology chosen and the architecture implemented? Of course. But these were implemented, and you could sense their flaws. The other options were utopically optimal, but we were yet to face their road bumps – and for sure they would exist.
Was it possible to correct the problems? Absolutely.
Did it require some work? Definitely. But much less than just throwing everything away and doing it all again.
In the end, we realised the parts needing refactoring were fewer than what was initially considered. The application was upgraded and perfected and it’s currently alive and kicking.
Solved problems is our success metric
Would our success metric be “how many lines of great code can we produce” and we would definitely be creating a brand-new application.
Would it be better than the one existing? Quite possibly.
Would the problem-solved count be better than the one our client has today? Definitely not.
We’re just happy our metric is “solving problems”! In our opinion, it is much better 🙂
What about you? Do you have that problem-solving mindset? Are you looking for problem solvers in order to help your business?
Let us help! Share your needs with us.