Not too long ago, one of the companies I advise launched a new software product. It was a two-fer product, one that would enhance the capabilities of their current customers while also opening a new line of business to attract new customers.
I love those.
Once the new product settled in a bit, the team's attention immediately turned to ways to get their customers using the new product more often, more efficiently, and more successfully. New tech always creates new possibilities, so there was a lot to talk about.
We started with the thorniest customer problems first. The highest priority problem--the one that was the most expensive and time-consuming for their customers--was the one for which the team had spent the most time designing an elegant and effective first new feature for their new product.
But something about their new feature bugged me.
When I finished for the day, I spent a few hours diving back into the design they had crafted. The feature was indeed efficient and elegant, even cool. I couldn't put my finger on what was bugging me until the next morning, when it hit me like a ton of bricks.
Their new feature solved a problem that could be solved with an email.
Most Technical Solutions Are Overkill
I work daily with a chief technology officer who wants to build new tech only when the building of new tech is absolutely necessary. On first take, this seems counterintuitive, but it's actually a luxury for me. Good CTOs are always tasked with building new tech, and they know that good new tech is expensive, time consuming, and almost always comes with some amount of technical debt.
If CTOs could predict the future, their job would be a breeze. Well, maybe not a breeze, but they wouldn't get caught in the technical overkill cycle.
The statement "most technical solutions are overkill" also seems like hyperbole. It is, a little bit. But having slung tech for the better part of three decades, I've learned that solving problems with tech almost always creates new problems.
Once we techies get going, it's hard to turn off the spark that leads us to expand and extend our solution to be all solutions to all problems. This is what the team I was advising was experiencing--a young, smart, and very recently successful team looking to capitalize on that success.
Nothing wrong with that. But back to their story, I realized that a simple automated email could solve 80 percent of the problem for less than a percent of the cost of their technical solution.
Good CTOs know that you start there.
Why Technical Solutions Are Like Whack-a-Mole
You know that carnival game where you hammer a mole and then several more moles immediately pop up? This is what a lot of technical solutions are like.
When they're first applied, they are elegant, efficient, and solve 100 percent of the problem. But almost immediately, there's degradation. Over time, outliers and business shifts make the solution increasingly less elegant and less efficient. This goes on as the solution solves less and less of the problem, until the tech eventually becomes a problem itself--a problem that requires, you guessed it, another technical solution.
So before I build any technical solution, I look for the hack.
The hack can be a technical hack, it can be an operational change, it can even be a temporary hire. Or it could be none of those. But before I sink time and money into permanent technology that is going to become part of my product's DNA and my customer's job, I make a list of all the other ways that same problem could be solved with limited-to-no new technology.
The list is usually pretty long, so I then spend some time narrowing it down.
Rule of Thumb: How Big Does Your Solution Have to Scale?
The thing about business problems is that there are a lot of them, they happen often, and they cost money. However, they are rarely systemic, frequent, or--and this is the big one --expensive.
What's more, if a business is experiencing frequent, systemic, expensive problems on a daily basis, there is not enough technology in the world to save that business.
When I'm told we need technology to solve a business problem, I always ask: "How often does it happen, and how much does it cost when it does happen." The answer is usually "I don't know." So I ask for numbers. Almost without fail, the problem doesn't happen as often as it seems, and it's rarely costly enough to justify a technical solution.
I only want new tech to solve a problem when the problem will scale quickly, broadly, and expensively enough to knock over all the solutions in the alternative non-technical solution list I made. You'd be surprised how rarely this happens.
This is why my CTO builds new tech only when it's absolutely necessary. It's why most technical solutions are overkill. And it's why you should think about all the reasons you shouldn't build that tech before you build it.
December 29, 2021 at 05:41PM
https://www.inc.com/joe-procopio/technology-overkill.html
The Dirty Little Secret Developers Won't Tell You: Most Tech Is Just a Big Waste - Inc.
https://news.google.com/search?q=little&hl=en-US&gl=US&ceid=US:en
No comments:
Post a Comment