Choosing a tech stack through the ambition matrix

Whenever I get the chance to work on something that doesn’t need to be part of a core tech stack, I love to shop around. Maybe there’s a framework you heard about on HackerNews. Maybe you’ve been building your own. Maybe you just want to use newer technology than your existing stack. All of these are great reasons to try something different.

It’s one thing to read or listen to someone’s testimonial with a technology. It’s something else to try it out for yourself. Developer experience can be just as important as scalability - even if you don’t adopt the technology long term, understanding different approaches will help make you a more experienced developer.

There’s a lot of metrics you could assess a stack by. Performance, ease of use, number of dependencies, popularity. They’re all good to consider, but I prefer to use the metric of “what will I learn from this?”. If I failed to learn anything when I got the chance, I consider that a wasted opportunity. Sure, there are times when you should use what’s familiar because of development time needing to be quick, or because the project is intended to be maintained by people other than the developer. But those cases should be considered part of your core stack. The ambition matrix is helpful for thinking about this.

https://hbr.org/2012/05/managing-your-innovation-portfolio

When it comes to development, you can think of core as being your existing products or codebases that you work on every day. They have a clear userbase, they have a clear usage. If something was to happen to them, people would yell. These are codebases you should be careful to touch - and use your existing knowledge and tech where possible. Next are the adjacent codebases - these are typically projects yet to exist, but will be important for the future. Here you’d want to use proven technology which might deviate from your core stack, but still avoiding a framework with 5 stars on Github. Think more along the lines of adopting purely React when your core stack is mostly using Handlebars. Finally, we have transformational. These are far out ideas: perhaps you’ve seen a need for a framework that you made and would like to adopt it. Transformational projects are not critical systems, and you don’t even need on-call for it.

Applying the ambition matrix to real world cases looks something like: 1 Core) Our production newspaper codebase uses Handlebars for a lot of existing widgets, so if we want something quick that we know works (like an NPS survey), we should use Handlebars. 2 Adjacent) We’re rewriting parts of the frontpage to be part of an A/B test, so we look at options and land on using React, which we work with elsewhere but not in the core stack. This allows us to safely introduce React without needing to answer a lot of questions before using it. 3 Transformational) We’re writing a dashboard that will be only used internally, so we use Derw to learn more about how it works.

Note that things tend to move from Transformational → Adjacent → Core. Experimental innovations lead to new projects, new projects become legacy projects. The benefit of this model isn’t to avoid innovation - but rather ensure that it occurs in a space where it’s safe to say “no, this is not working”. If a language or framework isn’t serving the need, it is safe to drop it during the transformational stage. Your project has no users, so no one is going to be harmed by a codebase rewrite. Likewise, core does not mean that your codebase cannot be improved. But rather it should be improved by a known and understood entity.

The ambition matrix came with some suggestions on how much of each stage you should be doing, along with the return you might get from investment in each stage. The idea is similar for development: if all you invest in is core, your codebase grows stale. If all you invest in is transformational, your users (and business) suffer. A balance should be found, and typically my happiest ratio is 40% core, 30% adjacent, 30% transformational. Different teams and developers will have their own personal preferred ratios, but opening it up for discussion with your tech team will help ensure that both your developers and their code are happy.

Don’t be afraid of change. Understand what you want to change, why, how and what the business effects will be.