Why is it so hard to decide to buy?

A tweet that generated a lot of feelings

Optimism and Fun

The default to building our own software is well-established at most tech companies. Some of the patterns that lead to this include:

  1. We want to believe ourselves to be special, and our situation to be unique. We over-focus on the edge cases that are not perfectly solved by off-the-shelf tools, and ignore the complexity of providing the main features in addition to our desired edge cases. We believe ourselves to be better engineers and capable of solving the problem in a more-perfect way.
  2. Building is fun, and the work of integrating an existing product often sounds tedious. As an industry we’re still struggling to move from telling engineers “your job is building brand new things from scratch”, and our whole style of teaching computer science is first-principles based, which encourages the default to build ourselves. The industry has not thought much about what makes someone good at integrations, or what the opportunities are for engineers who are doing integration work to learn new things and feel challenged and stimulated.
  3. We underestimate the work of building, and the total cost of ownership of having our own special product. It’s easy to see the bill for your SaaS software every month, and hard to appreciate that the engineering cost to build an internal version is still probably higher because you haven’t factored in the opportunity cost of having engineers build that system instead of contributing to more core business opportunities. Perhaps you think that you can lessen this bill by making the project open source, and having community support for the effort. In reality, even if you somehow manage to build a community around it (an extremely challenging thing to do), now you have to balance moving the project forward in the way your company needs and moving the project forward in the way the community might need. Building OSS might still be the right call, but it’s not a free option.
  4. Companies reward people who create new things. It is hard to identify and reward problems that are avoided. When it comes time to evaluate people, we look at systems built from scratch and believe their authors show more technical talent than those who completed similarly-challenging integration projects with less raw code. Most companies promote those who create new systems even of questionable value much faster than they promote those who might be making wiser choices by not building from scratch, which creates a pressure to build in order to grow your career.

Making the decision to build or buy

When you come across this situation, here are some questions to consider:

When integrations bite back

I have attempted to simplify the problem and solution, but there are a number of non-trivial elements to buying that are worth keeping in mind.

Problem 1: Buying a bigger solution than you need, and then feeling obligated to use all of it.

Jira might be the best example of this kind of abuse. Jira is a perfectly fine system for ticket tracking that can be made to do horrible, horrible things through customization. Just because the product can do a thing doesn’t mean you should use that feature! Over-customizing an off-the-shelf product can end up being the worst of both worlds: you are writing a lot of code and maintaining a lot of bespoke logic for a system you don’t really “own,” which tends to bring a lot of technical debt over time as the product evolves in ways that are incompatible with your customizations. Just because you are paying for a product doesn’t mean you have to use every bell and whistle!

Problem 2: Evaluating every option out there for every decision.

You do not have to do a bake off for every product you choose to adopt, really. It is ok, even good, to build into an ecosystem that works well together, that your team is comfortable with, where you have an existing relationship with the vendor. These are not bad reasons to choose a product (just try to avoid choosing a product because of your CEO’s golf buddies). There is a cost to delay of making a decision, so be realistic about what the really important factors are for choosing the product and try to otherwise move fast. When you agonize over every one of these decisions, you make the team less inclined to adopt something that they’re comfortable with and works and more inclined to just build their own thing to avoid the bureaucracy.

Problem 3: Over-vetting every product.

Similarly, if the process of approving a new vendor/SaaS/OSS product is slow and painful, there is every incentive for engineers to just build so they don’t have to wait for approvals to get started. Is this really want you want to happen? If not, figure out how to get the approval to use a product done faster, preferably in parallel to the team getting their hands on it to see how well it suits their needs.

Problem 4: Underestimating the work of integration.

Yes, integration is often the right choice in a cost-benefit analysis, but that doesn’t make it free. Think of the work involved in moving to the public cloud as an example of a really complicated vendor integration exercise. When you decide to adopt a vendor product that requires anything more than “enable this for everyone with a google account in my organization” expect that it will take time. And while you don’t want to over-vet everything, no product is perfect and the more sales people there are around the product the more likely you are to find some unexpected gaps in the offering that you may have to work around, so make sure you understand the core important features.

Problem 5: Neglecting to speak to the value of what the engineers are providing when they aren’t building from scratch.

You are still going to need software engineers, even if a lot of your underlying software is not bespoke. These engineers need to feel like they are learning, and growing, and they deserve to be part of these decisions. The integrations, automation, the shims you build on top to make a unified surface area for the users at your company, the fine-tuning of the use of the software so you don’t spend a ton of money, these are tasks for engineers. I run a platform engineering team, and must tackle the question of “what is platform engineering in the era of the public cloud.” I have yet to run out of software that needs building, despite moving more and more towards open source and SaaS components, but it is an ongoing process to explain to engineers who aren’t familiar with working on these problems why they are still interesting and fun even when you aren’t building everything from scratch.

Wrapping Up

If you believe your company to be a tech-driven company, there should be plenty of things for engineers to build, and even the integrations they are crafting will have meaningful engineering challenges. As a leader, you have to support their desire to innovate, experiment, learn, and build. Buying software is often the right decision for the business, but if you need to go deep into this path, you must challenge yourself to identify the meta-products that the team is creating to take these off-the-shelf solutions and turn them into a productive ecosystem.

--

--

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store