Team topologies in the travel and gastronomy industry

You can be a digital product organization with highly talented software engineers, it does not prevent you to progressively face delivery issues. This post explains the journey of our teams to adopt a value stream and team first approach with Team Topologies. The results are outstanding.

Team topologies in the travel and gastronomy industry

Michelin operates in the tire business. No surprise here. We're also present in the travel and hospitality market for quite a long time too. It started with the famous Michelin Guide in 1900, quickly followed with the maps in 1905. ViaMichelin, one of the first maps and itineraries solution was created in 2002. In 2018, the Michelin group acquired Tablet Hotels, a hotel booking site specialized in curating luxury and boutique hotels. The idea was to leverage Michelin Guide awareness and bring the hotel booking converting business into it.

The team delivering the digital products for Tablet Hotels was located in New York city and their scope of responsibility slowly changed from being hotel booking only to embrace the restaurant universe as well. We had to scale them to deal with that new scope and adapt its organization that was already to its limit delivery wise. While at the same time, we had to admit that we were already facing some difficulties to deliver on scope and on time.

Where we started

The historical engineering teams was organized with components teams:

  • A team in charge of the back office providing APIs and connectivity with channel managers (to get rooms availability and prices)
  • A desktop team delivering the Tablet Hotels web site
  • Mobile teams publishing the mobile apps: one for iOs and one for Android
  • And two transversal teams supporting DevOps & Quality Assurance activities

Completely separated from that organization, there was a team in charge of the Michelin Guide web site.

This organization made a perfect sense but convey couples of disadvantages:

  • a new product feature often, if not always, required to coordinate multiple component teams needed to deliver it. A project management cell was then created to handle these coordination needs.
  • there was a clear separation between product and engineering affecting the collaboration between the too. Everything had to go through project before reaching engineering.
  • two activities became bottleneck in the software delivery process: QA & DevOps.
  • the scope of work for some of these teams could be huge functionally wise. The back end team was in charge for the on-boarding process of the hotels, getting the inventory for rooms but also to deliver all APIs called by the different fronts. A a single team was contributing to multiple value streams. When you do serve multiple value streams, the prioritization between them can quickly become tricky. The extension of the scope following the Michelin acquisition amplified this problem.
  • The android team was in fact one software engineer working in India alone and too far from the rest of the team

How to adapt the organization to our new goals?

It became clear that we had to re-organize our teams but how. We quickly identified that the Team Topologies approach could make sense. Usually, you start by brainstorming on the problem you're trying to fix. As we made several diagnosis before, they were quite clear. We directly jumped on the re-redesign of the organization.

There are two main types of input you can use to start this work: a value stream or a user/customer journey. The hotel booking business is mostly a B2C business even if business travellers exist as well. You'll find below a generic and simplified customer journey for this business.

It's not a surprise if the user journey on our web site stick to it

We translated this user experience into main features linked to personas: consumer ie the users, Hotel managers for those that are not connected and need to manage their inventory manually, the Distribution team in charge of on boarding hotels that will become bookable on the platform, the customer service and the marketing team.

When you look at this schema, you start to see the teams you need. A good indicator is the persona you're addressing. Here we see a set of features directly targeting consumers: searching for available hotels for your stay, selecting the one you could book, then the room with the right options and the payment of that room (the checkout). A team named booking path will take care of this scope.

There is a pre-requisite for that to happen: you need to properly on-board hotels so we get their inventory (ie the rooms) and they can be discovered by consumers. The main persona for this scope is the hotel teams for which an inventory & rate management team was created. This team will be focused on the seller side of our marketplace: hotels.

As you can see above, the booking customer journey starts way before you actually start searching for an hotel. We have to reach customers first so they go to our platform to search and book. We also need to take care of the after booking experience to make sure the customer will be willing to book again the next time. There are two main persona here: the customer service and the marketing team. The team in charge of this scope was named customer engagement.

You can use the Wardley map tool to visualize this structure.

When you've done this exercice, applying team topologies is easy as you have identified your value streams quite naturally. Getting the inventory & rates is one while booking a room and engaging the customer are the two others. The below picture translate this work into team topologies. We decided to include the team managing the Michelin Guide web site in this organization but we have not yet decompose its value stream. The main reason is we mostly rely on a service company to deliver it and we don't want to impact their organization. Each stream aligned team gets a Product Owner and the needed staff to cover back end, front end and mobile engineering.

We haven't tackled yet the DevOps and QA topics that is why we have an enabling team supporting these two activities and collaborating with each stream value teams. You could ask yourself why? It's a tactical move to be honest. When you change a organisation that much, you try to pick your battle. Yes keeping devops and QA activities separated from the stream aligned teams is not ideal. You'll end up with a bottleneck or two at some point. We will deal with it once it happens and that makes the change management easier for the time being.

Is it working? Do we deliver faster and better?

This organisation is in place for a year and we now can share some results. We're in the process to implement the accelerate metrics so I won't be able to show the progresses through them.

More autonomy for teams as a good portion of the product features can be assigned to one team only. There are still some topics that requires to coordinate multiple teams. A good example of this is when we deployed the Hotel keys (the equivalent of the Michelin stars but for hotels): the Inventory & rate team where the Hotels are managed, the booking path to show this new attribute and the customer engagement team when they communicate on rewarded hotels. Project management is still needed but was repositioned in the product organization. While before 90% of the topics required to coordinate 2 or more teams, this ratio is now around 30%.

The below table illustrate the gain. Yes we hired more engineers accounting for 15% more workforce but comparatively we delivered more topics.

Reduced cognitive load. As the scope for a team is smaller than before, team member feels they can master it more easily. There is also a significant reduction in context switching leading to a better focus thus "productivity". Let's face it, the day to day ceremonies are also more focused then shorter and it's well appreciated.

“My scope is way more managable and I don’t always switch from one topic to the other”. (Lead back end engineer)
“Our ceremonies are way smaller & shorter” (Product Owner)”

Product may be the new bottleneck. I am bit provocative here but as engineers are more focused, don't switch between contexts etc they are faster to deliver. Now we can have issues on the product side to keep pushing work to do to engineers.

“I can’t keep up with the rhythm and keep my engineers busy” (Product Owner)

More business agility. Would we have to deliver a complete set of features that have nothing to do with the existing teams, well yes we can add a team easily. A good example would be the User Generated Content. Both Tablet Hotels & Michelin Guide are closed curation ie users can't add hotels or restaurants themselves. We don't even allow Michelin Guides to provide comments, pictures,what they like etc. All this User Generated Content concept is coming to the Guide and if needed we would be able to create a team focused on making it happening.

Final words

Ultimately, yes we deliver more value faster. We can safely say it's thanks to the changes we made on the organization but also because more people joining the engineering team. Beyond the figures, we see a team or a set of teams that perform very well, focused, in charge with people that knows what they have to do.

Unexpected things happened though.

There used to be a weekly meeting to decide or change the priority for the engineering team. It was a painful meeting where the business teams & product owners were "fighting" the engineering team and asking them to constantly change the things they were working on, and sometimes for good reasons. As the teams are smaller, more autonomous and focused, they mostly deliver faster so this meeting was changed to review the What's Important Now in a pure lean approach with red or green WINs. Successes are now shared as well as risk/issues so we can help teams to fix them.

The fact that we aligned the team organization on the value streams thus our products also helped the product owners to manage their teams using product roadmaps. And then to tight product features to business objectives and identify dependencies between features thus teams. The execution of these roadmaps is much more smooth than it was before.

We're not yet done. As we saw above, the QA and DevOps activities will have to be moved back into the stream aligned teams. The development of mobile applications is also something we're not sure about. We may create a dedicated team again on mobile as the technology is different, its rhythm of evolution too etc. But that would be for another post.

A big shoutout for the teams that not only accepted to change but embrace it. What a progress in a year. Special thank to Henry Mendez who believed in it and made it happen. Well done sir!