Controversial opinion: The biggest thing standing in the way of most CTOs’ success is the impulse to build their own infrastructure.
In the past, engineering teams had little choice but to build tools—because there weren’t any better options available. Before the days of cloud computing, you needed a dedicated server room. Or, say you wanted to launch a machine learning model: You’d need to buy or build an ETL tool, connect your databases, write Hadoop jobs, and have a dedicated ML engineer oversee the entire process.
Today, all that can be done as a service. In fact, thanks to the accelerated pace of technological advancement, these days you can get an out-of-the-box solution for pretty much anything.
So why are so many teams still trying to do it themselves?
Buy, don’t DIY
A quick note: I am generalizing infrastructure to include anything that is peripheral to the core business competency, including hardware, software, and services.
The impulse to build is deeply ingrained in tech leaders, from the days that engineers extracted an actual moth out of Harvard’s Mark II calculator (how’s that for debugging?). And it’s not a bad thing. Many of us—especially those from startup backgrounds—have gotten to where we are today because of our ability to build innovative solutions with limited resources.
But CTOs have to be cognizant of the stage of their company. In a startup, a CTO is frequently a product head, a VP of engineering, and CSO rolled into one. As companies grow, so does a CTO’s role. At more mature companies, CTOs need to think more about current trends, internal technology efficiency, and innovation. At a certain scale, it may be prudent to take a look at expensive pieces of infrastructure and look to optimize, but here’s why I think you should hold off on (or at least, think twice before) doing it yourself:
1. Someone else (probably) does it better
When your CEO turns to you and asks, Can we build that? there’s a huge temptation to answer yes—and you probably could. But as technology leaders, we have to face reality: Just because we could build something, doesn’t mean we should.
Chances are, there’s already a tool for whatever you need to accomplish. And I’d wager that it works better than any solution you would devise in-house. Not because you’re not capable, but because it’s not going to be your priority. Imagine you wanted to build an internal CRM on par with the options available on the market today. You’d not only need developers, but also a product team to plan out the tool and UX designers to ensure your internal “customers” would actually want to use it—and you’d still probably not get anywhere near the capabilities of Salesforce. The truth is, your core competency is never going to be infrastructure. Your core competency is always going to be the product you’re building and the domain you specialize in.
2. It will slow you down
In order to succeed in today’s tech landscape, you need to be able to “move fast and break things,” as Mark Zuckerberg said in his famous Business Insider interview. “Unless you are breaking stuff, you are not moving fast enough.”
To move fast, we need to focus on building products that help our customers, not the products that support our processes. Other companies are already perfecting those. Every minute you spend building infrastructure is a minute you could be spending refining your own product. Letting infrastructure take resources away from your product takes a significant toll on your business—try to minimize this whenever possible.
3. The infrastructure ends up running you
When you start building your own infrastructure, it becomes hard to draw a line on when to stop. Infrastructure teams start evolving, and they will need a raison d’être. This soon starts becoming the focus for them and in no time, a significant proportion of your engineering team is devoted to infrastructure, instead of building your product to solve customer problems. Roadmap execution slows down and product development starts crawling.
Of course, there are exceptions to all these points. You might have very niche criteria or need to meet very specific security or compliance requirements. But unless you’re working around these kinds of constraints, I’d say it’s better to get an out-of-the-box solution.
When faced with the question of whether to build or buy, ask yourself:
- Will our internal users actually want to use an internal solution? Or would they be better served by an existing solution?
- Is building an internal solution the best use of our time and effort?
- If we build it internally, can we measure the ROI, and is it worth it?
Ultimately, the role of the CTO is to be forward-thinking and to concentrate on trends within your industry and across related industries. As tech leaders, we need to stay focused on being leaders in our own domains and helping our teams work better by leveraging some of the revolutionary changes in the technology landscape—not on building the best infrastructure to support our processes.
About the Author: Neelesh is the CTO/cofounder at Syncari and a technologist with more than 20 years of experience in building large scale SaaS applications. Previously, he worked at Marketo, where he lead many major technology transformation efforts. He was also at Oracle, Successfactors before that. He loves being on the edge of product and technology.
