What is your engineering org's context half-life? (thread)

At Monzo, a bunch of the projects our team takes on involve fundamental changes to our service platform, and sometimes this means removing 'Monzo-specific weirdness'.

We generally aim for things to be as standard as possible, whether that's idiomatic code or technologies that the community are centralising around.

When you're building a company, you have to place bets on technologies, and sometimes you back the wrong horse. Sometimes, there's just nothing suitable available and you have to build it yourself. That's ok.

But when the environment around you changes, it's important to re-evaluate those decisions. Sunk cost fallacy should be at the top of your mind here.

A common piece of feedback we get on proposals to change things is "is it worth adopting X when we already have Y which kind of works and is easy to learn?". This is a fair question, and it's a difficult one to answer.

As an example, Monzo uses a custom RPC framework called Typhon. There are other, off-the-shelf, arguably better systems that exist now, which didn't exist when Typhon was built.

Picking one of a few competing technologies isn't a problem, but when a whole community starts centralising around a single technology and you're not on it, that's when things become more of an issue.

If you gain no advantage from your custom solution, you're effectively continually taking on debt by not swapping it out. The longer you wait to adopt, the more your paths diverge and the harder the migration becomes.

If you were starting today and the choice is obvious, that's a good indicator that you should at least consider migrating to that technology. To be clear, there's no shame in backing the wrong horse - nobody can predict how things will play out.

Uber initially settled on Thrift and Mesos, which subsequently got drowned by gRPC and Kubernetes respectively!

So, should you migrate? Most of the time, it seems that people are making that decision based on the *current* state of the eng org rather than the *future* state. If we have some weirdness, it's easy to say "but we're all used to it and new people can learn it quickly".

However, if you're a growing org, it doesn't take long for the people with context on that weirdness to become a minority. I call this the "context half-life" of an engineering org.

Think about it this way; in the entire life time of your company, of *all* of the people who will eventually need to understand this system, are most of them already at the company or not?

Some quick modelling can show you how removing company-specific weirdness might pay off. With 250 employees, a 30% yearly growth rate and 10% attrition, it only takes slightly over 2 years for 50% of the engineers in the org to have zero context on the original decision.

With a more modest 100 engineers, 20% growth and 10% attrition, that's just over 3 years.

When I joined Uber, we had 100 engineers and grew an astonishing 400% year on (for 2 years) with little attrition. That means after 2 years the original cohort made up just about 3% of engineering.

With those kind of numbers, it's clear to see that investing in removing 'weirdness' would be a good choice. Uber switched out core parts of the platform which allowed thousands of new engineers to join and not need to get familiar with a fading technology.

Monzo is back to growing the engineering team significantly, which means we need to start thinking hard about whether it we should dedicate time to removing our custom crufty implementations and standardising.

Monzo's graph is approximately like this:

We currently have a context half-life of about 2 years. For your company, it might be very different. If you're not growing quickly, maybe you can defer this decision until much later. Don't jump on the bandwagon for the sake of it.

This of course completely ignores the upfront cost of the migration, re-training, documentation, and everything that goes along with making this decision.

This isn't a reason to start a migration, but you probably shouldn't say "no" to one without considering your context half-life first!