How to choose the elements that should make up your tech stack

It seems my question about the technology stack has prompted several other questions, now we focus on how to choose the elements.

Following on from Tony Boobier challenging us to be clear on which type of data leader, guest blogger Francesco Corea returns. Francesco is the research lead at venture capital firm Balderton Capital, as well as an advisor & blogger on all things AI. He has shared with us before on InsurTech and useful AI event in Berlin.

In this post, Francesco shares lessons that he learnt when thinking through how to choose the technology stack for venture capital firms. I think the advice he gives in this post reads across well to what data & analytics leaders also need to consider.

So, over to Francesco to help you step back and choose the elements…

The drive to digitisation

As everything these days seems to move online, it may be a good moment for data leaders to sit back and re-evaluate the ways they run their businesses.

When I started this mapping (and yes, it was way before the lockdown), my main goal was to simply understand what was the current landscape of tools. Ones that investors could leverage and how to choose the best ones that could fit specific needs and structures.

I was also a bit sceptical and a bit fed up with the overused adoption pattern of “everyone else is using it”. So, I had to look with my own eyes at different possibilities.

So I have started navigating the ecosystem. Testing several different things, going through countless demo calls. All with the final aim to be able to reach a more thoughtful decision when looking at a piece of software and be able to optimize a technology stack at a glance.

You can check the full list here, if you wish:

Lessons learnt while choosing elements for that tech stack

Even though the list may be useful per se, I think it could be interesting to share some of the takeaways learned by putting it together. So, here are those I have recognised:

(1) Optimise, optimise, optimise

It is very easy to get swamped by apps and software. To be fascinated by the new shiny tool just released (I am guilty as well, sorry). Focus on what people use and track the usage to see whether some other tool in place can address the specific use case. That may bring you to kill part of your stack.

(2) Stitching things together

The one-stop solution does not exist. Even if it did, I guess that probably investors would be a bit sceptical about it. This means you have to stitch things together. So consider how easy and flexible are platforms. If you want a source of truth, and to avoid disconnection between your systems, this is paramount. Automation is key, but don’t abuse it because the more you stitch, the more likely it is the something will break at some point. Be careful, because more is not always better.

(3) Process vs Product

This is obvious but not easy. Sometimes your problems are not with the tool (or the absence of it) but rather with the process. Easier said than done, but spend time on reviewing & improving your processes first.

(4) Build vs Buy

I am still convinced that if a tool can bring competitive incremental advantage (I am thinking of this, for example), it still makes sense to build it yourself. However, for the majority of the software you want to internally implement, buying them is often more effective. Built-in software has to be designed, maintained, fixed, and there are so many good solutions out there that it does not make sense to create a new one.

Use cases may differ, and there are circumstances where you really need to build your CRM system. But 90% of the time this is not the case. Don’t fall victim to the overconfidence bias. Odds are that a dedicated company builds a piece of software all day long will likely do a better job than you.

(5) Due diligence

I am particularly fond of small emerging and more agile companies. But as an investor, you should use your investment skills and processes to assess a potential tech provider. Is the tech/engineering team behind it good enough? What is the trajectory and roadmap of the company?

Do they have enough funding to be around in one year and if not, will they be able to fundraise or self-sustain? Who are their clients? This may seem too much, simply for choosing a provider. But believe me when I tell you that you are not going to change the platform for at least a couple of years. Switching costs are often too high. So, it is definitely worth the effort.

‘Walking the talk’ when I choose the elements for a tech stack

I am a good preacher. But I have to admit that I often make the same mistakes I warn people against. I believe that choosing a new tool is not a trivial task.

It is similar to renting a new apartment: you have to enjoy what it looks like inside and outside, it has to have all the minimum functionalities you look for (but maybe you can sacrifice a thing or two), it has to be well-connected, and the price has to be good enough for your budget. Plus, you have to consider relocation costs and a minimum tenancy, as you have an onboarding cost and a holding period for the software you end up picking.

One final simple piece of advice

Sometimes it may feel overwhelming to run a full assessment for multiple platforms. So here comes the simplest piece of advice I can give you…

Start with your ideal platform. The perfect solution you want, and design all the requirements or features you want this to have. Consider ease of use, flexibility, and end-user experience. Is the system designed for the purpose you had in mind? How does it ingest or spit out data?

Then, check your list of alternatives against this ranking, and eventually narrow down your options to two. For complex decisions, it seems to scientifically work better to achieve a satisfactory decision.

It is also likely that not everyone will be happy about the choice of the tool, and that’s ok. Try to make happy as many people as possible, but do not be Buridan’s ass and choose something.

Has that helped you make some decisions?

Thanks for Francesco for those tips. Some useful advice there that builds nicely on earlier posts about avoiding Shiny Object syndrome or being seduced by sexy demos. I hope it helped you with choosing your elements.

Do you have advice about the elements of the technology stack that data leaders need to understand? If so, please vote in our latest survey and share your comments below. As Francesco says, this is not easy and we are often working against our biases. So, let’s keep sharing our lessons learnt.