Build v.s. buy: how billing models affect your internal culture
13th December 2020
Something to pay attention to when making a build v.s. buy decision is the impact that billing models will have on your usage of a tool.
Take logging for example. If you buy a log aggregation platform like Splunk Cloud or Loggly the pricing is likely based on the quantity of data you ingest per day.
This can set up a weird incentive. If you are already close to the limit of your plan, you’ll find that engineers are discouraged from logging new things.
This can have a subtle effect on your culture. Engineers who don’t want to get into a budgeting conversation will end up avoiding using key tools, and this can cost you a lot of money in terms of invisible lost productivity.
Tools that charge per-head have a similar problem: if your analytics tool charges per head, your junior engineers won’t have access to it. This means you won’t build a culture where engineers use analytics to help make decisions.
This is a very tricky dynamic. On the one hand it’s clearly completely crazy to invest in building your own logging or analytics solutions—you should be spending engineering effort solving the problems that are unique to your company!
But on the other hand, there are significant, hard-to-measure hidden costs of vendors with billing mechanisms that affect your culture in negative ways.
I don’t have a solution to this. It’s just something I’ve encountered that makes the “build v.s. buy” decision a lot more subtle than it can first appear.
It’s also worth noting that this is only a problem in larger engineering organizations. In a small startup the decision chain to “spend more money on logging” is a 30 second conversation with the founder with the credit card—even faster if you’re the founder yourself!
Update: a process solution?
Thinking about this more, I realize that this isn’t a technology problem: it’s a process and culture problem. So there should be a process and cultural solution.
One thing that might work would be to explicitly consider this issue in the vendor selection conversations, then document it once the new tool has been implemented.
A company-wide document listing these tools, with clear guidance as to when it’s appropriate to increase capacity/spend and a documented owner (individual or team) plus contact details could really help overcome the standard engineer’s resistance to having conversations about budget.
This post started out as a comment on Hacker News.
More recent articles
- Datasette Enrichments: a new plugin framework for augmenting your data - 1st December 2023
- llamafile is the new best way to run a LLM on your own computer - 29th November 2023
- Prompt injection explained, November 2023 edition - 27th November 2023
- I'm on the Newsroom Robots podcast, with thoughts on the OpenAI board - 25th November 2023
- Weeknotes: DevDay, GitHub Universe, OpenAI chaos - 22nd November 2023
- Deciphering clues in a news article to understand how it was reported - 22nd November 2023
- Exploring GPTs: ChatGPT in a trench coat? - 15th November 2023
- Financial sustainability for open source projects at GitHub Universe - 10th November 2023
- ospeak: a CLI tool for speaking text in the terminal via OpenAI - 7th November 2023
- DALL-E 3, GPT4All, PMTiles, sqlite-migrate, datasette-edit-schema - 30th October 2023