Insights
Article

Stop solving solved problems

Nate Berent-Spillson
/
VP, Engineering
<Read time>
/
January 22, 2024

There are all kinds of reasons why enterprises stumble instead of innovate. Limited budgets, fear of failure, resistance to change, unclear goals — these are obvious culprits. But a roadblock that’s harder to spot is the habit of re-solving solved problems.  

On the surface, it sounds absurd. Of course your team isn’t spending its time, energy, and money, solving problems that have already been solved! But organizational muscle memory can lead us astray here. Once we’ve labeled something a “problem” and spent time and resources trying to fix it, we dig in. When an out-of-the-box solution becomes available, we’ll likely insist that no, no, this problem, our problem is very unique and special and therefore requires a bespoke and special solution.  

It doesn’t.

Getting to what really matters

A key component of becoming a frictionless enterprise is keeping your focus on the business problem. Start with the business problem and then ask yourself, how much of this do I NOT need to build? Put the business problem first, then use technology to support it. That’s the platform mindset. That’s using your technology strategically to support the business, instead of the other way around.  

Don’t mistake activity for progress

Returning to the issue of solved problems and how they distract us from innovation – part of what’s alluring is that it feels good to be busy. But don’t mistake activity for progress. Be honest – do you give your people credit for activity? Sending an email and then sitting back and waiting days for a response, saying “ball is in their court” is bad. Churning on a solved problem is a classic activity that hampers real progress.

Examples of solved problems

How do you know if you’re falling into this trap? Here are some typical hallmarks of solved problems:

  • Not strategic to the value proposition of your organization. In other words, you’ll never brag about the solution in a press release.
  • A complex domain problem that is easy to get wrong and often overly controlled in its own silo. Think Identity and Access Management (IAM). You don’t need your team to build a custom solution; you need a provider that specializes in IAM security.
  • A superficially simple problem. We’ve all felt the intense frustration of digging into something that appears quick and easy, only to realize it is anything but.  
  • Difficult edge conditions. You want to understand what issues users may face, but spending too much time on uncommon or extreme conditions is an easy trap to fall into.
  • A broad application that works across a variety of industries and verticals. If it’s that broad, chances are someone else has already solved it.

Tapping into solved-problem-as-a-service is vital. It enables you to move faster and keep your focus on your special sauce—the strategic differentiator that makes you money. Remember, solved problems don’t make you money. Buy, don’t build, and then crucially, insulate yourself from vendor lock in.

Leaders, it’s your job to keep your team focused on the business-level goals because solving solved problems typically trickles down to execution. Teams are told “make it happen” and then left to figure out how. It’s easy for the C-suite to stay focused on strategy because they’re not in the trenches. Meanwhile, their foot soldiers get bogged down in details and progress plods forward at a glacial pace.  

Pull the value forward

Picture this. Your C-suite discovered untapped potential in Europe. None of your competitors are operating there, and research shows there’s a demand for your products. It’s a huge opportunity.

Upon hearing this, your customer service team realizes that expanding into Europe would require providing support in potentially two dozen languages. They begin weighing their options – pour time and resources into building a custom solution, or spend months vetting and choosing a provider that will probably require customization anyway? Beyond customer service in multiple languages, there are a dozen other similar decisions the business has to make to capture this new market.  

Multi-lingual customer support is a solved problem. That said, you may have to do some customization to make it work for you. But the worst of all possible worlds is to buy the solved-problem-as-a-service and then do so much customization that it becomes another unforgiving system. You’ve lost the convenience and savings, and you're no better off than before.  

The second part of "don’t let vendors get their hooks into you” is to build in seams – axes where you can make changes — into whatever you adopt.

When you’re faced with a scenario like the above, ask, “What is the critical path to capturing value?” You don’t have to solve every single problem up front. In reality, there are only a small number of problems you have to solve to start capturing value. The mistake is in viewing all dependencies as equally important, or overvaluing the importance of something.

Pull the value forward. Maybe there’s one country, say Germany, that is most promising. Invest in German language support to begin with. If you wait, or spend precious time churning on every single decision with equal deliberateness, a competitor may enter the European market while you’re spinning your wheels.  

Solved problems don’t make you money

Remember, every bit of capital you’re spending to solve solved problems can’t be invested in innovation. In addition to asking, “What part of this do I not need to go build?”, remember to also ask, “Is that a problem I need to go solve today?”  

There are strategic differentiators that are your organization’s secret sauce, and there are problems that are last decade problems. Success depends in part on your ability to focus on the former. The sooner you’re able to spot solved problems and eliminate the temptation to re-solve them, the closer you’ll get to the sustained innovation that frictionless enterprises enjoy.  

This is only part of the path to perpetual momentum. Explore the rest by downloading our Frictionless Enterprise book.

No items found.
0:00
0:00
Show insight details
Episode hosts and guests
No items found.
Written by 
Nate Berent-Spillson
VP, Engineering

Nate has been enamored with technology and engineering his entire life. His first exposure to programming was BASIC on a Commodore 64 in 1985. In middle school he took a career exploration test that predicted Computer Programming, which turned out to be incredibly accurate.<br></p><p id="">While studying Chemical Engineering at the University of Tennessee, computing always found a way into his projects. His senior project, Batch Research and Internet Control Station (BRICS), combined his work in process control &amp; automation, computer science, and the internet, creating the back-end components and a web page to remotely monitor and control physical equipment in the lab from a remote web browser. Nate presented the work at the annual American Institute of Chemical Engineers meeting in 1997, placing third.<br></p><p id="">After an early career in process automation and controls, Nate switched completely to software engineering and development in 2002. Throughout his career, he has been an early adopter of tech advancements, bringing new capabilities to his teams. <br></p><p id="">Nate joined Nexient (now Launch by NTT DATA) in 2014, leading delivery teams and growing the Microsoft practice. His thought leadership has been featured in blog articles, presentations at CodeMash, and Agile &amp; Beyond. His article “Going Lights Out with DevOps” was picked up as the cover of SD Times. The initial sketches for the “Frictionless Pyramid” took shape in 2022 and inspired Nate to write this book.

Episode transcript
Sources
No items found.
Let’s talk.

Transform insights into action and ideas into outcomes.