When I have 1:1s I frequently ask people what they’re working on and how it fits into the big picture of what the company is trying to do. It’s common for me to find places where someone thinks they’re working on the right problem, but there is misalignment.
How do you know if you’re solving the right problem? That’s what this post is about. I find that this problem exists at all levels of a company.
About twice a month, I’ll get someone coming to me to ask for career advice. I’m starting to collect the more common questions and my thoughts on them. I’m putting these together as a series of blog posts under the tag CareerPlusPlus.
Ask “Why?” Seven Times
It’s easy to say “Hey! Go solve the right problem!” But how do you do that in practice?
When my kids were younger I would sometimes get annoyed by how many times they would ask, “Why?” It was like they were a record that was skipping. They were trying to understand the world around them and there were so many things they didn’t yet understand. They wanted to understand.
We should all endeavor to be more child-like (note: not childish).
Let’s say you have some problem in front of you. Ask yourself why you need to solve that problem. It may seem obvious. But then ask yourself why again. What is there reason for the assumption that the problem needs to be solved?
The thing we’re trying to identify is not if you’re taking the correct approach to solving the problem, but if you’re solving the right problem at all.
A Common Pitfall
The most frequent problem I see when facing a problem is that people reach for solutions that are known or familiar to themselves, even if it isn’t related to the core problem. People are often trying to do the right thing, but don’t always know how to do the right thing so they try to solve a problem they know how to fix.
For example, we had a problem where our simulation engine was not correctly reproducing how other cars would respond in a particular situation. It was a very complex problem with a dynamic elements that needed to be recomputed in real time to give emergent behaviors. I assigned this problem to a very hard working engineer. They went away happily and worked on it. When they came back to show me the results, they had been working on a completely different problematic behavior they found in the engine. The thing they worked on didn’t impact the final simulation results.
What happened here?
I gave them a very hard problem to solve and they didn’t know how to do it. When they looked into what was happening, they saw a different problem that they did know how to solve. They wanted to do well, so they went forth and fixed that issue. Then they came back to happily show me what they had done.
It’s very common that things like this happen. Most people are trying to do their best, and this person was no exception.
Tips to find the right problem
There’s a saying that months of coding can save you hours of planning.
Do a repeat back. One of my go-to strategies that I found very annoying when I was starting out was to repeat back a problem and approach in my own words. I hated doing this early in my career, but it’s something I’ve learned to embrace because it saves me a ton of rework.
When I get near to the end of a conversation, I usually say something like, “Ok, can I repeat this back to you to make sure I understand we’re on the same page?” Then I put into my own words what the problem that needs to be solved is, why we think that’s the core problem, and what my specific technical approach is going to be. I usually even outline the first few steps I think I need to take.
This gives the other person the opportunity to interrupt or correct me before I even begin work.
Get out your rubber duck. Once I have the problem firmly in mind, it’s often helpful to run your solution by another person. Sometimes they’re just a rubber duck, and sometimes they’re proving a lot of feedback. Either way, it’s useful to outline in your own words how you’re going to solve the problem.
When you are the rubber duck, your job is to see if the plan they are outlining really is solving the problem. Not only is it technically a valid approach, but does it even address the core issue?
Give useful status updates. When working on a problem, it’s all too easy to try to slide by and say “making progress” or “working on some issues.” These don’t really say anything. I know a lot of people don’t like to give detailed status updates for a lot of reasons. I encourage you to let go of that and be specific when giving an update. “I’m working on an issue where the velocity estimates don’t match expectations in X type of simulations” is a far more useful update.
By giving these kinds of specifics, it gives the others you are working with an opportunity to check in on why you’re doing that. They can ask the Why that I suggested above. Will this make your work more difficult? Maybe in the short term. But if you course correct early you can save weeks of work sometimes.
What if I don’t know how to solve that?
Swallow your ego and ask for help.
My own ego has been my biggest hindrance to my own progress. I’ve learned over the years that the statement, “I don’t know” is a statement of strength, not weakness. Not everyone feels this way. In fact, many don’t. Toxic people will always be toxic, but I can’t control them. I can only control myself and my actions.
I can tell you that I’ve never regretted admitting that I didn’t know something.
Closing Thoughts
A book recommendation! I rarely do these. What’s Your Problem by my friend Thomas Wedell-Wedellsborg is an excellent resource. It’s not just because Thomas is an excellent person (which he is), but also because he’s written an entire book about doing this very thing. I’ve seen one of his talks, and I cannot recommend them highly enough.
Making sure you’re solving the right problem is one of the hardest things I’ve had to learn how to do. I find that it needs to be an interactive process.
Good luck!