Production at Stootie

Stootie is the first application for peer-to-peer services in France. A simple, fast and cheap solution to find a hand to fix a leak or move a sofa. We design and produce a technology platform for the general public in the form of applications (iOS, Android and Web) and private and partner APIs.

When I arrived at Stootie, I conducted an audit of this platform and confronted it to the ambitions of our CEO, Jean-Jacques Arnal.

My vision is that a company spearheading the field of collaborative economics, a field in full revolution, must be innovative in its technical field but also in its organization. We need to work together as much as possible.

My first recommendation was to make a technical pivot and to migrate the architecture of the platform towards a microservices architecture. The second recommendation was to accompany this technical pivot by an organizational pivot.

Law of Conway

First of all, it is appropriate to speak of Melvin Conway, eminent computer scientist who established the eponymous law:

Companies are organized in the same way as the software they produce

In Conway’s idea, this went quite far and we could determine by reading the code of an application, if the developer was a freelance, or if he was isolated, in the middle of chapel wars, technical or product oriented, and so on.

It also meant that if the software was buggy or malfunctioning, it could be a reflection of a bad organization.

Toward the feature teams

We relied on the contraposition of this law in the framework of its technical pivot:

In any case, we have to produce microservices, then as much organize accordingly, in micro teams

This seems trivial, but the classical paradigm of the production of a digital society is broken. We moved from:

Organization > Perimeter

To :

Perimeter > Organization

And it seems logical, how to define how to be organized if we do not know what we have to produce?

In the traditional delivery management, the company chooses to lead its project by the dates, or by the costs. Conway’s law requires leading it by the features, and by the way to get things out when they’re ready. Some companies, such as Gitlab, say they have frozen their delivery schedule for the year and what does not come out on schedule, will come out in the next delivery time slot.

This is quite aligned with Agile methodologies and more over with the DevOps philosophy.

We are not talking about organizing an IT department or small isolated team in a company. It’s a global pivot !

Spotify had already understood this in 2014 when publishing its videos on the culture of engineering (1 and 2) and proposed complementary organizational models (Squads, Tribes, Chapters, and so on.).

Their proposal, tinged with agile method, comes from what I call the “reduction of entropy”, namely the reduction of organizational complexities and constraints in favor of productivity.

Concretely, the fact of passing in feature teams had a direct impact on the teams:

  • Mixed team: the people who needs to achieve a feature are grouped together, during the whole time of the production of the feature;
  • Reduction of the hierarchy: there is no manager in the feature teams;
  • Flat working circuit: the delivery workflow is simple and standardized, leaded by the feature team;
  • Team goals rather than personal goals: if the feature team succeeds then it is the company that succeeds and therefore everyone;
  • Distinction by seniority: the evolution of the collaborators is made by the experience and the mastery of each of the competences necessary to the realization of its work.

Basic lessons

After 4 months of experimentation, we have learned the following lessons:

  • It is necessary to work on the meaning of each element of the organization, to appropriate it and to understand how it interacts with the rest of the organization;
  • The commitment of the company must be total in this organizational pivot: we organized a vote by show of hands to decide to commit the company in this adventure;
  • The product must be ahead of developments;
  • The structuring into “guilds” does not only concern the technical team, but all the teams involved in the creation of features;
  • Emergencies and bugs have their place in this model, they must be managed;
  • Everything does not fit into a feature team, typically the work of some support functions is sidelined, or some subjects that are dealt with in the long run.

The organization must serve primarily the product and is such code, it must be maintained.

We evaluate and test each ritual to understand what works and what could be improved or abandoned.

We note that the atmosphere of the company has changed a lot, a lot of work but also a lot of collaboration, even complicity. The first feedback from the team is unanimous, it is necessary to continue working in feature team.


At Stootie, as I write, we are a Series-A fundraising company and reaching the 40 people, +25 in 2016.

Should a startup organize itself in feature teams ?

The transition to the feature teams is the organizational counterpart to the transition to a microservices architecture. So, if you already planned to change your architecture, you might strongly consider organizing your company in feature teams.

Stootie takes the advantage now by organizing itself as a company that efficiently scales its agility.

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.