Meta problems: The hidden dragons
Let’s define them. Meta problems are problem-sets that are secretly the direct cause or a major contributor to many other problems. If they are addressed so are a large number of issues alongside them. They are also known as Keystone Problems or many other names.
To be honest, even calling them problems is kinda tricky because they might also be in the form of missed opportunities. Think that you have a genie that can grant wishes for your organization. What would you wish to be changed? That is a meta-problem.
Solving these types of problems/problem-sets results in huge enhancements to overall processes and downstream systems. Ranging from performance improvements, huge cost savings , eliminating huge chunks for work / even teams or aligning a whole organization in a certain direction.
As we will explain, these problem sets are normally:
- hidden or hard to pinpoint
- require a huge amount of effort to address
- are hard to find solutions for / require intentional trade-offs
- drain huge amounts of resources if left unattended
Examples for Meta problems
Before this gets too abstract, let’s start with some examples of these kinds of problems:
- The dev team complains that they can’t test performance of certain things because production workload is different. As an “intermediate solution” someone goes and runs those certain queries manually in production and reports that they need some tweaks . This is reported again a month later on another issue. There is always “bad code” being merged causing issues for the production system.
- Customer success team has trouble finding the necessary information for a customer interaction with the system. Sometimes they can’t find any records of a customer claim at all. It looks like nothing even happened. As a “workaround” someone from the team goes and tries to repeat what the customer reported and tries to manually detect the issue. Another customer reports a slightly different issue (but of the same nature) a month later. The team is always scrambling to keep customers happy somehow.
- The CFO is always complaining about the cost of operation. The dev team goes in circles explaining why the costs are needed and justify each individual cost factor. As an “interim” solution the organization finds some other ways to cut costs (including laying off people)
The who
As people get promoted up in an organizational chart, they “should” spend more and more of their time solving meta-problems and less on normal problems. It can be counter-intuitive to do this transition because as you get more experience, you become really good at solving normal problems so it is easier to keep that flow going.
Most of the time, meta problems are solved by people who stay in organizations long enough to understand systems/pipelines/processes end-to-end. They also have the authority and expertise to solve these problems without leading the organizations into an iceberg in the process.
Solving a meta problem feels like diffusing a bomb. You are normally addressing some critical aspect of a process or domain with a lot of stakeholders involved. If you make mistakes they are normally costly. If they weren’t, someone else would have picked them up sooner and had solved these problems.
So the person who takes on these problems are risk takers. They understand the high stakes but they dive in and address these issues anyway. The rewards on the other hand are normally huge. They result in company’s success in a certain angle.
How do we detect the meta problems
Meta problems are very different in nature every single time. But they have some common characteristics that can nudge you into detecting their presence.
First of all , They have symptoms that are repetitive. If you see folks complaining about a problem every month / few months and then someone goes and “patches” the issue, that is normally a sign that there is a hidden a Meta problem. This also means that you can see them if you are paying attention. These are normally costly issues and most the time someone (or a group of people) are paying the price by “patching” these problems or taking on huge amounts of toil.
Domains get “hardened” when people add tools/processes to solve them. The bad news is that once these things are in place, there is less room to be creative about them. You can’t just move things out without breaking something (unless you have an elaborate plan for doing so and somehow convince everyone). This is the exact reason why green-field projects are so easier to deal with.
How do we address these problems
Observe
Try and understand how everything works first. If you feel like something “obviously” shouldn’t be there or be in a different way, you are likely wrong. Things happen for a reason (not necessarily a good reason) and you have to understand those reasons first before changing things.
Earn Trust
Try to earn enough trust in the organization to be able to pull off something of this order. If folks don’t trust you, there is no way you can fix a meta problem successfully. The process normally needs a lot of communication and normally consensus by different stakeholders. You will also need resources. Including but not limited to: time, money, other people’s time. interruptions and etc.
Define it
Before moving to a solution just try to articulate what you feel is wrong first. Gather evidence of the symptoms you used and how you attribute things to this problem. Share the findings with someone you trust to give you early feedback. Try to see if they also see it as a problem and if not, try to see why. If you still think this is important, Don’t get too fixated on convincing people yet (As folks might be biased towards a certain way), when you are ready, share it with more people and try to get more eyes on it. Importantly share it with folks that have to fix your mistake if you are wrong.
Do your homework. Check it twice
If you are coming with a creative solution to a certain important problem set, you must be able to back it up with evidence and a clean path forwards. Importantly you have to meticulously work on your migration plan to the proposed solution. Your idea has to make sense to you first end-to-end before you can convince someone else.
Be prepared to be disappointed
Because of the nature of these problems, you might (most certainly will) face some resistance if you are picking an important enough issue to fix. It can happen for many reasons including but not limited to:
- Folks don’t believe you : normally because you haven’t done a good job of convincing them, you didn’t gather enough evidence or your communication style just doesn’t fit the way their mind works.
- They don’t have time to go through the process with you but they also can’t just leave it to you to decide
- Any real change is hard. folks might not be ready to take on the challenge alongside you (since normally you are implicitly involving them too).
- You are simply wrong. There are reasons for things that you have not considered.
- They are just not interested in helping you
If one of these happen, go through everything again .Try to understand the point of different people involved and go triple check everything again. Ask folks for explanation. Ask for help. Change your strategy. try to arm yourself with as much ammo as possible.
Be ready to let go
Sometimes you have to lose a few fights. It is hard to take on risk, show up for it, do all the work and at the end of the day, run into a brick wall but it happens more often than not. Try to not take things personally and reflect on the process you went through from start to end. Fix your mistakes next time.
Not all Meta-problems are immediately fixable. Sometimes you go back to them a year later with a different perspective, set of ideas / leverages. Try to be patient and observant.
If you manage to fix a few of these problems. It will already be enough for the organization to appreciate your work and recognize your work.
Remember you are not always right either. Sometimes even the timing just doesn’t make sense. So you have to be flexible and understanding throughout the whole process.