CIOs and CTOs have generally moved past denial and into ‘acceptance’ that they need to make changes to their marketing stacks to compete and win in an omnichannel-24/7-personalized world. The question is now ‘How?’. Central to unpacking that critical decision is the ‘Build vs. Buy’ dilemma. What follows are but a few of the key issues to weigh before embarking down a path:
Do you have the resources to build?
Every time you write a line of code it’s like you’re creating a child. That line of code has to mature. It has to be supported. It has to be fed, nurtured, and maintained over time. A lot of organizations don’t have the resources to do those activities.
Do you have the expertise to build?
Expertise is also a challenge because some companies don’t have the luxury of hiring the best and brightest technologists out of Silicon Valley due to their location. Instead, they hire people who graduated from the local community college. These hires have a different technical acumen and a different level of expertise.
Do you have the buy-in to build?
The people who buy your product and the people who invest in your company should ultimately give you the signal whether to build vs. buy.
As a public company, if you think Wall Street is going to respond positively to you saying that in order to be successful in this particular business, whether it’s hospitality or airlines or retail we have to shift the majority of our capital expenditures towards investing in tech development, then you should probably build. If you truly believe that you can drive a better customer experience building it yourself, maintaining it yourself, evolving it yourself, and it’s not going to have any downstream customer experience implications then go for it.
However, if you think that they’re going to respond negatively to that you should try to partner with the best companies in the world that deliver the key components of what you’re trying to accomplish and evolve those components over time.
What will you do when things go wrong?
Operating something at scale is completely different than actually building it. One of the things to consider when deciding whether to build or buy is what are you going to do when things go wrong. Will you be capable of responding to the worst case scenarios around how that technology would perform and do you want to be responsible for that? Do you feel like you have the people, time, and money to operate that system at scale? If your answer is “we actually don’t know what we’re going to do when things go wrong or we’ll figure it out as we go,” you’re probably dipping your toe into a deeper pond than you realize.
What will you do when people leave the organization?
Employee turnover creates major problems for companies that go the build route. Consider a hospitality company — everything is custom developed and maintained in house, but people regularly leave the organization. As a result of the high amount of turnover there’s a lot of technical debt around people not being knowledgeable about how something was written or how it worked. What ends up happening is that as personnel changes over time, all the things that an organization had built become unrecognizable to the new people currently in the organization.
The point is–the things that you decide to build today may be someone else’s future pain. You might not imagine as a director of IT or CIO that you won’t always be there to help support the organization. The reality is that you need to build an infrastructure that’s going to evolve with the company long after you and your team have moved on. Whatever you do shouldn’t be something that’s going to hamstring the organization.
All the other things that go along with that internal development that you would expect from a smaller organization–things like lack of documentation, lack of testing, lack of certain things ever being tested at the scale that they should’ve been designed for. As the organization grew and the amount of traffic on their network grew; the data that they were collecting grew; some of these homegrown systems kind of just fell apart but there was no one else on staff to deal with them because they’re not with the organization anymore; people were not with the company.
How quickly do you need to create value?
People generally underestimate the amount of investment needed to be made by only evaluating the first use case. (Because everything always seems so simple through the lens of the first use case.) Once you deploy beyond that use case you open yourself up to a cascading, exponentially growing set of variables in your environment that are going to influence what you need to do next, and only the most disciplined individuals can actually avoid having to support that.
Time is relative; effort is relative; investment is relative, but you will probably underestimate how much time it’s going to take; how many people it’s going to take; how many experts it’s going to take your first go round.
Here’s where the concept of ‘speed to value’ comes into play. Speed to value is a measure of how quickly the product of a decision will have an impact on an organization in a positive way, such as driving more revenue. If you’re trying to make a build vs. buy decision as a public company you’re probably going to prefer something that’s easy to do, addresses the main use cases and problems you’re trying to solve and has the highest speed to value.
In the end, the correct answer to ‘Should I build or buy?’ may very well be ‘Yes!’ Many if not most modern technologists will blend components in creating the stack that’s suited for them today. The tricker bit that will test their powers of observation will likely be committing to the path that will give them max latitude for what may come in the future.
Suggestions