How we trusted WeMaintain's tech team to reorganise itself

Post thumbnail

“Here’s the one and only rule: do what’s best for the company." Those were our last words before sending WeMaintain’s engineering, product and design teams on a 3 week quest to reorganise themselves. But we are getting ahead of ourselves - let me explain why.

Since it’s creation in 2017, the engineering part of WeMaintain responsible for our MobileApp, Software platform and IoT offering has grown to 30 people. With only three teams, we could work with ad-hoc communication, sometimes not-so clear responsibilities and a lot of shared ownership. With our series-B in the rear view mirror, we are now getting ready to add 30 more people in product-engineering over the next 18 months. This growth requires a reorganisation.

There are many ways to do such an exercise. On one hand, one could gather up the executive team and perform a "top-down re-teaming" behind closed doors, deciding on everyone’s fate in a matter of hours. On the other extreme, one could create a minimal set of guidelines, and trust our team to do the right thing. We chose the latter.

The process we chose went as follows:

  1. We want the new teams to be independent, each responsible for one part of the business, and empowered to do what is right. Furthermore, we want to live by the maxim: "when people are treated like adults, they behave like it." So following the semantic of the book “Team Topologies,” by Matthew Skelton and Manuel Pais, we identified four potential streams and two platforms. We spent some time making sure that the responsibility areas of those teams overlapped as little as possible. This iterative process started two weeks before the team forming workshop. It ended with a summary presentation at the beginning of the workshop.
  2. We first brainstormed as many ideas as possible for the initial team creation. For this "diverging phase," we asked everyone to enter their name and the names of as many colleagues as they wanted in all the teams they saw fit. Next, we asked everyone to highlight their first and second choices amongst all the places where they were named.
  3. Then we asked all the participants to join the breakout room corresponding to their first choice. We gave them the task to define the team's needs, skills, knowledge, responsibilities, create a first roster and make further suggestions. And there came our hint, "do what's best for the company." This iteration ended with presentations from the teams of their needs and suggestions. Everybody was welcome to comment. Then we repeated this exercise with people moving from one team to another as they deemed fit, and, at the end of this second iteration, we already had stable teams. Unfortunately, the two most important teams were a bit understaffed, putting the end of the year in jeopardy. So the teams decided to stop the workshop and develop solutions before regrouping.
  4. We met to sort and filter the proposals using Systemic-Consensing a few days later. That is a method using the resistance to a set of ideas to find the best consensus. We repeated this exercise twice and finally agreed to "disagree and commit.", acted our teams which have since started flying!

During all this time, Tristan Foureur, our Agile Coach Jean-Pierre Lambert, myself Tim Bourguignon and the rest of the leadership team only provided the framework for arriving at a decision. We also provided advice and council but only when asked for it and most importantly: we refrained from making any decisions.

What did we learn along the way? We discovered that when we treat people like adults, they indeed behave like adults. Once the team realised that we would not intervene and wouldn't say anything regarding the understaffed teams, they felt empowered and responsible. We trusted them to do what's best for the company, and they did. Sometimes it was too much even. The one time I almost jumped in was when a colleague discarded his first choice to strengthen another team. I thought it was too early for him to back off. We had not explored enough other options.

Finally, what we also discovered, is that self-organisation requires leadership. The process would have been as much self-organised but a bit less chaotic had we provided more guidance over the process from the get-go. We could have explained beforehand what the process would be and how we would conclude. Had we done that, people could have come more prepared. We might have identified the understaffing problem earlier.

Was it easy? Not at all. Would we do it again? Absolutely! The long term gains in terms of trust, openness, empowerment, ability to disagree & commit, etc. are just phenomenal.

Now here's the tricky question: should you do it? It made sense for us because we were confident our team was ready to step up to the challenge. In hindsight, I even think they wouldn't have had it any other way. But is it the case for you? Furthermore, we were ready to trust them and see it through, even if the teams decided on a structure we disagreed with. Starting the exercise, only to intervene in the middle, would be even more destructive than not doing it at all. The loss of trust it would create in your best collaborators would be tremendous. If you are in a similar situation and need to reorganise, we would encourage you to trust your teams and give it a try!

This philosophy of trust, mutual respect, empowerment and servant-leadership is what the leadership team wants for the future of WeMaintain. We want to hire stellar people, empower them, give them ownership and responsibility to do their best, provide guidance when needed, but most of all, get out of the way. This is how we see our leadership mission!

Are you interested in joining this fine crew? We are hiring in almost every role. Check out our careers page or ping me on LinkedIn.

Share the article

This could interest you

See all articles in Team
Post thumbnail
Read the article
Post thumbnail
Read the article
Post thumbnail
Read the article
You have subscribed to our newsletter, thank you!