A few years ago I was working on a contract negotiation with Splunk,
and we kept running into what felt like a pretty unreasonable pricing structure.
They wanted some number of millions of dollars for a three year license,
which felt like a high price to pay for thirty-two ascii characters
in a particular sequence.
Even with the license, we’d still be the ones operating it
and paying for the capacity to run it.
We decided to negotiate by calculating the cost of running our
own ELK Stack cluster,
determined by means of the appropriate solution of solid numbers and hand waving.
We used this calculation to establish Splunk’s value to us
and ultimately got Splunk to come down to our calculated value instead of their fee structure,
although I suspect we might have overpriced the value a bit and
landed too high within the zone of possible agreement.
Recently Calm has been considering if we
should move parts of our workflow to a headless CMSes,
and consequently I’ve been thinking a bit more about how to make these sorts of
build versus buy decisions, and in particular how to evaluate the “buy” aspect.
Ultimately, I think it comes down to risk, value, and cost.
Risk
Using a vendor is taking on an outstanding debt.
You know you will have to service that debt’s interest over time,
and there’s a small chance that they might call the debt
due at any point.
From a risk perspective, calling the debt due isn’t the vendor
holding you hostage for a huge sum, although certainly if there’s
little competition the risk of price increases is real. Rather,
the most severe risks are the vendor going out of business,
shifting their pricing in a way that’s incompatible with your usage,
suffering a severe security breach that makes you decide to stop working with them,
or canceling the business line (which some claim has undermined Google’s abiltiy to gain traction on new platforms).
Some risks can be managed through legal contracts.
Other risks can be managed by purchasing insurance.
Other sorts you simply have to decide whether they’re acceptable.
In the build versus buy decision, most companies put the majority of their energy
into identifying risk, which has its place, but often culminates in a
robust not invented here culture
that robs the core business of attention. To avoid that fate, it’s important to
spend at least as much time on the value that comes from buy decisions.
Value
Businesses succeed by selling something useful to their users.
Work directly towards that end is core work, and all other work is auxiliary work.
Well-run, efficiency-minded businesses generally allocate just enough resources to auxiliary work
to avoid bottlenecks in their core work, reserving the majority of their resources for core work.
This efficiency-obsession is a subtle mistake, because it
treats auxiliary work as cost centers disconnected from value creation.
In reality, value is created by the overall system, which includes auxiliary work.
Many companies create more value from their auxiliary work than their core work, for example
a so-so product supported by extraordinary marketing efforts.
Other companies sabotage their core work by underinvesting
in the auxiliaries, for example a company of engineers eternally awaiting design guidance.
To calculate the value of a vendor, compare the vendor’s offering against what you’re
willing to build today. The perfected internal tool will always be better than the vendor’s current offering,
but you’re not going to build the perfected internal tool right now, what will you actually build?
Also, how will the quality and capabilities of the two approaches diverge over time?
Most companies, particularly small ones, simply can’t rationally invest into improving their
internal tools, such that they get worse over time relative to an active vendor.
If you’re assuming the opposite, dig into those assumptions a bit.
Vendors selling those internal tool have a totally different incentive structure
than you do, and it’s an incentive structure that
requires they make ongoing investments in their offering.
At a certain point you may reach your own internal economies of scale that
support ongoing investment into internal tooling.
Uber famously built their own replacement for both Greenhouse
and Zendesk after reaching about 2,000 engineers, but they relied on
vendors extensively up until they reached that point.
One way that folks sometimes discount vendors’ value to zero
is they worry that the vendor simply won’t be good enough to use at all.
This implies the existence of a boolean
cutoff in quality between sufficient and insufficient quality.
This is a rigid mindset that doesn’t reflect reality: quality is not boolean.
There will be gaps in vendor functionality, and you should absolutely identify those gaps
and understand the cost of addressing them, but avoid falling into a mindset
that your requirements are fixed absolutes.
When it comes to build versus buy,
the frequently repeated but rarely followed wisdom is good advice:
if you’re a technology company,
vendors usually generate significant value if they’re
outside your company’s core competency;
within your core competency, they generally slow you down.
Cost
Once you understand the value a vendor can bring, you then have
to consider the costs. The key costs to consider
are: integration, financial, operating and evolution.
Integration costs are your upfront costs before the vendor can start
creating value. This is also the cost of replacing the vendor if the current
vendor were to cease to exist at some point in the future.
This is where most vendor discussions spend the majority of their time.
Financial costs are how much the contract costs, including projecting
utilization over time to understand future costs. This is another area that
usually gets a great deal of attention during vendor selection processes,
but often with a bit too much emphasis on cost-cutting and not enough on value.
Operating costs are the cost of using the vendor,
and in my experience are rarely fully considered.
This includes things like
vendor outages or degradations, as well as more nuanced issues like making mandatory
integration upgrades as the vendor evolves their platform.
Stripe’s Payment Intents API is
far more powerful than the previous Charge API,
but there’s a large gap between knowing a more powerful solution is available and
learning last year that PSD2’s SCA requirements
meant you had to upgrade to keep selling to buyers in the European Union.
How you want to use a vendor will shift over time, which makes
evolution costs essential to consider, and similar to operating costs
are an oft neglected consideration.
This is where vendor architecture matters a great deal, and
well-designed vendors shine.
An example of good vendor architecture is
headless CMSes: they’re
flexible because they’re focused on facilitating one piece of the workflow.
If some piece of the workflow doesn’t fit for a niche workflow you support,
just cut that one piece away from the headless CMS: you don’t have to replace
the entire thing at once.
Some vendor solutions try to create a crushing gravity that restricts efforts
to move any component outside their ecosystem, and these are the vendors to
avoid. Folks often focus on things like being vendor-agnostic, e.g. the ability
to wholesail migrate from one vendor to another, when I think it’s usually more
valuable to focus on being vendor-flexible: being able to move a subset of your
work to a better suited tool.
Your total cost model should incorporate all of these costs,
and becomes a particularly powerful tool in negotiating the contract.
Pulling it all together
Once you’ve thought through the value, risk and cost, then at some point
you have to make a decision. My rule of thumb is to first understand
if there are any sufficiently high risks that you simply can’t move
forward. If the risks are acceptable, then perform a simple value versus
cost calculation and accept the results!
Generally the two recurring themes I’ve seen derail this blindingly obvious
approach are legal review (outsized emphasis on unlikely or mitigatable risks)
and unfungible budgets (overall cheaper to use vendor, but company
views headcount budget and vendor budgets as wholy distinct).
These are both sorts of bureaucratic scar tissue that accumulate
from previous misteps, and aim to protect the business.
On average, they likely are creating the right outcomes for the company,
but for specific decisions they might not be. If you believe strongly
enough that this is one of those exceptions, then ultimately I’ve found
you need an executive sponsor to push it through.
A note on vendor management
Throwing in one more thought before wrapping this up,
I’ve found that many companies are quite bad at vendor
management and are quite good at building things.
As such, their calculations always show that vendors are worse than building it themselves,
and that’s probably true for them in their current state.
To get the full value from vendors, you have to invest in managing vendors well.
A company that does this extraordinarily well is Amazon, who issue their vendors
quarterly report cards grading their performance against the contract and expectations.
Getting great results from vendors requires managing them. If you neglect them and
get bad results, that’s on you.
