How Failing Fast Drives us Forward at Zalando Tech

At Zalando, we try to live a mentality of failing fast. The context here is not a failure of the person or the group involved, but rather a chance to learn from the mistakes that were made. If you fail fast, you are also able to right the wrongs much quicker. Failing fast can be a golden opportunity, and our team (Team Sokoban) tried to apply this mentality during the beginning of our stock rebuild.

The stock system is the connection between the physical warehouses and the CFAs, and knows where an item is located, how much we still have in stock, and how many units we can still sell to the customer. It’s easy to see that it is an important component in Zalando’s Platform Strategy, and our system has to be ready for the challenges that lie ahead.

To get the rebuild on track, we started with a two-week workshop where we exclusively focused on this topic. We defined requirements for the stock, designed an architecture, and according to Zalando’s API first principles, designed APIs for these new services. This is important, because it’s one thing to own and know the own domain, but something else to know everything about the surrounding teams that rely on our solution. With this API, we were now able to liaise with other teams and involved parties about the future, allowing them to give us feedback on their behaviours and requirements. It was during this step where our failing occurred.

Some of the options we presented just didn’t work out, due either to our data model, or the fact that other teams had plans which wouldn’t work with our solution. Our team felt that this wasn’t a problem, as we were able to spot bigger issues right at the beginning of the project and adapt them without much effort. We were redrawing architecture pictures and redefining APIs, but in the end we crafted a more stable and improved solution thanks to the fast feedback we received in such a short timeframe.

But this doesn’t end with APIs. While defining and implementing APIs for example, we were already implementing the monitoring required, or thinking about how scalable our solution would be. Load tests were completed to identify problems in the setup while we spoke with different teams about monitoring and common problems. This coincided with us making plans for migrating the old data.

In conclusion, failing fast is about getting feedback from the very start of your project, and testing your API, setup, or implementation. Don’t try to overthink everything and come up with a perfect solution at first. The lesson here is that changes will be made, and when you approach the work unafraid of failing, you’ll be able to recover and fix the issues raised without sacrificing months of hard work.

If you have any questions or anecdotes to share about your own failing fast experience, get in touch via email.