The hidden cost of mediocre internal tools

I've written previously about the reasons that tools developed internally at your company should be good enough to get the job done and no more. That post is a cold cost-benefit analysis explaining why doesn't make sense to develop your internal tooling to the level of consumer products.

But there's an extra cost factor that just wasn't visible to me back when I wrote that post.

Picture an acquisition...

Imagine you're the PM in a 100 person data analytics company which has just been acquired by a corporation with 30k employees.

The plan is to roll your data analytics company into the acquiring companies tech stack and offer its features as a core part of the larger product. This is a common acquisition strategy where a startup becomes a feature of a much larger product.

In order to successfully integrate with the parent company, it's decided that you will migrate off AWS and onto the internal platform of the 10k company. You might even be excited by this because surely that huge scale they're going to have awesome internal tools to work with.

Unfortunately, once you start integrating it becomes clear that things aren't as rosy as you might imagine. The internal ELK logging stack is a few versions behind current, the deployment tooling is oddly tailored to some legacy situations that used to be commonplace and the configuration system is designed for a static world that most companies have moved on from.

This can easily happen for the very solid reasons I outlined in my previous post. It can easily be the most rational decision to put the minimum investment possible into these internal tools so that they are good enough to provide the minimum functionality but don't have any bells and whistles.

Now you're thinking... "I'm about to migrate my company onto a software stack which is worse than where we came from pre-acquisition. Why the hell would I do that?". So you fight to stay on your existing stack and not integrate fully into the acquirer.

Or internal development...

Next, let's take the case of a small team of 4 people who were quickly put together within the acquiring company in order to rapidly tackle an emerging market need.

They're starting from scratch and developing their own microservice to tackle the market opportunity. They want to get to market fast and they want to have good tools to be able to manage their service in production.

Now they're looking at the same internal stack and they're thinking "I can just quickly deploy a VM for monitoring and another one for logging and I can manage them within the team. It's not our core competency but opensource makes it easy and it just needs to handle small scale for our own use."

If I use the provided tools, the alternative is a 3-month process of red tape in order to integrate with the canonical stack within your parent company.

So again you chose to optimize for your own needs and you stand up your own stack.

Fracturing

Finally, imagine you're a VP within this 30k company and you're looking at all these snowflake stacks spring up. Teams are eschewing the tools that have been built for them and creating their own stuff instead because they can get something working super quickly at small scale. Because internal tooling has been built to be just-good-enough to work, nobody wants to use it.

Worse, you now have fractured data-lakes within the company. An enterprise company with 30k employees should be thinking super hard right now about how they can get into the big data game. But the data analytics company can't analyze the data of the small internal team because they each are building their own logging and stats stacks.

Mediocre internal tooling leads to fractured tech stacks and has a very real cost on the value your company can bring to the market.