Vinted Engineering

New platforms have and will keep bubbling up - be it smartphones, tablets, smartwatches or embedded devices. Both startups and established organisations encounter a need to enter and support them. We went through different stages of transformation to support multiple platforms. This story can be useful in understanding how to best do that.

Starting Small

Roughly 3 years ago, Vinted was a desktop-only product. The engineering team was comprised of several backend developers, some of whom had complementary web frontend skills. Alongside them, a product manager and designer focused on what to build next.

This small startup team worked well when building out the initial one-platform product, allowing the team to iterate fast and retain super-collaborative atmosphere.

Tackling the Mobile Opportunity

Vinted was a small operation during those days. Thus, mobile presented both an opportunity and a risk. To mitigate that risk, we chose to create the first version of our apps with an external company, keeping only high-level product ownership and API setup on our end.

Working with an external company to create a new face of our product was not easy. We were unhappy with our initial partners and had to switch. Our new partners successfully took charge of an unfamiliar code base and managed to ship on schedule.

During the launch, Vinted was virtually formed of two companies — the initial desktop one and our new partners, who worked on the mobile app. We only came together on the occasional evenings to celebrate the tens of thousands of downloads we suddenly had. The next morning, however, we were in two different offices again, separated by a 30 minute drive in our relatively small city.

Success

Mobile proved to be super-successful for Vinted. P2P messaging is at the core of our buying/selling experience. Mobile mechanics, such as push notifications and constant presence, improved it further. In only 3 days after the launch, some of the markets already saw a fourth of all activity on mobile. In 6 months, activity on mobile overtook desktop. We became a mobile app company with a desktop-centric organisation.

After the launch of mobile apps we understood the strategic importance of building out mobile skills in-house. We have started with hiring a few mobile engineers and creating a team with a couple of our launch partner’s battle-hardened developers, who continued to help us. Slowly, this transformed into a team of 6, focused on mobile apps.

This setup worked well for a while. It was at its best while mobile played feature-based catch-up to the desktop product. Yet we did not even notice when we ended up slowly diverging and creating two different products: desktop and mobile. In addition, we started running into dependency roadblocks and getting slower with every sprint — a lot of new stuff on mobile required the backend team’s time. The backend and mobile teams were involved in a constant ping-pong of requests, fulfilments and readjustments, which often resulted in a 2 week lag.

It was clear we needed to find a better way to organize — to deliver one product, a consistent user experience across different platforms, and still iterate as fast as we did in our early days.

Welcome to the land of small startups

When the company grows and you become slower, it is only natural to remember the old days when you were small, lean and agile. Yet you can still retain a lot of this spirit — and we found a way to do this in Product.

Instead of 3 function-based mobile, web frontend and backend teams, we have started experimenting with cross-functional teams that resemble small startups. We have started with a single team comprised of all the people needed to ship a product improvement across all the platforms: iOS and Android engineers, a Web frontend developer and a couple of Ruby on Rails backend programmers with a product manager at the helm. The team had very little outside dependencies and could solve a lot of issues very fast. Close teamwork led to better planning and execution of integrated solutions with clear ownership of value delivery to the user.

After seeing the first positive signs with the experimental team, we have quickly formed a second, and — a few weeks later — a third one, fully switching to this new way of working. After a few months, we saw designers joining these teams to integrate better, killing even more dependencies along the way. With Vinted continuing to grow, we scaled this model to form a few more teams, and ended up with a total of seven.

Issues?

As good as it sounds, no structure is without its own issues. We use this structure to continuously improve our products for more than 2 years already.

With teams being focused in solving specific problems and seeking different opportunities, they can become relative silos and you may lose consistency in different areas — design and code execution as an example. In addition, we ended up with no clear ownership and development of specific areas and platforms.

Looking for ways to solve these issues, we have learnt a lot from how Spotify works. Inspired by their culture, we have introduced Guilds concept in our organisation. They act as virtual organisations with dedicated time allocation and clear leadership. Guilds are empowered to come up and execute clear area or platform vision. This solves consistency and ownership issues and provides great platform for people mastery development in specific fields they pursue.

Cross-functional teams are empowered even more when people start to be interested in other areas and acquire complementary skills. At Vinted, several Android developers learnt the basics of Ruby on Rails and were able to contribute when the team had more work in backend. This not only allowed the team to deliver value to the users faster, but improved teamwork and team spirit.

In the end…

Vinted’s experience can be helpful to any organisation transforming from single-platform to multi-platform product development. Different solutions fit each stage of transformation: having a separate team work on a new platform makes sense at first, but integrating that knowledge across all the organisation is best when a platform becomes mature enough.

The cross-functional team approach has its own challenges, yet most of them can be solved by integrating some sort of functional angle in the organisation - Guilds, in Vinted’s case - and an attitude open to being broader as an individual contributor

A combination of cross-functional teams and Guilds is a great base. It allows to create a consistent product experience across different platforms while continuously improving them engineering-wise.