Modularis

How to Make Better Technology Decisions for Your Software Company

SHARE THIS

Every business leader craves the latest technology. Some embrace risky bleeding-edge tech to get ahead of the competition, while others are more conservative and believe proven technologies are the right choice to drive their business forward.

Certainly, experience shows both approaches work, and each has its pros and cons. In fact, the particular technology chosen to build a product has less of an impact on its success or failure, than the architecture and patterns embraced by the engineering team, or the experience and maturity of the technical leaders charged with execution.

When the pressure is on, and you need to build something new to drive net new revenue, preserve existing revenue, or hop on an opportunity to get ahead of the competition, the last thing you care about is which technologies your team uses to get it done.

You just need something built quickly that you can sell, so it’s very easy to tell your team to do it however they want.

It’s also very tempting to tell your team to build something “quick and dirty,” even though they warn you they’ll have to rebuild it right later.  That’s a problem for next quarter or next year.

But the truth is that successful software projects never really end and you’ll be living with your technology decisions for many years to come. This spans everything from operating systems, cloud providers, programming languages, development frameworks and tools, 3rd party components, and probably most importantly, architecture choices and patterns.

To de-risk and accelerate your software development efforts in both the short and long term, you owe it to yourself to pay attention to these choices if you’re building anything beyond a POC or Prototype.

Think about it. You want to launch a new MVP (Minimum Viable Product) in 90 days that will generate net new recurring revenue. What happens if you’re successful? If you rush something to market quick-and-dirty, you’ll be paying the price for those shortcuts sooner than you think in terms of poorer quality, lower development velocity, or even bad bets on dead-end or proprietary “black box” technology.

Remember Silverlight? Or when your friends at Microsoft convinced you that the Desktop was dead and Windows 8 was the future?

No need to only pick on Microsoft. Open-source frameworks are great too — until you realize that once you choose one, say Angular, you’re now taking on the responsibility of maintaining and upgrading not only your own product but the particular version of Angular (or any open-source framework) you’ve chosen. Are you ready to upgrade to Angular X.Y every year? And in many cases, there are so many breaking changes that you essentially have to rewrite your solution all over again. Did you or your tech lead take into consideration that that’s what you’re in for, year after year?

The point is that the technology choices you make have a lasting, but often unforeseen, impact on your business over the long haul.  As a business owner or investor, you naturally and carefully weigh the pros and cons of all major decisions you make, whether that’s which people to hire, which law firm to use, or which accounting or CRM system best fits your needs. You’ll be living with these decisions for a long time and they naturally need to be carefully considered.

The same can be said for the technical decisions you typically leave to your R&D team.

My general recommendation is that it’s never a good idea to let your junior developer fresh off the campus to do whatever he wants.  It’s not that he doesn’t know what he’s doing, or doesn’t have your best interest in mind. It’s that he doesn’t look at these choices through the lens of an investor like you do. You’re principally trying to balance Risk and Return, while your young developers are driven by what’s new, what’s trending, or what’s commonly applied.

Years ago during the dot-com boom, I was the chief software architect for a well-funded B2B startup.  My team and I had just built and successfully rolled out a stable, scalable, and full-featured web-based solution based on Microsoft technologies. It worked, was delivered on time, was generating revenue, and the customers, investors, and engineers were happy. Our hard work had paid off!

And then our newly hired VP of Engineering suggested we rewrite it in JAVA.

Huh?!!

We’d just built and delivered a solid, flexible and scalable solution that was built to last. When I asked Why, his answer, delivered with absolute seriousness and conviction, was “Because JAVA’s hot right now.

And that’s when I realized it was time to move on.

It’s natural for tech folks to get religious about technologies—typically the ones they know and love. But from an investor’s perspective, this is highly counter-productive and only increases risk and limits your returns.

It doesn’t matter whether a technology is “hot” right now or not.  What matters is whether that technology will be supported for the next 10 years. What matters is whether you’ll get that support from the vendor, or if your own team will be forced to assume the burden. What matters is having access to a reliable talent pool with a mastery of that technology 10 years down the line. What matters is getting a return on your investment in time and money when embracing one technology over another.

At the end of the day, you need to choose technologies that will enable you to deliver monetizable innovation to your customers with the best possible combination of low risk and high development velocity. This is what you need to impress upon your technology leaders. It’s something they can and will understand, but it’s not natural for them to think like this, even though it is for you.

This is where the following technology decision scorecard can help.  Ask your tech leaders to answer these 5 simple questions for each technology they’re considering.  Only embrace technologies for which they can answer a definitive Yes for at least 3 out of 5 questions.  Make sure they can adequately explain to you their reasoning in language that you can understand.

If you follow this approach and take the time to help your engineering team look at things the way you do, they’ll be able to sharpen their focus and deliver even more value to you and your customers.  They want to do a great job for you—help them see things through your lens.

Get our Technology Decision Worksheet
(Free Download – No Email Required!)



Download Now

Head over to LinkedIn and follow us for more Software Product Development Insights

Follow On LinkedIn