Applying the Socratic Method to Build Versus Buy

Considered the father of Western philosophy, Socrates believed that the act of questioning itself was the only defensible form of teaching. It’s by asking and refining the right set of questions that we move closer to the truth. This is one of the key tenets of the Socratic Method of inquiry, which is structured around cooperative dialogue, probing, and rebuttal to help stimulate critical thinking and deconstruct underlying presumptions.

For IT and security leaders, there is perhaps no more daunting question than whether it makes more sense to build a certain technology capability in-house or simply buy it? Every business, regardless of their size, industry, or specialization, has struggled with this question.

For engineering led startups, the build versus buy question is particularly tricky since engineers pride themselves on being builders. “Why buy it if we can build it ourselves?” is a common initial reaction. Of course, just because you can build something doesn’t necessarily mean you should. You might be an exceptional carpenter but that doesn’t mean it makes sense to mill your own lumber.

From my own experience building and leading several tech start-ups, when I’m asked whether it makes more sense to build something rather than buy something, my response is often deeply unsatisfying: “It depends.”

It depends on a wide variety of factors and circumstances. But mostly it depends on asking the right questions to the right group of stakeholders. And above all, it requires a commitment to having an honest dialogue where everyone involved is open to challenging their assumptions and exploring the implications of their decisions.

Five Crucial Questions to Consider

The core of the Socratic Method is centered on persistent and focused questioning, with the goal of encouraging reflective inquiry to arrive at a more defensible and well-reasoned perspective. Consider these five questions as a starting point for driving a constructive dialogue with your stakeholders:

1. Is the capability core to our business? A significant aspect of the build versus buy decision is understanding whether having full control over a system and its architecture confers a long-term competitive advantage to your business. This is perhaps one of the most basic yet fundamental questions that needs to be addressed upfront. At my last start-up, our team prioritized the need for high availability and live backup capabilities for our flagship Security Orchestration, Automation and Response (SOAR) platform. While there were many viable solutions available in the market, we decided it was something we could build ourselves. Our team spent several months prototyping and building this capability, but in the end, we came to realize that we would have been better off just buying an existing solution. Our customers didn’t use it enough to merit the time we spent on it. Moreover, we had to dedicate scarce developer resources with every new release to keep this feature updated. It was only after the fact that we recognized that this functionality wasn’t core to what our product did or how it solved customer problems.

2. Have we considered all the financial implications and burdens of building something? All too often, organizations intent on building something will get estimates from engineers that focus narrowly on initial timelines and deliverables while undervaluing the true cost of the maintenance and support required over the long-term – especially in the absence of external support. As the former CIO of PwC noted, “70% of software costs occur after implementation.” From addressing vulnerabilities and transitive dependencies to building custom integrations, it’s not hard to see how these costs can skyrocket over a solution’s lifecycle. Beyond hard dollar costs, IT leaders must also evaluate the opportunity cost of diverting precious developer resources from other revenue-driving initiatives.

3. Do we fully understand the capabilities of our team? Accounting for the human element in the build versus buy equation is another area where engineering teams tend to underestimate the full scope and weight of this determination. This is especially relevant in today’s technology industry where software talent is scarce and retaining that talent is tougher than ever. So when you decide to build a new capability, you need to ask yourself how confident are you that the individuals who coded it will all still be there in a few years (hint: probably not that many). And if there is turnover, how difficult will it be to support and maintain the code base over its lifetime?

4. Are our requirements truly unique or unique because they are unclear? Many companies, especially those on the ‘bleeding-edge’, think their requirements are so unique that no existing solution would be able to meet their exacting specifications (or conversely that the capability itself is so ‘cutting-edge’ that it needs to be built whereas it might already be a solved problem that exists in the market). Or if one did exist, it would still require such a significant amount of customization that they might as well build it themselves. While this might sometimes be the case, it’s important to be able to recognize and articulate the difference. That’s one reason why when we have had these discussions internally in the past, I have asked my team to draft a detailed requirements document that aims to address both basic questions (i.e., why do we need it?) as well as more nuanced ones (i.e., what specific functionalities are necessary to meet our strategic objectives?).

5. Do we have a clear interface between our product and what we’re buying? Perhaps the biggest question mark that comes with buying a solution is the uncertainty that comes with it. Will the vendor still be in business in a few years and if not, how will their solution be supported? Is the vendor responsible for data storage and if so, how much effort and cost will be required to repatriate all of it? That’s why it’s crucial that when you do decide to buy a solution that a clear interface and a well-defined API exists between your product and the data. Without this assurance of interoperability, you not only run the risk of vendor lock-in but can also face potential disruptions in adapting to future changes and integrating alternative solutions.

Ultimately, the value of applying Socratic examination is not in knowing whether to build or to buy but in seeking to understand the many overlapping considerations, implications, and values that underpin such a decision. Of course, there are no easy answers. But by focusing your team on asking the right questions, you’ll be able to give a better answer than ‘it depends’.