Addressing the challenges of build vs. buy

How would you frame your decision-making around your organization’s core competencies?

From startups to large enterprises, the question of ‘Should we build or should we buy?’ is a perennial issue for engineering leaders.

Challenges in this debate can range from cost and business value to team morale, ego, and bureaucracy. With so many factors, how have engineering leaders been navigating the decision, and what lessons have they learned for the next time the question rears its head?

As part of the ‘Weighing up the pros and cons of build vs. buy’ series, LeadDev brought together a second group of engineering leaders from across the globe to share their experiences of build vs. buy: their decisions, their regrets, and the considerations that need to be made.

To open the session, Dawn Parzych, Manager of Developer Marketing at LaunchDarkly, gave a presentation on the ten questions engineering leaders should ask before deciding to build or buy. These questions fell under the umbrellas of cost, business decisions, and growth and change; they included:

• What are the known costs and unknown costs?
• What is the cost to purchase?
• What is the cost of having two or more systems?
• Is building this part of your core business value?
• What are the motivations behind building?
• Who are the users?
• What happens if you change course?
• How easy is it to switch to a different solution?
• Who will maintain and enhance the product?
• What am I missing?

After Dawn’s presentation, the group embarked on a discussion around what they had built in the past, and some interesting points on competencies and commodities were made.

What have you built in the past?

The group was asked to note on a virtual whiteboard what they had built in the past, with the most common answer being logging systems. Attendees were invited to comment on why they thought this was: what could create a situation where more folks are choosing to build these systems?

One attendee explained how logging software is a commodity and so unless an organization wanted to innovate in that area, the most sensible choice is to buy – especially with the multiple options available on the market. Another attendee responded to this with how they had written a blog post on what people were reinventing, and the first example they used was logging systems. Their theory was that this is one thing that people think ‘This is really easy! I could build a cheap one.’ And then they realize that the system has to scale and the efforts of building and maintenance become even more complex.

It was then observed that no one had marked on the whiteboard that they had built a CRM. One attendee said that they remembered how in the late 1990s, CRMs weren’t popular, so teams were constantly figuring out ways to build something like a relational database to store their customer context. But now, there are so many options available on the market, teams wouldn’t think to build. The attendee mentioned how there was this interesting shift over time as certain tools become mainstream. Someone then mentioned Salesforce, and how they had come out so early on a SaaS platform and quickly developed a lot of followers due to its lower cost and simplicity. The attendee wondered about the impact here. A response was then made by a person who had previously worked at Salesforce, and they discussed how the company is in a different part of the market, and that they have new competitors in that space which caters to the lower-end.

What’s most important when considering buy vs. build?

One of the first considerations attendees brought up was internal resourcing. Hiring is currently a huge challenge globally in the tech industry, and it was a major consideration for more than one attendee. How much competency is there in the team in order to support what you want to build? Is that competency spread out? There was also the consideration of tooling: one attendee mentioned how it was difficult to find developers with experience in Liferay, but that React developers are much easier to find. On the subject of individual developers, one attendee said how they had seen a situation where the one engineer who built the software and knew how it worked then left the company. At this point, no one else in the team knew how the custom system worked. This resonated with an attendee who had had this exact experience; they had someone build their own mini JavaScript framework for a web console, that person left, and then they wrote a blog post on all the mistakes they had made in this JavaScript framework they had built. Suffice to say, no one else on the team knew how to use it. The lesson here for attendees was how important team buy-in and the spread of knowledge is across the team when making the decision to build.

Expanding on companies’ missions, the question of ‘Is it your core competency?’ was explored. Attendees looked at how it does not only mean having the competency to support and maintain a build, but also the competency of the business value: is the build going to distract from doing what needs to be done to serve customers? To complete this part of the discussion, one attendee summarized it by saying ‘if it’s not our core competency, we should be buying it’. They also referred back to Dawn’s presentation where she used the analogy of either buying or building a house: when buying, they might not be able to get every single thing they want, but buying achieves goals faster and probably cheaper in the long run if it’s not part of what their company primarily offers to customers.

Another attendee chimed in here to say that there was also a point around buying where you think ‘Well, it doesn’t fit exactly – maybe it does 99% of what I want if I buy off-the-shelf but it doesn’t do this exact 1%. Therefore, I’m going to rebuild it just for us.’ The attendee said they had failed at this many times, and how sometimes it’s about stepping back and not only assessing whether it’s your core competency, but equally, what are you willing to forgo if you buy it off the shelf? Is it okay that it doesn’t fit one or two specific requirements?

What is something you bought and ended up building later?

One attendee molded this question to ‘What is something you bought and ended up buying from another company later?’ They discussed changing requirements, and whether or not you have the vision for where the product is going. Specifically, they used their own example of choosing Liferay based on what they knew years ago – but that what they wanted to deliver for customers had completely changed now. When looking for another third party to go with, they asked questions such as, ‘Well, is the company going to disappear in a year’s time? If so, what are you going to be left with?’ For this attendee, that was always a challenge. When looking at a third party, they gave the advice of always finding an excuse to contact support and seeing how responsive they are. How quickly do they turn around fixes? This attendee shared that their org was now working with MongoDB and had a really positive experience with them, building a trusting and close relationship. They advised the group that folks need to build this relationship with a third party if it’s something they are going to invest a lot in.

The conversation then branched out to how, sometimes, it has happened where an org has changed the code of a bought tool so much that it really becomes their own, and also becomes a product that they could no longer purchase anymore through updates. One attendee gave a particular example here of implementing a BI tool within their SaaS product, and how they had to customize it extensively. They knew that going in, but they are undecided on whether that was the better choice at the end of the day. For them, it was a very long path to completing the vision. 

At this point of the roundtable, a couple of attendees flagged Wardley Mapping as a tool. One attendee explained that it is a framework that puts together when you’re thinking about what is core to your business, and what is the opportunity cost. They said that with Wardley Mapping, there is a way of thinking about the adjacent industry of your business and about what things you are still experimenting with.

The attendee continued to say that one benefit of Wardley Mapping is that you can think strategically about if you want to get in the commodity business for a particular thing. The framework enables you to understand/have APIs etc. in place so you can have early indicators of movement through the industry. For example, if you’re providing a commodity tool and you have APIs so that you can see usages of it, then that gives you an early indication of what those things are under the genesis and product delivery stage. This puts your business in a good position to think strategically. The conversation needed is about communicating with business counterparts and Wardley Mapping helps them think about it because costs etc. come into play, but that might be more engineering-focused.

What have you regretted building in the past?

This was a real story-sharing point of the roundtable discussion. One attendee related their experience back to the competency theme of the conversation, sharing how at the turn of the millennium, when applications were really expensive, they built their own application server with C++ and Corba. ‘Don’t do that.’ They explained how they should have bought instead rather than spending 25%+ of engineering effort on building a piece of undifferentiated infrastructure that wasn’t part of their business.

Another attendee told of how they built out a machine learning python when they should have purchased something like Google Cloud instead. They were an AWS shop for the most part and so didn’t want to go down the Google Cloud route initially. They wanted to roll out their own. But this was a negative experience for the attendee and the entire project ended up getting scrapped.

Yet another attendee told of how they founded a company and decided that the first product they would develop would be an email marketing system because they thought they could create the most awesome product and beat the minimal competition. This was in 2006. They regretted their decision years later due to maintenance and lack of knowledge. They have now migrated everything to MailChimp, which also was not an easy process.

To round out this part of the conversation, one attendee shared that the interesting part for them was the extra tooling you need within a business. For example, their company introduced OKRs to set goals, and a lot of developer time was spent building a complex OKR tracking tool that they thought they could open source because it was ‘really shiny and awesome’. This was until they realized that something like Excel gave them 99% of the functionality they needed; it just looked less shiny.

What are you currently considering buying or building?

One attendee shared that although they currently use a third-party vendor for all their logging, they have recently hired a systems team that has the ability to build an entire logging system. The benefits of this being that they would then have more control of their users’ data and it would be a lot cheaper – knowing how expensive the vendor can get the more logs you funnel into the system. ‘We didn’t have a team at the time so we bought; now we have a team so we can build.’

The challenge of cross-functional teams and decision-making then arose, with an attendee sharing that the idea of buying an analytics solution had recently come from their design team. They told of how there are all kinds of debates about full story vs. better integration with an A/B testing tool vs. 20,000 analytics tools. But that someone also always wants something bespoke. Questions come up of ‘Which one do you buy? Which one do you implement first? How much do you need to know before you try a second tool that fills some gaps of what the first didn’t do? How in conflict are they? The attendee focused on how there are a lot of solutions and needs that aren’t necessarily driven by technology. For them, right now, the biggest question isn’t build or buy – it’s what are the outcomes that they are trying to drive? How can they help teams who aren’t deep in software development understand how their decisions impact Engineering?

Looking at cross-functionality from a different angle, another attendee recommended exploring the tools and frameworks that product managers use for working with stakeholders. That function is developing in the industry and it’s worthwhile to learn from.

Closing thoughts

Finally, attendees were asked to make a commitment to take one learning into action after this discussion, sharing their answers in the Zoom chat function. The overwhelming response was Wardley Mapping, demonstrating the importance of strategic structure and clarity when it comes to making decisions at this scale.

A theme that continued throughout this discussion was commodity vs. core competency. Though, of course, many considerations need to be taken into account when making a build vs. buy decision, it was apparent that a clear cut and basic question engineering leaders can ask themselves, in the beginning, is: does this align with the strengths of my team and the values of my business? If the answer is yes, then a build could be considered, if the answer is no, leaving the work to experts within third-party vendors is the more viable option.

As always, the answer to build vs. buy is heavily individual to each company, organization, and team considering it. But through sharing experiences and knowledge, like in this roundtable discussion, engineering leaders are able to gather the information and considerations they need to make the right decision for them in their current climate.