The Build vs. Buy Debate

The decision to build versus buy is as old as time, and it’s not going away any time soon, especially as technology takes off and the need to keep up with, if not stay ahead of, the curve grows with every day in fast-paced sectors like AI, ML and NLP. I’ve sat among the C-Suite executives numerous times as we try to make the challenging decision of whether to build or buy a new technology that can transform our business, and it’s not always an easy call. But to me, it comes down to four questions.

1. What is your core DNA?

2. Are you focused on success or pride of ownership?

3. Are you willing to take on the risk along with the reward?

4. Is the ROI worthwhile?

Let’s look further into each factor.

1. Your core DNA

I’ve had some great mentors in my career, and one comment stuck with me all of these years. It was something along the lines of, as you develop as a senior leader, one thing you want to establish is an identity for your department. It should be something short and succinct, based on your team’s core competencies. And I’ve learned that it can really only be one thing. It’s just too expensive to be everything to everyone.

If your team excels at customer service, be the company with the best customer service. If your DNA is founded in UX, have the best customer experience. Maybe your core competency is excellence in engineering, or customer centricity – whatever it is, focus on developing that on don’t spend time and money trying to build something outside of your core DNA.

My personal background happens to be in data science, and that fit well with the makeup of our team, so that’s what I’ve focused on at The Globe and Mail and Sophi. Being clear about our identity makes it easy for me and my team to understand what we want to buy vs. what we want to build from scratch. When something is outside of our DNA, or core competencies, we don’t waste the time and resources trying to build it. For example, we have never considered building our own CMS because that just isn’t what we do, and there are other companies out there where that is their DNA. If we can get a top of the line CMS for a nominal licensing fee, that leaves us with the time to focus on solving other challenges that fall within our core competencies.

It’s easy to identify a challenge that seems interesting and exciting to solve with your own build, but when it doesn’t fit within your core DNA, it will ultimately be hard to get buy-in across the board, and I’ve unfortunately seen leaders sink time and resources into a money pit that didn’t come to fruition. To oversimplify matters, you can even draw a Venn diagram of your core competencies, then the capacity you need to solve the problem, and see if there’s enough overlap for this build to fit within your DNA.

2. Pride of ownership vs. success

This is a particularly tough one. There are so many shiny new toys out there these days, and it’s tempting to want to use one as a way to build your portfolio or your corporate culture. But at the end of the day, it’s crucial to think hard about whether you’re building something for the pride of ownership, or because you believe you will be successful. While these two goals can overlap, they cannot be mutually exclusive.

Don’t fall into the trap of Not-Invented-Here Syndrome. You don’t have to create everything from scratch to be successful, in fact you shouldn’t create everything from scratch to be successful. Coming to that realization takes honesty and self-awareness, and it’s not always easy to buy something you’d enjoy taking a stab at building, but it needs to come down to what will lead to success.

Success means getting things off the ground quickly and ensuring you make more money than you spend. Given that time and money are synonymous, the longer it takes you to build a solution, the harder it becomes to show a strong ROI. When success is the ultimate goal driving decision making, it is easy to do the math and realize that leveraging someone else’s investment and risks will, many times, help you drive your desired business outcome. Ultimately you want to be successful more than you want to be proud.

Take, for example, Sophi. The Globe and Mail had a robust data science DNA and I felt strongly that we could succeed at building Sophi. We knew that no one else had cracked the problem of automated digital content curation, fully dynamic paywalls, and what to write more and less of based on the value different content brought the business – and we knew that with our team, we actually could. So we decided to build Sophi. It took the team five years to get Sophi to a point where The Globe and Mail was choosing to use Sophi over having the editorial team spend their time on. Those five years took a sizeable investment in terms of money and time from true data science and engineering experts who knew what they were doing and invented Sophi. We also had the backing of our investors and the confidence earned from our CEO and ownership to try internally and then commercialize it – millions of dollars later.

3. Willing to inherit all the risk

While the potential reward of building a new, shiny thing that meets all of your specific business needs can be enticing, the other side of the coin is that you have to be willing to accept all of the risk that comes along with the unknown too. Building a large, powerful technical solution is a hard road.

It has been very common for publishers to build their own CMS. And that CMS typically had to be rebuilt every five years to keep up with new challenges and demands. Often these proprietary CMSs didn’t even solve all of the problems they set out to. Six years ago I was faced with the decision of building our own CMS or buying one. I knew this wasn’t in our DNA and I wasn’t willing to take on all the risk of putting years and money into building something I wasn’t confident would even solve all our problems, and so we decided to buy instead of build.

After using a number of established CMSs, we decided to try a new tool – Arc Publishing. As a beta customer for them, we were able to help guide their tool to meet our needs – making it a more effective tool for us, and helping them improve their CMS offering, all for much less money than it would have cost to build it ourselves, and without taking on the risk The Washington Post did when they built Arc.

4. ROI

ROI is clearly a key factor in this type of decision making; if you don’t have the buy-in of the CFO, your project just won’t get off the ground. And it’s very expensive to hire data engineers, senior developers, AI engineers, ML engineers, and data scientists – these are some of the hottest jobs on market and people who excel in those areas are getting paid more and more. To build a successful tech solution, you have to pay what you need to recruit and also keep your team, then you need them to gel and work well together too. All of that takes a lot of time and money.

There’s a difference between running an A/B test or creating a widget, and the math and deep learning that goes into solving something like how automated decisions are made for experience automation. And it’s a whole other level when this becomes part of your daily operations. In my experience, your CFO will ask the really hard questions. There’s an art to tuning these costs to make it a winning business case where you can demonstrate ROI. You may have even run successful experiments, but when it becomes your project 24/7/365, it’s completely different.

I think about our business financial tools, as a good example of this. We compete on our financial data – it’s a #1 driver of subscriptions for us (and we have three key drivers). Readers value our financial tools, and our stock alert tools, as one example, had been a huge success for The Globe and Mail for two decades. But a few years ago, the technology grew to be 15 yrs old and was breaking. We had to re-platform, and given the factors mentioned above and the projected ROI, we decided to buy from Barchart. I say this so you know we’ve been through this debate – we did the hard thinking and calculations, and we had to acknowledge to ourselves that business financial tool development just isn’t part of our DNA anymore. As we’ve focused elsewhere, others have gotten better at it than us, and we didn’t want to incur the costs of continually upgrading charts that wouldn’t make us more money than buying from someone else. This is very different route than we took before – but ROI and success are more important to us than pride.

Technology is ever changing

One last thing I want to mention is that building net new technology can take years, and lots of things can change over a period of years. What do you do if you’ve started down the road to building and you realize it isn’t going as planned? If you’ve begun investing in a great team, it wasn’t for nothing. I believe that having a strong data science team is never a bad thing. If you find an out-of-the-box solution that solves the problem you were working toward solving, and it can save you years and millions of dollars, it may be worth revisiting your decision to build and looking at what will truly make you successful. There are so many problems a strong data science team can look at today. Take advantage of this opportunity to look at the areas where you can make an impact quickly, such as inbound and outbound marketing, understanding your audience, what leads to propensity to buy, and so on.

If I were ever to move to a different company, I 100% wouldn’t build Sophi again. Those problems have already been solved. I’d license Sophi and use my core DNA to solve new and equally interesting problems. As someone deeply rooted in data science, I will always say that having a data science team is important, but it’s even more important to focus on solving the right problems.