At growth companies, complexity kills. The reason is simple - complexity is slow, and slow don’t grow.
For example, say the software you’re building has a piece of code that has been optimized for the last 4 years, mostly by one SME. It might run 40% faster than a simpler, less optimized version. But it’s become very complex, and even SME has some trouble keeping all of it in their head at once. One final, critical detail - the code is not bad code. It’s actually very good code. Let’s even take it one step further and say that there’s no way to make this code simpler and keep the optimizations, because optimizing this problem is inherently complex.
What you have here isn’t tech debt - it’s complexity debt. Because the code is so complex, it’s hard to support, it introduces key-person risk, and building on top of it becomes difficult.
For foundational pieces of software or process, the more people building on-top of or using them, the more it makes sense to make them simpler, even if it makes them a lot less optimal.
Keep asking yourself “where can we invest to grow faster?” But you should also start asking the team explicitly - “where can we lose some money but make things much simpler?”
The best place for reducing complexity debt are areas that have the following properties:
The support burden is non-trivial
Onboarding takes a lot of time
You expect to add more people working on this area as time goes by
A great example here is a centralized job processing framework. If you’re building software that operates on a distributed system, you likely have a job processing framework that jobs run on. In many systems, sophisticated server utilization methods are used to make sure that servers aren’t waiting around for jobs. However, those methods often create hard-to-understand complexities around resource planning and triaging of issues. Especially if the whole team is using it, giving features or teams dedicated server capacity, even if it’s wasteful, pays for itself in productivity.
So next time you think about growing your team, think about ways you can lose some money in the name of simplicity, as counterintuitive as that may be.