2021 · BT

Redesigning an organisation to become more user-centric at BT

Product design, organisational design, stakeholder management, budget management

People are continuously expectant of great digital experiences and the standard for those experiences is constantly being pushed beyond its limits with companies like Netflix, Amazon, Spotify, and more investing huge sums of money into their products so that their customers never feel the reason to leave their service.

These high expectations are now commonplace and mean that it is even more critical for organisations (both large and small) to provide products and services that are simultaneously easy to use, solve genuine needs, and can help make lives easier. Without this customer-centric view when building digital experiences, organisations cannot hope to stay relevant and compete in the ever-changing landscape of a digital economy.

For a company like BT and EE, this is no different. With over 45 million customers (combined BT and EE), goals, and needs change frequently and it’s up to us to continuously meet those new demands and try to exceed them where possible.

In order for us to keep doing this, we need to continually improve on the way our organisation is structured.

The challenge is that our customers view our services as one singular journey, indifferent to the department or team(s) that are involved in designing and building that service. So, to ensure our teams are more focused on customer goals and less on platform technology and product features (as they are today) we needed to better organise ourselves around our customer lifecycle model.

To do this, we decided to lean on the LBGUPS (learn, buy, get, use, pay, support) framework.

Taking a service design approach to our organisational re-design using the LBGUPS framework

The LBGUPS (Learn, buy, get, use, pay & support) framework gives us a very high-level view of the various stages and touchpoints that a customer will experience during their journey as well as the ability to evolve the way we organise our people by mapping our existing alliances against each step in the journey, and sharpen our squads’ focus on the things users need to do from initially learning about us and our services, to buying them, using them and any support they might need before finally reconsidering their relationship with us (beginning this lifecycle again) or leaving us.

Mapping our existing alliance to the LBGUPS framework

My focus throughout this re-design of our organisation was on the My account alliance.

The My account alliance is one of the largest and most complex in BT and EE and accommodates roughly 200 people. Our alliance is accountable for customer journeys that include changing your settings and marketing preferences, checking your data usage (phone or broadband), buying an add-on (Now TV pass), and controlling your costs (setting up direct debits).

With this range of customer goals in mind, it seemed fitting that our alliance would connect to the use and pay steps in the LBGUPS Framework, and just like that, we were transformed into the UP alliance.

Each alliance also consists of what we call an ALT (Alliance leadership Team) where I represent Product Design. ALTs are a cross-functional group of discipline leaders who are jointly accountable and responsible for the alliance’s performance and wellbeing. It was our responsibility as an ALT to collaboratively create an organisational model that would enable our squads to design more focused customer-centric journeys.

Week 1: Establishing our objectives & principles for change

Our first priority as an ALT was to reach out to each squad in our alliance and understand how people were feeling and listen to any ideas they might have. It was important to develop a shared understanding of why we were about to make changes and how this might impact our current way of working.

During week 1, I hosted an all-day virtual workshop where the ALT and a diverse group of product, engineering, and design leads from our existing tribes established our principles for change, the risks we’d likely encounter, and our objectives for this organisational re-design.

Our principles for change:

πŸ‘‰ Squads need to be more focused on end-to-end journeys and customer goals and less fixated on platforms and products.

πŸ‘‰ Each squad needs dedicated engineering resources to empower them to deliver in a continuous iterative cycle instead of using pooled resource when demand appears.

πŸ‘‰ If we can, squads need to be brand agnostic (across BT and EE) and share research insights across similar problems that we’re trying to solve so that we can avoid duplication of effort.

Our areas of risk:

πŸ‘‰ We’re not sure if we have the right skills or brand knowledge across design (product and content) to support platform and/or brand agnostic squads.

πŸ‘‰ Combined platform and/or brand agnostic squads would be too large (20 + people) and too much work for one single Product Owner (or Designer) to manage.

πŸ‘‰ Each brand (BT and EE) has very different tech stacks and will require an enormous amount of onboarding and learning for our engineers β€” this might impact our squad velocity.

Our objectives:

πŸ‘‰ Increase volume and share in our digital channels.

πŸ‘‰ Exceptional customer experiences that will generate better CSAT, NPS, conversion and task completion rate.

πŸ‘‰ A continuous iterative approach to our organisational re-design where feedback is shared freely so that we can adapt when necessary.

Week 2: Defining customer goals for our alliance

In week 2 we ran a number of virtual workshops together with our alliance leads to try and establish all of the customer needs we could think of across Use and Pay. We then prioritised these needs, grouped them into themes, and passed them through our customer goal engine.

The customer goal engine (that you can see below) is a simple tool that asked 3 simple questions about the need that you had identified with an easy-to-follow β€˜yes’ or β€˜no’ track. The purpose of this exercise was to generate a comprehensive list of customer goals across the UP alliance that we could group and use to form the skeleton of the squads we’d need to stand up.

Week 3: Ideation

The following week, we broke out into separate, cross-functional groups in an attempt to generate some ideas that might work whilst considering the various constraints (tech and budget) that we had previously established.

Here are some of the ideas we discussed:

1. A multi-tribe support squad

This squad would be responsible for managing release cadence, iOS/Android fixes and updates, merging and rejecting pull requests across the alliance, and monitoring the standard of code across our engineering team.

Opportunities:

πŸ‘‰ Alleviates these responsibilities from our product squad engineers and enables them to focus solely on delivering against their sprint goal(s).

πŸ‘‰ Ensures that the products we build are both secure, flexible, and accessible to other engineers who might need to clone it in the future.

πŸ‘‰ Theoretically, with more people and more a more considered governance process, this squad could be expanded across the department managing code across our entire digital department.

Risks:

πŸ‘‰ We currently don’t have enough senior engineers to staff this squad so we’d need to embark on a recruitment drive to ensure we get the right people in place β€” this could be costly and take a lot of time.

πŸ‘‰ A governance process for merging and rejecting new code is currently unique to each squad and there is no standard way of doing this across the alliance. Setting this unified governance process will take time and may impact the velocity of our product squads in the short term.

Verdict

πŸ‘ We loved the flexibility that this squad would give us and the freedom it’d give our squad engineers so this was an idea we wanted to include in our final proposals.

2. A special projects squad

A solution that highlights the imperfections of the LBGUPS framework but nevertheless gives us the opportunity to potentially pivot where necessary and explore unique customer problems that could fall between the gaps of the LBGUPS framework.

Opportunities:

πŸ‘‰ Covers a broader range of customer goals that don’t necessarily fit within the LBGUPS framework.

πŸ‘‰ Supplements existing product squads to cover holidays or absence if needed.

πŸ‘‰ Helps our existing product squads to conduct more long-form qualitative research that could help us uncover more in-depth customer insights.

Risks:

πŸ‘‰ Becomes abstracted from the alliance and our existing product squads.

πŸ‘‰ This isolation and possible lack of communication could unknowingly lead to duplication of effort.

πŸ‘‰ Continues to encourage us to think about our products as projects and not the other way around.

Verdict:

πŸ‘Ž We felt that this idea didn’t fit within the LBGUPS framework and would have become too abstracted from the rest of the squads in our alliance.

3. Platform & Brand agnostic squads

Customer journeys across BT and EE really aren’t that dissimilar. On the face of it, both brands offer our customers broadband, mobile, and TV packages with varying price points and perks yet the customer goals across each are almost identical.

Removing the brand from the experience we’re designing for brings us closer to one single system of design, engineering, and product that can scale seamlessly.

Opportunities:

πŸ‘‰ Avoids duplication in effort across design, product, and engineering.

πŸ‘‰ Allows for better alignment and communication across the squad.

πŸ‘‰ Greater flexibility to move people to different squads in any alliance as we’ll have more common ways of working between squads.

Risks:

πŸ‘‰ Onboarding engineers to new tech stacks will take some time and that may subsequently impact velocity in our sprints.

πŸ‘‰ Managing such large backlogs that involve so many stakeholders across multiple brands is a lot to ask of one squad.

πŸ‘‰ Squad sizes might become unmanageable considering we need enough engineers to develop solutions for both BT and EE, web and app.

Verdict:

πŸ‘Ž This felt like too much of a departure from our current way of working and would have required a long period of onboarding new tech stacks across both BT and EE for our engineers.

Week 4: Defining our alliance model

Now it was time to combine our ideas into one that we could trial and adapt when necessary.

Here’s what we committed to:

Opportunities:

πŸ‘‰ Our squads have a clear and focused view on the customer goals they are designing for.

πŸ‘‰ A separate multi-tribe support squad can help us manage pull requests, define release cadence, and iOS/Android maintenance for the entire alliance enabling squad engineers to dedicate all of their time to each sprint.

πŸ‘‰ We won’t lose domain knowledge (tech stacks and stakeholders) as our squads will remain brand-specific (for the time being).

Risks:

πŸ‘‰ How do we effectively communicate the opportunities, risks, and differences to our existing way of working?

πŸ‘‰ Recruitment for new roles that we need to recruit for in this model could take more time than we anticipated and delay day zero activities for a number of squads.

πŸ‘‰ People will take time getting used to this new way of working and may initially impact the velocity for our squads.

Measuring the impact of our changes

We decided to measure the success of our changes against 3 different pillars:

1. Positive impact on our customer experience. We’d measure journey CSAT, NPS, and also task completion rates (change of settings, buying an addon, paying a bill, or setting up a direct debit).

2. A convincing majority of positive feedback (observed through squad or alliance retros and bi-annual employee surveys) from our people about ways of working.

3. Velocity in sprints would eventually (2–4 months) recover and exceed our previous velocity rates.

Early reflections

As I’m writing the last few paragraphs of this article, we are just 3 days into our new alliance model.

My advice to anyone reading this who might also be in the process of making large-scale changes to their team is to over-communicate.

I think we (the ALT) overestimated how much we needed to share our WIP (not always possible when we were managing sensitive information) with everyone in the alliance and give them a sense of ownership over the changes we were proposing. This is by no means an easy task but can be easily be overlooked when things are somewhat chaotic, deadlines are fast approaching and there are so many people to consider.

Regardless, it’s important to remember that change can be unsettling for you and your team so you’ll need to make even more effort than you might have done so already to reach out to the people around you and talk to them! Actively listening to any ideas, feedback or concerns will make them feel at ease and far more likely to commit and ultimately be accountable for the changes that are happening around them.