Refurbishing our tech team’s organizational structure.

Today we tackle one of Back Market’s most relevant concerns: properly scaling our technical team AKA the Bureau of Technology.

At Back Market, we strongly believe that it’s time to offer a mainstream alternative to new products, by making existing used devices more appealing to potential customers, and fight against the exponential production of electronic waste and planned obsolescence. #HereToStay

Along with our journey, we often face questions about the best way to build our marketplace and how to scale it.


When talking about agility, velocity, time to market reduction and so on, a lot of actions can be taken. It is almost impossible to define the number of methods, tools, frameworks etc. trying to answer these multiple questions.

But clearly, one of the main topics to consider is the organizational structure itself. That’s what we decided to work on first at Back Market.

In a few months, our Bureau of Technology (i.e. the BoT, our tech team composed of backend / frontend developers, architects, devops, QA, Product Owners, UX designers etc.) has quickly grown, going from 9 to 36 people in one year. Unsurprisingly, we came to a phase where our team operations seemed to become less and less efficient.

With the company growing so strongly, we decided that it was the right time to review the overall organization of our tech team.

Today, we can say that it was just the beginning of a long journey. A long and difficult road ahead, but an interesting one: refurbishing the BoT!


When did we decide to change the team structure ?

For us, the situation started about nine months ago (January 2018).

It was necessary to quickly address the organizational structure when we began to see that a lot of changes were happening in the BoT. We have identified the specific triggers that led us to begin this journey over a fairly short period of time:

The rest of the organization grew just as quickly (and even more than the technical team).

We had the chance to see the Back Market team grow a lot over a short period of time. In one year we went from 27 to 130 people. The BoT grew, but it wasn’t alone — the other departments hired and grew aggressively.

In a very schematic way, more people = a lot more ideas = an exponentially growing development load.

The initial organization of the team stopped working.

At first, our technical team was classically organized into two poles: the backend and the frontend. It’s a perfectly logical structure for a certain period.

Over time, with a growing team and newly emerging expertise, a malfunction appeared: a rift was created between our backend and frontend devs. Some of our development became more difficult to coordinate, and we lost more and more time trying to correct the oversights created by this lack of exchange.

There was a tangible change in our ability to produce.

When Back Market first started, it was not uncommon for a feature expressed in the morning to be shipped the same evening. This situation was no longer possible because the number of subjects to be treated no longer allowed this flexibility.

Also, a more comprehensive prioritization frame had been introduced that no longer allowing us to manage all topics on the go. Obviously, with the evolution of the team, newcomers did not have the entire historical knowledge of all the technical aspects of Back Market, and could not have the same responsiveness (at least not right away).


How to proceed

There is no perfect or turnkey method. On our side, with our knowledge of certain methods, we decided to adopt a collaborative approach.

Concretely, we started by getting some fresh air with our team. We left the office for a whole day to meet all together and to try to define the future of our team.

So many beautiful BoT people ❤

Alternating presentations, innovation games, and group talks, we discussed the following topics:

The state of our team

Kind of an overall retrospective of our team’s health (in a nutshell, we arrived at the observations and triggers above).

Our teams’ populations and their mindsets

We worked on identifying the groups of people composing our BoT. Typically, we went further than “Front Devs”, “Product Owners” etc. We looked for logical groupings, based on common behaviors and expectations (e.g. “The OGs”, “Tech Leads”, “Neo Backend Devs” etc.).

With this exercise, the goal was to analyze the strengths and weaknesses of each group, in order to define the overall status of the team.

Our vision of a product-oriented organizational structure

We had already talked about the Feature Team notion together. Taking this further and to ensure that everyone was on the same page, we had a conversation about our vision of organizing around squads (value creation, user-centric, autonomous, with diverse expertise, aiming at improving the technical objectives etc.).

Functional perimeters possible for Back Market

To make our vision more concrete, we worked on the notion of functional division. To illustrate this, we presented some examples (including the most famous, from Spotify) before working on a proposal to split the Back Market product.

And you know what? We actually managed to define a first version of this perimeter division, giving us 7 potential squads!


Our first move: the Bossa Nova experiment

With regard to this exercise and the number of people in our team to date, we decided not to start a real Feature Team-based structure. At this time, even if the team is growing, it is not feasible to create multidisciplinary teams (Dev, PO, UX etc.) that are able to work independently.

This is why we decided to create an hybrid structure that we named Bossa Nova.

This is not Bossa Nova dance

How Bossa Nova works?

The two main principles of this structure were:

  • Start a first team feature. As the Feature Team structure was clearly our long-term goal, we felt it was necessary to start at least one squad. We decided to start a team where the risk would be limited. Limited because, on one of our functional perimeters, we already had several people wanting to work together (devs and a PO), a defined backlog full of critical topics and some strong stakeholders able to work effectively with a tech team. All the basic ingredients were there to give it a try ;-)
  • Create several batch teams. We were in love with the organizational methods used at Basecamp (see this wonderful article by Jason Fried). In summary, the team is divided in small batches (dealing small topics that can be achieved in few days) and big batches (working on a large subject requiring a larger workload) during a 6-week cycle. We decided to give it a try and separated the team with a plan to rotate people every cycle.

What have we learned from Bossa Nova so far?

Experimenting with our Bossa Nova structure for a few months, we learned a lot. In broad strokes:

  • The feature team was a success. Although the launch was not easy (finding an operational mode, promoting autonomy, defining team rites etc.), the squad was clearly a success. Very quickly, the team has gained velocity, people’s expertise clearly increased, and communication with stakeholders became much more fluid (especially thanks to a daily exchange and Agile rites as the demo and retrospective).
  • Structuring in batch was effective... Thanks to the big batches, we managed to ship some key topics for the company that would have been really difficult to deal with using our previous system of organization. The small batches also allowed us to develop a large number of product topics on our various interfaces.
  • … but did not fully correspond to the way we function. One of the organization principles presented by basecamp were to create batches not exceeding 3 people. With the increasing number of developers in our team, we have not respected this rule (shame on us). And it’s from this precise moment (when we started to have 6 or 7 devs within a team) that Bossa Nova lost its effectiveness for us. It was indeed more and more difficult to manage 6-week cycles with too many people.

Following this experiment and the insights we learned, we decided to move on for good to a squad based model, working on the foundation we had set up with our first team feature.


Where we are today: Squad

Six months after the beginning of this exercise, we launched a new collaborative session to finalize and initiate our new structure.

We started from the model presented by Spotify, but we tweaked it in order it to make it more compatible with our habits and our team’s dynamic.

First, we decided to define two types of Squads:

  • Feature Teams (organized around a user-centric functionality and delivering functional value)
  • Component Teams (autonomous team organized around a specific technical system used by other teams).

Finally, we defined all the squads that today make up our Bureau of Technology:

Six amazing feature teams

  • ⛵ Navigation & Search - In charge of managing all topics related to the discovery of our wonderful products. The team’s mission is to manage all our navigation tools, administration and search experience, personalization and contextualization modules, etc.
  • 📦 Bucks & Shipping - Beautiful people that deal one of the most difficult topic of every e-commerce website : the complete finalization cycle of an order. They aim to define and improve our payment strategy, optimize conversion, improve fraud management, manage purchase options (insurance, delivery methods).
  • 👨‍💼 Merchant’s Journey - As a marketplace, the relationship with our merchants is one of our business pillars. So we decided to create a squad in charge of managing their entire life cycle and tools. This team must manage their on-boarding, their integration and they also create and implement tools and interfaces designed to help merchants on a daily basis.
  • 📒 Catalog - Squad aiming to manage all the elements related to our products (yes, because a marketplace without product is like a bakery without chocolatine). From their administration (how to optimize the ease and the speed of publication of our catalogs) to helping customers understanding (product attributes, categorization etc.), products are the babies of this team.
  • 🛒 Customer Satisfaction - The team most connected to the other pillar of our model: our final customers. Managing their entire post purchase cycle, this squad is in charge of all interfaces related to orders, customer service claims, and all the tools for expressing customer satisfaction (note: this is our beloved first feature team ❤).
  • ❤️ Growth & Love - Because Back Market is all about love, this team aims to spread the word and make more and more people discover our offer. They Manage all topics related to SEO, CRM and sponsorship. It is also this team that is in charge of the creation of operations bringing traffic (contests, games, dedicated pages for our partners etc.) as well as insurance and educational content.

Three state of the art component teams

  • 🏛 Core team - Where technical magic happens. They are in charge of defining and carrying the technical vision of the firm. They ensures and guarantee the transverse coherence, the respect of development and security standards. They are our technical references that validate and arbitrate every critical technical choices. They are also accelerators for the other teams, as they ensure their technical autonomy.
  • 📱 Mobile team - A company selling smartphones without a dedicated team working on the mobile → impossible :) They are in charge of creating and managing the entire Back Market mobile presence. Beginning with our first application (coming soon!), this squad ensures that all our activities are present on mobile in the future. In few months, we already consider spreading all the mobile devs in the various feature teams to bring 100% autonomy.
  • 📊 Data team - It was relevant for us to create a data team. We have everything to do here, exploring data, cleaning it etc. They are managing the dataset — launching our data pipeline, creating a data lake & a data warehouse. Also, they are training our different machine learning models. As for the mobile team, the data is going to be split into the different feature teams afterwards.

No Pain, No Gain

Here we are! Even though the process has been long, sometimes complicated and not perfect yet, we are very satisfied with the current state of our restructured organization.

Keep in mind, this configuration is not carved in stone, and we might even say that we are only at the MVP stage. With the arrival of new people and new expertise, we want to continue to iterate and optimize this operation to ensure that our BoT evolves in the best possible conditions.

We hope you’ve liked this post, don’t hesitate to share how your tech team is structured too! Oh, and if you want to join our Bureau of Technology or any other Back Market department, take a look here, we’re hiring

The Bot, with ღ