Back to resources

Are We Solving the “Right Problems”?


13 November, 2020

Michael Vanhoutte
Michael Vanhoutte

SVP Engineering at Ontoforce

Michael Vanhoutte, Chief Architect at Aprimo, discusses why it is important to establish that a problem you are trying to solve is the right one and how the engineering obsession with ‘fixing the problems’ can lead us astray.


In the world of perplexities and uncertainties, one is easily tempted to rush into solving the problem. Oftentimes, down the road, after much strenuous effort and countless hours, we would realize that the problem we are laboriously working on won’t solve customers’ needs let alone is aligned with the company strategy and goals. This challenge is proverbially captured as ‘when on the wrong train, every station will be the wrong one’. Having been there myself, I wholeheartedly recommend that whatever you do, ask yourself first if you are solving the right problem. Perhaps, you are only fixing a symptom or something of no use and could channel your energy on solving problems that matter.

Actions taken

To illustrate more clearly my position I would restore to three typical situations:

Solving a bug
Before digging any further ask yourself if the place where the bug appears is the place where the root cause of the problem is. Often, I see developers fixing the bug exactly where the customer has reported it. For example:

  • If the customer has reported that a certain value on an object causes the UI to crash, then it may be tempting to just update the UI to properly deal with that situation. But have you considered whether this value is even correct in the first place? And if the data is invalid, wouldn’t it be better to prevent this data from being there? By fixing the rendering in the UI, you may have inadvertently hidden the real bug. So, by “fixing” the UI you just made the identification of the real bug much more expensive.
  • Suppose a customer has reported that he is able to create objects containing some invalid properties using your REST API. Also here, one might be tempted to add validation logic to the API to ensure that the data coming in is indeed always valid. However, are you sure this validation logic shouldn’t be developed a few layers down in the business layer? Even if your REST API today is the only consumer of your business layer, who’s to say that there won’t be another consumer added 12 months from now? Maybe some bulk import capabilities need to be added and maybe these things will use your business layer directly. If you fix the bug in the REST API today, you are keeping the door open for the same bug once the bulk import feature is added. This means this bug would have to be fixed twice which translates into a much higher cost for the organization than simply spending a few more hours today to fix the bug in the right layer immediately.

People usually don’t do this out of laziness or malintent but often, in an attempt to resolve the bug as quickly as possible, people forget to stake a step back and really question if this is the right approach. Always question yourself: “Are you fixing the root cause or simply putting a patch on a symptom?”

Optimizing the SDLC
You have quality issues with your releases: too often you have too many bugs blocking a release, or even worse, ending up in production because it wasn’t detected by any of your quality gates. An easy and immediate conclusion may be that your developers aren’t writing enough tests and you may be inclined to push your team to write more automated tests. Again, before challenging the life cycle itself, check if you have overlooked some other issues much earlier on in your software development life cycle. Have you considered why your developers are not writing enough automated tests? Maybe that is the problem worth addressing. Perhaps the testing infrastructure is outdated or doesn't scale; perhaps it runs unreliable and people stopped running it because of this unreliability; perhaps it runs with too many false failures. Or maybe the way you used to write automated tests doesn't scale anymore with the size of your product. Or maybe some of the features aren’t tested properly because they are designed in such a way that makes testing difficult and that’s why developers don’t do it. There are too many ‘maybes’ that should be considered before you move forward with simply telling your developers that they should be writing more tests.

Developing a feature
Oftentimes customers push heavily for certain features and if they look valid at first glance, you may give in to the pressure. The feature sounds sensible and might benefit other customers, so why not do it?

But before continuing, have you asked yourself whether you are developing this feature for the right reasons? The feature may be nothing more than the customer’s answer to a problem that he is having. But if the customer would have simply explained the problem to you, would you have used the same feature to solve this problem? If you do develop this feature, are you intending it to be used for the use-case the customer is trying to solve? If you would know what is the problem that the customer is trying to solve, maybe you would have pushed for a different feature.

Lessons learned

  • Be patient and be confident to take as much time as you need to think about the problem and whether it is the right problem to put your energy into solving. Three examples above demonstrated how to avoid common detours engineers are facing when they are pressured to fix a problem instead of the problem.

  • The fast pace of the industry, pushy customers, demanding stakeholders -- all of them can drive you to a trap of solving the problem without establishing first is it the right problem to solve. Withstand the pressure -- analyze the root cause of the problem, question methodology and re-evaluate customers’ pain points before you roll up your sleeves.

Discover Plato

Scale your coaching effort for your engineering and product teams
Develop yourself to become a stronger engineering / product leader

Related stories

Managing Remotely: Balancing Team Cohesion and Focus Time

26 May

Jonathan Belcher, Engineering Manager at Curative, explains how to balance team cohesion and individual focus time, tapping into his experiences of working remotely for seven years.

Internal Communication
Psychological Safety
Jonathan Belcher

Jonathan Belcher

Engineering Manager - Patient Experience at Curative

Navigating Disagreements When It Comes to Priorities

9 May

Pavel Safarik, Head of Product at ROI Hunter, shares his insights on how to deal with disagreements about prioritization when building a product.

Innovation / Experiment
Product Team
Dev Processes
Conflict Solving
Internal Communication
Pavel Safarik

Pavel Safarik

Head of Product at ROI Hunter

Here to Make a Recognizable Difference: How to Develop Teams

5 May

Eric Merritt, VP of Engineering at, divulges on the many complexities of developing teams in management by solving problems according to their needs, and empowering teams.

Sharing The Vision
Coaching / Training / Mentorship
Eric Merritt

Eric Merritt

VP of Engineering at

Balancing Technical Debt Innovation: How Roadmaps for Development Help Your Company Succeed

4 May

Brad Jayakody outlines the roadmap to maintaining a healthy balance between technical debt and team growth. However, just as balancing acts go it is important to have a strong foundation.

Tech Debt
Career Path
Brad Jayakody

Brad Jayakody

Director of Engineering at Motorway

The Optimization and Organization of Large Scale Demand

4 May

Kamal Qadri, Senior Manager at FICO, drives the importance of setting expectations when optimizing large-scale requirements.

Managing Expectations
Team Processes
Kamal Qadri

Kamal Qadri

Head of Software Quality Assurance at FICO

You're a great engineer.
Become a great engineering leader.

Plato ( is the world's biggest mentorship platform for engineering managers & product managers. We've curated a community of mentors who are the tech industry's best engineering & product leaders from companies like Facebook, Lyft, Slack, Airbnb, Gusto, and more.