“Fall in love with the problem, not the solution”. If there is one phrase I repeat the most to clients, it’s that one. And what I mean by this is simple: focus on solving the problem, and don’t get caught up in creating the perfect solution.
Fall in love with the what?
Typically when we have a big problem to solve, we get wrapped around the axle of building the “perfect solution”. This is perfectly natural, because we want to do great work, build cool stuff, and look good doing it. But chasing that ideal solution can be incredibly costly in terms of time and money. Don’t get me wrong, there are absolutely times when this (being perfect) is required. But usually… we‘re spinning our wheels, and not going anywhere. We lose the forest for the trees; we forget about the job to be done.
This (keeping things in perspective) sounds incredibly easy, but I find that pulling it off can be challenging. Especially when it comes to large programs, where there are multiple decision makers at various levels, different teams and stakeholders, and varying incentives for all the parties involved. And in instances where there are shiny, new or innovative technologies involved? Good luck!
Illustrating this Concept
Let me give you a tangible example of where you may encounter this scenario.
Example Scenario: Data Ingestion Design
Let’s imagine that you are a lead (technical or otherwise) on a program and need to design and implement a cloud native architecture for ingesting data at scale on Google Cloud (substitute your cloud of choice, I’m sticking to what I am an expert in). This is for a large ecommerce site. There are several parameters you need to consider:
Streaming data (usually event related data, like clicks, transactions, errors, etc) that is processed and ingested in real time
Batched data (data like daily store sales, end of day inventory, etc) that is processed together in larger windows
The data will be used for traditional business intelligence, predictive analytics use cases and for the recently released GenAI chatbot
Overall service reliability should be between 1 and 2 “9s” (between 90 and 99%)
Ensure it is secure at all layers
For each of these parameters, there are lots of options. Do we use Spark, Flink, or DataFlow for streaming? How about Kafka or PubSub for events and message queueing? Do we use Airflow on GKE, Cloud Composer, or Argo CD for orchestration? Do we use different data stores for the different end use cases?
All of these questions (and more) will influence what design you end up with. And your counterparts will inevitably influence you too (e.g. “I’ve always wanted to work with x…”), and the path you take together. And you may spend countless hours designing and iterating on on permutations trying to get to the exact, perfect solution.
Other examples
You may see this come up regularly whenever there is a group dynamic and some large decision to be made. A few other examples:
Organization design
Sales account strategy and planning
Product roadmap and development
Operationalizing new functions
I’ve seen this “perfect solution” mindset over and over, in examples like the above and countless others. And there are some common patterns or archetypes that precent us from falling in love with the problem.
“Perfect Solution” Archetypes
I see a few archetypes (both scenarios and people involved) when I find the need to ground my clients in the “fall in love with the problem, not the solution” mindset. Those are:
Technology in search of a problem
IP Obsessed
Ego & Emotional Driven Decision Making
Analysis Paralysis (& Fear of Failure)
Technology in Search of a Problem
“That piece of technology is so incredible. Can you imagine if we used it to solve…?” If that refrain is familiar to you, you may be in situations where there is a technology in search of a problem. What do I mean by this? In simple terms: a technology that hasn’t identified what it is supposed to do, or does it in a very niche way, and tries to solve any number of problems to stay relevant.
This archetype almost always shows up when there is a major technological shift, but it can be more nuanced (hang on one second). I have two recent examples that I love: web3, and AI. O.M.G. There are so many good ones coming out of these two advances. There have been a number of examples where the technology was desperately being used to showcase a point, but not because it was the right tool for the job (e.g. metaverse real estate, NFT-ing all of the things, trinket AI products, and chatbots on any and every webpage).
Hot take: scrutinize the new technology, and don’t be afraid to ask “is there a proven tool or method that can already do what I need to do? Why am I not using that?”.
IP Obsessed
Another archetype I see is the “IP Obsessed” solution positioning. You usually see this when there is a framework, methodology, product or solution kit that has taken immense effort to produce, and thus, it needs to be used at every turn and opportunity, and at all costs.
This “shoehorn-ing” the solution into anything and everything can be very common in large enterprises, and in consulting firms. You usually see this in the form of “accelerators”, which more often than not, create more drag because of the inflexible nature they are built and packaged. Remember, you are likely getting the sloppy seconds of someone else’s program (and problems), and it is recycled and repackaged as “the best way to solve your (unique) problem”.
Hot take: you are getting something that solved someone else’s problem(s), and your mileage may vary. Be wary of solutions that rely heavily on black box IP, especially IP that appears to be and feels magical. Push back and be vocal about the job to be done, and the quality with which that job needs to be done.
Ego & Emotion
Perhaps the most challenging of the archetypes, the egotistical solution-er and emotional attachment to a solution are very real. These are often seen when someone creates a novel way to solve a problem, usually one that hasn’t been solved before. And because they are the mind and life force behind this idea, this solution, the conquerer of the challenge, they believe that no one else has anything to offer on the topic. Another version of this is “the expert”, who because they know so much, will bloviate until all opposing opinions are silenced.
Similarly, an emotional attachment to how we have solved the problem or the tooling involved can arise from time to time. It could be fondness and reminiscent (“remember the days when we had to scrape by to put this together”), to the fear of the unknown (“I don’t know anything about xyz…”), to seeking comfort in the familiar. All of these prevent us from attacking the problem head on and finding the optimal solution.
Hot take: have the self awareness to determine if you are falling trap to any of these; even the well intentioned can become one of these archetypes in certain situations. When dealing with the egomaniac, the expert, or the emotional, being willing to cede credit for the ideas that will solve the problem goes a long way.
Analysis Paralysis (& Fear of Failure)
The last archetype is anchored on the inability to decide on the course of action. After all of the ideation, the discussion, drafting and designing, we need to take action. But sometimes, we find ourselves continuing down the paths of “what if…?”.
Typically, the solution, and the process of discovering and designing it, have become the focal point, rather than the problem. There is a certain sense of joy in creation. And if we’re honest with ourselves, playing the mind games to handle new edge cases, or to find a different approach that optimizes one variable in favor of another can be fun. Sometimes, we don’t want the game to end.
In some cases, the fear of failure and of making the “wrong move” can become a variable that creates friction or pause.
Hot take: Embrace the fact that there will be a new challenge that replaces this problem once the solution is found and focused. The wrong move is always not making a move. Be flexible and adapt the solution if needed.
Problem Obsessed, Mission Driven
A few last thoughts…
Bring things back to first principles when and where you can, internally and externally. Be curious. Understand the need and the want. Think of the user. Be creative. Hold strong opinions, loosely. Fall in love with solving the problem, and doing the job to be done exceptionally.