Plato Elevate Winter Summit has been announced (Dec 7th-8th)

🔥

Back to resources

Are We Solving the “Right Problems”?

Impact
Productivity
Prioritization

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.

Problem

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

Demystifying the Cult of the Founding Engineer: Talking to Customers and Discovering “Hidden” Talent

23 November

Albert Lie, former Founding Engineer and Tech Lead at Xendit, didn’t know what it takes to become an early engineering hire and not a lot of people around him experienced this unknown and arcane path. He had to learn it the hard way from the pitfalls he encountered along the way and he has been creating numerous frameworks to measure his growth and keep burgeoning in this role since then. He codifies and expresses the systems he put in place surrounding the balance of customer inquiry to product building and growing the engineering team.

Alignment
Meetings
Feedback
Hiring
Prioritization
Albert Lie

Albert Lie

Former Tech Lead at Xendit

Succeeding as a New Product Manager

5 November

Sydney Russakov, Senior Product Manager at LinkedIn, shares how she aced her role as a new PM in a different team.

Remote
Internal Communication
New PM
Prioritization
Sydney Russakov

Sydney Russakov

Senior Product Manager at LinkedIn

How to Encourage Innovation in Your Team

5 November

Prasad Gupte, Director of Product at Babbel, shares how he drove innovation through structure, collaboration, and autonomy.

Innovation / Experiment
Product Team
Collaboration
Prioritization
Prasad Gupte

Prasad Gupte

Director of Product at Babbel

Finding the Career Path for You

4 November

Joey Lei, Principal Product Manager at Kasten, shares how he reached the realization that he needed to pivot in his career path and changed course.

Managing Expectations
Personal Growth
Impact
Career Path
Joey Lei

Joey Lei

Principal Product Manager at Kasten

Simplifying and Prioritizing Key Objectives

28 October

Michael Sobota, VP of Engineering at Uplight, states his most recent experience refining the goal-setting process, using key objectives.

Alignment
Goal Setting
Motivation
Prioritization
Michael Sobota

Michael Sobota

VP of Engineering at Uplight

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

Plato (platohq.com) 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.