Problems crop up all the time. That’s a rule of nature. The question is how we address them. Many leaders get tunnel vision and rush to get the thing sorted out. Sometimes, that’s a surefire way to keep seeing that problem repeat itself.
I’ve found that we can uncover a lot of issues so much faster by learning to ask the right questions. Knowing how to wield critical thinking, and specifically some healthy diagnostic questioning, can make all the difference. Let’s cover the must-have questions you should have in your diagnostic toolbox.
Discovery and Awareness
These questions are aimed at understanding the issue at hand, its start, and how you got to this point.
Why have we only noticed this now? We start by making sure that we understand when the issue started and questioning why we only became aware of it when we did. This aids in realizing whether there are other blind spots or broken parts in your monitoring.
Was it always like this? There’s a big difference between something that was always like that yet only now has reached a point where it is problematic (e.g., a system that you knew would never scale past 20 clients) as opposed to a deviation from a better past situation.
Was anyone aware of it prior, but didn’t speak up? I still remember the lightbulb moment when I first saw Sherlock Holmes pose the “why didn’t the dog bark” question. In our context, the question is whether the issue was already known and on someone’s radar, yet they didn’t alert others about it. Is there an underlying issue of safety and security that prevents people from communicating effectively? How can you be sure there aren’t other similar issues already at play?
What is the trend of the issue? Is it actively getting worse? Or remaining about the same? This is important to understand the actual urgency of the problem. If we’re talking about something that will only keep getting worse, and fast, it should probably become everyone’s top priority.
What are we not seeing? What are we assuming and don’t have data to support? This is about making sure that what we’re describing as the problem is all grounded in evidence. Otherwise, at least let’s be clear about our assumptions and state them as such.
Scope and Context
Is the issue localized to a specific team, specific type of client, specific period of the year, etc.? Or is it wide-ranging? If the problem is particular in scope, handling it is often simpler and localized to that part of the organization/product. It also might mean that we handle it better somewhere else, and thus can bring in that internal expertise to aid.
Is this unique to us, or is it a common issue in the industry? I’ve seen teams very worried about things that are essentially accepted as truths across the industry. Whereas sometimes that’s an opportunity for disruption, most of the time it’s healthy to understand what the industry’s accepted bar or thresholds are, so you can tell whether you actually have a problem or are deciding to engage in finding an innovative and novel approach.
How are other companies addressing this issue? You don’t have to come up with solutions all by yourself all the time. I repeat to my clients that innovation is great, but you cannot be innovating all the things everywhere. Best practices are there for a reason.
Decision Framing
Do we have to fix this? The lazy programmer question of the day. Just because the issue exists and you realize that it’s not perfect doesn’t mean that it warrants prioritizing. Some things we can just live with. When that’s the case, you should also remove it from your backlog. Don’t let things rot there if you know you won’t address them in the foreseeable future.
If we have to fix it, do we also have to get it back to how it was before, or is there a better solution? The knee-jerk reaction when something breaks is to rush and put it back together the way it was. However, sometimes we can use this opportunity to do things differently. Perhaps you don’t have to invest in getting it exactly the way it was, because the fix would be too expensive and not worth it. Or maybe there’s a workaround.
Are there positive aspects of the problem that we can leverage? A startup I was working with lamented that, being remote-only, they were having issues hiring engineers who really understood the product and the product, because they didn’t get a lot of time with the product people and tended to work on their own things. Instead of taking steps back and starting to hire people in the same office, when we talked about it, they realized that this could be turned around as an advantage: they made each engineer involved in localization and adjustments to their local market of the product.
Is this a wanted mistake? This means, is the problem something that, knowing what you knew at the time, you still made the right call, and the problem is the cost of doing business. You cannot aim to avoid all problems, because then every step would become too slow and costly. Assess your accepted level of issues and live at peace with it.
Constraints and Hidden Dynamics
How would you address it if you knew no one would get angry/offended? As you’re starting to consider how to address the issue, it’s important to be genuine with ourselves about the limiting factors that often go unsaid. Is there clearly a “right way” of solving it that you’re avoiding due to politics, avoiding difficult conversations, and similar?
Is there anyone who benefits from the situation being as it is? Is there a hidden reason that explains why the problem even happened in the first place, or was allowed to continue for as long as it did? Would there be any negative effects to fixing it?
If we were starting from scratch today, how would we have addressed this? Try to remove the constraints of the present situation and all the history that got you to this point. If a day-old startup were to decide to tackle this, would they do something substantially different? Is there anything you can learn from this thought experiment?
The right question at the right moment can save months of misguided effort. Your job isn’t to have all the answers. It’s to know which questions your team isn’t asking yet. If you need help asking the right questions, let’s talk.