About Weirdness Budgets

What is a weirdness budget? You might have heard about this concept as an “innovation budget” or a “risk budget”. I personally don’t like the term “risk budget”, as I think that underestimates risk itself.

Typically, when we talk about a weirdness budget, we refer to a particular project. Within this project, we usually have a block of work that is well understood - reusing API integrations, or existing data structures for example. Then, there is work that is clearly net new, like integrating with a brand new API. The interesting part is the third - work where optionality exists. Do we reuse an existing queueing mechanism, or is this work appropriate for something new? Do we need to explore different architectures to make this work? And so on. This is where weirdness budgets come in - for decisioning on this space where optionality exists. Let’s start with some basics.