Vinted Engineering

My name is Mangirdas, I’m an Engineering Manager here at Vinted, and I’ve just participated in a miracle project. Our team (Stardust) coped with a big technical challenge to bring a new project to life: the Vinted Go lockers network.

What happened is remarkable. Vinted is already a big company by Lithuanian standards, with well over 1000 employees in Vilnius alone. It’s not a secret that the bigger the company, the harder it is to launch new products and move fast. However, in this case, our team, responsible for the engineering part of the project, had the complete freedom to make decisions and move as fast as a brand new startup. Until now, I’ve only read books about these ‘startup within a company’ projects. This time I got to experience it, and it was incredible.

How do projects usually take place at Vinted?

Usually, we stick to the following steps when working on any significant project:

• Discovery, analysis, hypothesis, rough estimation.
• Teams (Engineering, Marketing, Design) plan their contributions in parallel.
• Commit deliverables to upcoming quarters.
• Execution and adaptation to changes.
• Launch, monitor, and reflect.

This approach works very well for us. Out of everything I’ve seen in my lifetime, this process provides the best balance between reliability and agility.

What happened differently this time?

If they’d been working within our standard process, our Engineering team’s deadlines would have only allowed them enough time to finalise the first step of the process (the analysis). At Vinted, we don’t like to compromise our regular working hours. Meaning overtime isn’t an option to meet the deadlines. Historically I’ve seen all kinds of decisions made in similar situations, like extending the deadline, cutting other projects, and reducing the scope. By chance, it happened differently this time.

I got involved in this project because Tomas, our Product Manager, had experience in a similar project. Our team (mainly backend engineers) had been doing integrations with other shipping companies for two years. We knew the fundamentals of how this kind of service should work. That was an “Aha!” moment. We realised that the team had the ability to help make this project happen. I asked if my engineers were willing to risk and commit to this project, to which I received a unanimous “Yes, sure!”. Together, our team expressed an interest in taking on the project, and we got it!

The project delivery

Within the project, our team had complete trust and freedom to work autonomously. We made a million internal decisions without consulting with the rest of the company. That’s not regular practice here at Vinted - our company greatly values co-creation and collaboration. We usually tend to share and discuss all plans in broad circles. But in this case, it would have slowed us down too much. To avoid any delays in the decision-making process, we tried to contain everything within the team. The intention wasn’t secrecy, but rather a complete focus on delivery. Limiting circles of influence to the team level speeds up the initial planning, and makes it easier to change your mind about any aspect of the software. And we made several swift turns regarding how our software works and looks.

Without bowing to the pressure of looming deadlines, we spent enough time discussing the core architecture and made it scalable, efficient, and practical right from the start. Books about agile development often suggest delivering something tiny but functional at the very beginning, and then improving. This ensures early feedback and guarantees that at least something is done by the end of the deadline. However, that’s not the most efficient way to deliver software. It leads to multiple refactorings later down the line because that ‘tiny’ first deliverable is never what you need at the end. To avoid that, we spent a week trying to find the best architecture, and then we began building it.

That was risky. The project would have suffered a lot if we’d chosen a poor architecture. Fortunately, we nailed it - mainly thanks to our experienced engineers.

Clearly defined architecture enables every engineer to work on their part and be sure that it sticks well to everyone else’s code. We didn’t skip our Scrum rituals. We continued to work in sprints, but there were no releases or demos at the end of the sprint. Very often, the deliverables were just new API endpoints made available to consume.

I would NOT say that we had to sacrifice the quality of code. We covered 99% of the backend with unit tests and had some integration tests. However, some shortcuts were made. For example, we didn’t have time to dig into the design part of the product properly and do iterations, or gather enough feedback from test groups. Some external parts of the system had no chance of being adopted to 100% suit our needs. But the critical point for us is that fundamental aspects are made well, and cosmetics, in our opinion, can be fixed later down the line.

During the project, we worked a lot and passionately. But we didn’t do overtime. Most engineers still managed to take a week or two of annual leave. Again, that’s because of the important planning that we did at the start. For example, we only had one Web and one App engineer. Both of them needed to take some holiday time. A clear plan ahead enabled the rest of the team to continue working on their parts when key team members were on leave.

What led to success?

Fortunately, our team pulled off this challenge. The number one success ingredient was the dedication of every single team member. We had no internal conflicts. Our only enemies were missing lines of code and unsolved problems. However cliché this sounds, that was the key. If your team doesn’t thrive together, the chances of pulling off a project are slim. On the other hand, having a dedicated team is not enough. I believe that the following points are also essential in pulling off a successful project:

• Freedom of choice.
• Swift decision-making.
• Complete trust from higher levels of the company;
• Technical leadership;
• Product leadership;

All the items mentioned above are interconnected. For example, how can you make swift decisions if you don’t have trust, freedom, and technical knowledge? If you don’t have the freedom to change things down the line, you’ll be more afraid to make the decision in the first place, and likely to spend more time on every single decision you make. And vice versa - the more trust and skills you have, the faster you can make a decision, because you know that you’ll be able to adjust it, and nobody will stand in your way.

Some luck is needed too. If you get highly unlucky, any project can fail. We had several fallbacks too. Some external APIs we used turned out to be highly inconvenient, so we needed to adapt. As usual for any project, some assumptions failed. The answer to this challenge is known in the industry - be agile and change, which we did. Sometimes we made significant decisions right during the stand-up. In particular, that was noticeable in priorities. Features that appeared critical turned out not to be at all, while others became critical. The people who made previous prioritisations had to be brave enough to recognise that.

Can the same development speed continue forever?

The short answer is - no. A development speed like this can only be achieved on new products that can be developed independently of the existing systems. As millions of users start using the system and multiple teams start working on the same product, everything slows down:

• Meetings take longer.
• Each change needs more attention as the existing user base may be affected.
• Cross-team alignment appears on top of any routines and creeps into all projects.
• All the past features always have to be taken into account.

The only solution I see to keep the speed going is splitting the product into distinct parts that can evolve independently - reducing the need for constant alignment and collaboration. But eventually, there will be projects that cross-cut multiple teams, which is just the nature of the industry.

Have you had anything similar?

I’ve described this experience as if it’s 1 in a million. However, the world has millions of projects. There are many engineers out there who have experienced something similar. If you haven’t worked on a project of this sort, I encourage you to try it out! Be careful to do it on the right project and at the right time. A healthy, experienced team of engineers is a must, and the project must be independent of the old products and code.

Come and visit the project’s public website: vintedgo.com