Skip to main content

The complexities of build vs buy

·2 mins

Reposting last weeks post on the IKEA effect to LinkedIn kicked off an interesting discussion on the complexities of build vs buy.

In particular I liked this from Shane Gibson:

If the Data Team wanted to go and buy some technology, lets says a Data Catalog, they have to ask for budget and that will require them to create documents, ask permission etc.

If they use open source, again they typically have to create documents, ask permission etc.

Both of these require somebody outside the data team to make a decision if the cost is worth the benefit.

However if the the data team build something themselves, the cost is hidden.

They just “steal” time from the data work the organisation has prioritised.

That’s always been something that has troubled me with build vs buy. If I get my team to work for months on building something like a data catalog I’ll get very little push back. However, if I ask for some money instead - which, when compared to the cost of the people we’re committing to this is much smaller - I’ll have a lot of hoops to jump through and need to create an entire business case.

There are a few other complexities of build vs buy. One is that the procurement process at many organisations is… a challenge, and can be very demoralising to go through.

Another is that with the way things are at the moment you might have an objective that is simply “reduce SaaS spend”, so once again you’re trying to convince someone outside your team of the value of that spend for each SaaS product you have.

All of that can feel a bit depressing as someone who is just trying to get things done in the way that delivers the best value for the organisation.

Having said that, it’s often a good idea to try and understand something from the other point of view, and in this case it might look a bit like this. A budget has been approved for the data teams, which gives you your headcount. Any SaaS spend is on top of that budget.

You should have to argue you’re delivering more by spending that, but equally the response could justifiably be “no, this is what we’ve given you, give us the best value for that”.

Unless of course you want to make the case that by buying something you can reduce headcount. But few leaders would argue for a smaller team.


Want great, practical advice on implementing data mesh, data products and data contracts?

In my weekly newsletter I share with you an original post and links to what's new and cool in the world of data mesh, data products, and data contracts.

I also include a little pun, because why not? 😅

(Don’t worry—I hate spam, too, and I’ll NEVER share your email address with anyone!)


Andrew Jones
Author
Andrew Jones
I build data platforms that reduce risk and drive revenue.