Our next iteration was to build cross-functional teams. We had a hypothesis that in creating cross-functional teams, we would improve:

  • Customer experience
  • Ownership
  • Velocity
  • Collaboration
  • Focus

Our first focus was to sit people together (i.e. Testers, Engineers, Agile Leads and BAs) to improve collaboration and ways of working, as we strongly recognised that face time is really underestimated in creating high-performing teams and increasing focus.

The next major change for us was to merge our Front End and ISE organisations to create one Engineering function, and also start to embed more roles into cross-functional teams, such as Product Owners, Web Analysts and UX.

The Front End organisation had been running the concept of Product teams for a number of years but they were more like feature crews than true product teams – mainly because they didn’t own the full slice of what they were doing.

Future Customer Journey Project

As a business, we recognised that we needed to shift our business to a much deeper product-orientated organisation. With that in mind, we started a small working cross-functional group on a project called the Future Customer Journey.

The project had a few critical goals:

  • Create a recommendation for a customer-focused Product Organisation.
  • Restructure all product teams around domain-based teams.
  • Ensure other roles, such as Commercial Analysts, are really included in the Product teams.

This was no small feat. It took us several months to look at our ways of working, and we took inputs from our Front End team, RAD framework, experience in the industry and customer analysis. We considered moving to a more tribe-based model like Spotify and other businesses. However, we decided to take the best pieces from industry that we knew at the time, smash it together and start to test and learn on some concepts that were tailored to BookingGo, whilst heavily adopting an Agile culture and decentralised autonomous teams.

Overview of Product Group set-up

As a result, we created a new organisation called the Customer Experience Group, which was a partnership with Product and Engineering. We organised ourselves into Product groups, each one a collection of Product teams focused on a similar theme or grouping.

We moved Product teams to have sole ownership of functional areas, components or systems. In some cases, such as our web stack, this wasn’t totally possible at the time due to the technology, but we are on the journey to create a decoupled domain-based Service-Oriented Architecture, which will be covered in future posts. We also had a view that platform teams didn’t have the customer at the heart of their focus. Each of the teams was cross-functional (as you’d expect from the context we’ve already set out) and at its core had the following disciplines:


Leading our Product groups were Senior Product Owners and Software Engineering Managers. The full complement of roles looked like this:


At the time of this change, we also decided to shift Business Analysts to be more Product-focused, so they transitioned towards being Product Owners. Our view was that each Product Owner would be a combination of Product Manager and Business Analyst. Product Owners would be accountable for shaping requirements with the team, owning the product backlog and managing stakeholders.

Another key change was a shift to Agile Coaches from Agile Leads, which was part of our goal to move towards servant leadership, but also iterating on our approach to Agile. I will talk more about Agile Coaches shortly.

One interesting part of the Product groups that we continue to evolve today is the supporting roles:

  • Analyst, both Commercial and Web
  • Architect
  • Agile Coach
  • UX Lead

As a result of the shift to Product groups, we formed 10 Product groups, really focused around the customer journey through the booking experience, from customer acquisition at the front of the booking funnel through to customer payments, through to contact centre and data & reporting. Our hypothesis: by creating Product groups and teams with a real focus on customers, we were looking to achieve our first goal of cross-functional teams: to create a better customer experience.

In our quest to organise Product teams around domain boundaries, another very subtle but hugely important part of this shift was the fact that it started laying the foundations for our future technology platforms. Rather than ‘modernise first; reorganise later’, we reorganised first. Our hypothesis for doing this was that it would improve ownership and longevity of our future technology, as well as enabling organic modernisation because teams were organised around the products.

The Future Customer Journey Project launched in September 2016. Like all major change programmes, it’s taking time to adopt and roll out, but it has really created the thumbprint for our business for the future. We now have a Product-based organisation: it still needs to mature (as is always the case) but we are set up for the future.

We will share more around our Product evolution in a separate set of blogs.

Servant leadership & Agile Coaches

As I mentioned earlier, in relation to introducing Agile Coaches, we were aiming to be one of the best Agile communities out there, so we would need to be ambitious with our plans. As part of the Future Customer Journey, we trained all our Product Owners and Engineering Leaders in Scrum to give them a basic understanding of Agile and let the teams start to embed Agile ways of working into the team. Still a lot of work to do here with the culture and delivery ownership, but a great step forward.

You may have spotted that we don’t call our teams cross-functional Agile teams. We started out with this, but quickly learnt that it became a battle of Scrum vs Kanban vs XP vs anything else, so we dropped the word Agile and instead changed our language to ‘cross-functional collaborative teams that deliver’. We don’t care what the framework is as long as the team deliver. However, we do care that they have some basics in place, such as:

  • Stand-ups
  • Retros
  • Backlogs
  • Feedback loops
  • A regular cadence for reflection: for example, 2 cycle

We don’t have dedicated scrum masters in the team: we asked the teams to self-organise in terms of who will lead, who will unblock things, etc. We also clarified accountabilities for Product Owners and Engineers. The hypothesis here was to create highly autonomous teams, which a lot of people found quite difficult at first, as they naturally expected the people at the top to tell them what to do or at least provide guidance. We’re aiming to shift more to a Servant Leadership model, where our leaders are enablers to the team. Whilst it takes a shift in culture, people and mindset, this is the journey we are on today.

While we were making this change, we recognised that teams need help and support with Agile, so we shifted our Agile Leads to Agile Coaches and they took up the role of supporting and coaching the teams with their ways of working. We introduced maturity models to enable self-assessments and let the team reflect on their capability.

We are still iterating on our approach with Agile Coaches as some teams need more support from a delivery perspective, but it’s something we will continue to iterate on and learn.


Thanks for reading this part of the blog series. I hope you see the huge shift BookingGo has made over the last few years in our evolution. We aren’t done yet, but the progress towards our end goal is a huge testament to the determination of our business and everyone involved.

A lot of our ways of working has been focused around organisation, so the change can naturally evolve and iterate.