At FINN, we are determined to build the most popular car subscription platform. We are on a promising path and hit $100 million annualized recurring revenues (ARR) in 2022, in our third year of existence. Supporting this immense growth we need technology. But as the company changed so much in only three years, our technological needs changed just as much.

As my colleague Ish Zafar outlined in his article No-code isn’t scalable, we were facing a range of technical challenges that were a loud cry for action. For in order to enable the business to grow as fast and ambitiously as we were planning to, we had to make our technical foundation scalable. So we decided to build a next generation car subscription platform standing on a foundation of pro-code.

Now imagine a growing company that is busy as a bee hive. And then you come to realize you need to do this tiny change of turning the core tech platform upside down while the business is running ever-faster. How do you manage a project like this?

I was visiting the OMR Festival in Hamburg in May last year and listened to a talk by the Delivery Hero CTO Christian von Hardenberg. He was presenting their approach to unifying all Delivery Hero’s acquisitions’ technical systems. This talk gave me two key insights:
Think 10x – a Google paradigm to innovate and create moonshots
A centralized approach may not win over a decentralized one

Moonshot mindset
Thinking 10x—this refers to shifting the mindset and aim for improving 10x rather than by 10%. The idea behind it is that people get way more excited about an opportunity to make something 10 times better. The goal becomes to create breakthroughs and to be radical. An accelerator is the ability to detach from existing solutions and old assumptions.

Discovering 10x-thinking triggered another thought process. In my view, it in addition emphasizes the iterative nature of evolving a minimal viable product (MVP). Building an MVP requires some kind of agreement of what’s minimal. So, when I thought about our goal—to create a scalable car subscription platform that serves 100,000 cars, having that number in mind and discovering the 10x thinking—suddenly I knew how to structure this project: we would start with an MVP serving 10 cars and iterate 10x the number of cars in each cycle going from 10 to 100 to 1,000 … and eventually to 100k cars.

Let’s go decentralized
FINN’s organization is split into vertical departments that are very independent, autonomous, and follow their own departmental missions. The sum of its parts results in the company mission. The Engineering department, however, is an enabling function, which means that Engineering teams are mostly distributed across all other departments. When starting the new subscription platform project, it quickly became obvious that it was going to be a cross-department effort involving teams from all departments.

A decentralized organization can hold a lot of complexity. Holding the complexity of a cross-departmental project that would reach the size of coordinating ten streams plus guiding the technical side of things would simply have been too much for one person alone. I am very grateful for my colleague Andrea Perrizato for joining me and taking ownership of the technical guidance throughout this project. Having two perspectives on the same situations is incredibly valuable and can elevate outcomes to a higher level, I am convinced.

A project principle
After having the basic project structure and approach defined, we added one simple project principle for everyone to keep in mind and use as a decision aid. The principle is “strategy is delivery”. For me it has one very clear meaning: to prioritize shipping features fast. Not in order to rush the process—to the contrary. We wanted to use this project to do it right. To review processes and workflows that grew organically and adjust them if we learned how to do things better in the meantime. The principle’s meaning underscores the sense of building an MVP. This MVP not only aims to do things better in the long run, but also, during short-term implementation iterations, aims to ship fast to maximize feedback cycles.

You could argue that the principle “strategy is delivery” has another meaning, at least in the beginning. After all, we are delivering cars that have been subscribed to be delivered at our customers’ doorsteps. For the very first car (and probably the following 100 too) serving the car delivery was very much the goal. On reaching every new 10x milestone we had a special sticker counting the number of cars delivered. We just got the 1,000 cars version added to the collection.

Zooming out to zoom in
Okay, I hear you asking, but how do you get going? My personal preference on doing things is to get context and see the bigger picture, so that I know what I am working towards. I’d like to think about it as zooming out, in order to be able to zoom in. In our first scoping workshop for our MVP 10 Cars, people from all teams came together to do exactly that: zoom out, to zoom in.

The tricky part about having a decentralized organization is the question of how to access distributed knowledge and make it available. Bringing relevant people onto the same (figurative) table is step one. Step two is pouring out the knowledge. My biggest objective was to understand what the whole lifecycle of a car and a subscriber at FINN looks like. I knew every department works on parts of this cycle, but I couldn’t visualize the whole process.

Everyone drew their core parts on a Miro board and we could stitch it together having one flow. We could break each step down into features and prioritize these features to match the MVP iteration’s focus. We would repeat this process for every MVP iteration and refine the overall flow as well as the next prioritized features.

Give out trust and ownership instead of managing risk
When you google for project management it is highly likely that you’ll find articles on managing risk. In the context of software development I refuse to understand this concept. Building software is inherently risky, because you’ll never really be able to predict the exact outcome and timeline. So, let’s just accept that there is risk.

Instead I want to give people trust and ownership. After choosing and defining the scope for every iteration collectively, I trust people will pick up the right things to work on in order to reach our joint goals. In a decentralized organization like ours, they effectively know their domain best. I like to give people true ownership, because I want to avoid micromanagement at all costs. Never forget that with ownership comes freedom and responsibility. I strongly believe that when giving out trust first and foremost, adding ownership on top, most people won’t risk you pulling the plug because they enjoy their radius of operation and know their impact.

See the gaps
For following through, it is essential to have an overview at all times and to never lose track of the target picture. Establish a weekly stage to exchange updates, challenges, and successes between teams. This will provide two opportunities:

• It creates accountability
• It can uncover gaps

You want to have week-by-week accountability to encourage progress to be made in a timely manner on the defined scope. More importantly, I think it is crucial to see gaps when connecting the dots week by week. This way you can course correct without a lot of delay and manage the project’s successful progress effectively. You are by default not waiting for crashes to occur and adjust direction only after they happened, but instead you are trying to read the ocean and navigate it based on your observations (which still leaves room for crashes).

Communicate interdependencies
Lastly, and this is especially true for a cross-department project, communicating interdependencies right from the beginning is key. Make this step mandatory, prior to any line of code being written or any automated workflow being built. For whenever there are dependencies between multiple teams it is most important to get back onto that figurative table with the teams involved and get clarity on each other's requirements and dependencies. We aim to design solutions for each other, because every team has stakeholders to serve and we highly value being customer-first at FINN.

Originally published on LinkedIn