Part 2: How to reach business agility in a fast-growing scaleup

If you start like Emma did 5 years ago — as a startup — you are in constant ‘survival mode’. You design your IT systems with tools and knowledge available to you to get the business running and growing. You make a lot of decisions that make a lot of sense in the phase you are in. You build your system incrementally, improving what needs to be improved and adding all the things that your growing business needs. In this phase you don’t think about longer-term strategy, about continuous integration and delivery (CI/CD), about architecture patterns or organizational design — you try to keep up with the business and solve the challenges of today and tomorrow. You don’t solve the problems that lie ahead in 1, 3 or 5 years — and that’s good! As said very well and fitting by Donald Knuth:

‘[…] premature optimization is the root of all evil (or at least most of it) in programming.’ — Donald Knuth, Computer Programming as an Art (1974)

However, if your business remains successful, eventually you reach the next phase and become a ‘scale-up’. And now, all the decisions that made sense early as a startup come haunt you as legacy and technical or organizational debt you’ve deliberately built up. When I joined Emma late 2020, we were exactly at that stage: Business was thriving, yet software development was merely reacting, drowning in tickets, and becoming a bottleneck to business development. There were many reasons for that, organizational and processes are part of it but also the technical architecture and infrastructure were big factors.

Remember: Emma is just 6 years old but experienced hypergrowth since its infancy. As the business grew almost exponentially, the organization scaled with it — fortunately linearly. However, what didn’t scale was the technology.

Although running on the (Amazon) cloud, the E-Commerce system used was the legacy version 1 of Magento with many, many customized extensions developed over the years that were implementing ERP-like functionalities, servicing the business as it grew. This, inevitably, accumulated a lot of functionality that doesn’t really provide distinguishing intellectual value to the company, but that, nonetheless, needed to be maintained and operated. At the same time, Emma started to implement a 3rd party ERP-system (Microsoft Dynamics 365 Business Central) to professionalize its operational and financial processes from an end-to-end perspective. I’ll cover the special aspects of repackaging an ERP-system integration in a separate blog post (see here).

Looking at it from one level up and depicting the situation like in the illustration below (i.e., categorizing 4 sectors of visible or invisible and positive or negative value contribution), the areas consuming the most capacity were of negative value (‘bug’ and ‘technical debt’) with some also allocated to ‘feature’ work. Obviously, the goal is to focus on both positive value areas and explicitly invest enough in the invisible area of ‘architecture’ to avoid accumulating invisible technical debt in the future.

We are feature+bug+technical debt, but need to be architecture+feature+bug (source: Kruchten, P. 2009)

Reviewing the status quo and anticipating Emma’s highly ambitious business goals, it became apparent that the current technical landscape would not suffice and simple, incremental improvement would not be enough to transform. We needed a radical step ahead — a leap to the next level of technical productivity, enabling global business in 30, 40, 50 or more countries, becoming proactive about business innovation, living on the cloud, and scaling not only technically but even more importantly, organizationally. We needed to enable concurrent business development driven by our country teams — we needed to become Business Agile, thus deprecating the old platform and designing a new, modern one.