3 difficulties in aligning teams on product transformation goals
Written With Mark Faiers
Product transformation goals should address an important business problem for it to be worth the investment
Product transformation goals should address an important business or customer problem for teams. When they are balanced across all team types they have a meaningful impact in the long term.
TLDR
To devise product transformation goals for different teams, a thorough diagnosis of their problems is necessary. However, these goals may apply differently to each team, and there are three difficulties to overcome:
Difficulty in balancing who owns solving the immediate problem
Difficulty in balancing a stream-aligned team's priorities
Lack of appetite to adjust goals with new information
To overcome these difficulties, the team should prioritize helping other teams learn and create enough slack in the team's capacity so that they can devote time to improvements. It's also essential to spend time understanding teams' perspectives and implementing feedback loops to identify what's working and what's not. Finally, product transformation goals must consider a team's sphere of influence, interactions with other teams, and funding culture.
This article explores the challenges and dynamics of product or platform transformation goals. It sheds light on their emergence and the variations across different team types. We acknowledge the difficulty of aligning these goals. A 2022 study by Oxford University and EY finds that “67% of senior leaders have experienced at least one underperforming transformation in the last five years”. They found that people, their interactions, motivations and emotions are key components to a successful transformation. No surprise there. Therefore, we want to emphasise the importance of product transformation goals for different team types. We will use team types as elaborated in “Team Topologies” by Matthew Skelton and Manuel Pais. Jump to the end for a TL;DR.
What are Product Transformation Goals?
Any product transformation is hard. It is because it requires human behaviour change and changes to complex work systems that have previously yielded results.
And yet product transformations are a response to competitive threats, opportunities to innovate better or deliver faster. A problem in product delivery can trigger this. A customer issue can trigger this too e.g., customer churn, negative feedback, etc. A thorough diagnosis of problems plaguing the teams can help you devise the product transformation goals. However, these goals may apply differently to each team.
What Team Types are we referring to?
It helps to think of team types as defined by “Team Topologies” book by Matthew Skelton and Manuel Pais. There are 4 team types - stream aligned teams, enabling team, platform team and complicated subsystem team.
It helps because it provides a laser focus on goals for each team type.
A stream aligned team focuses on customer outcomes end to end
Platform teams and complicated subsystem teams focus on reducing cognitive load for a stream aligned team or a platform team
An enabling team focuses on improving skill sets for other teams
Most team types (except for stream aligned teams) have other teams and colleagues as customers.
Why is it so difficult to align Product Transformation Goals across Team Types?
Product transformations involve a combination of team types above. At the very least - an enabling team and stream aligned or platform team. Clarifying goals for an enabling team is tricky. It is tricky because an enabling team is usually transient in nature. Clarifying product transformation goals is pivotal to transformation success.
To reiterate, an enabling team focuses on improving skill sets for other teams. There are 3 difficulties in the context of this goal.
1st difficulty is balancing who owns solving the immediate problem - “enabling team” or “stream aligned team”. If all the problem solving is part of “Enabling team” goals, when that team disbands problems will start appearing again. The sooner the stream-aligned team learns to practise solving the problem themselves - the better for the enabling team. Product transformation without this balance is incomplete. This difficulty further stems from
lack of trust in the stream-aligned team to solve the problem at hand
lack of time and safety in letting the stream-aligned team try different things and maybe fail a few times
The 2nd difficulty is in balancing a stream-aligned team’s priorities. They are juggling customer outcomes, business outcomes and their own improvement.
The 3rd difficulty is that transformation goals do not adjust to new information in the environment. Examples of information are 1) what is the problem understanding across teams 2) what is the data around hypothesis that is forming to solve the problem, etc.
So how to navigate these 3 difficulties?
Addressing the 1st difficulty, balancing who owns solving the immediate problem - “enabling team” or “stream aligned team”.
There is a good amount of research in the last 5 years focussed on what is the best way to learn at work. A lot of these conclude - that an effective way for knowledge workers to learn is “to learn in the daily flow of work”. This HBR article from 2019 is a great start to delve into this topic.
Therefore, “enabling team” goals should weigh towards helping other teams to learn and discover problems and solutions as part of teams daily work. This is a proven way for long term business impact. “Enabling team” can guide others. Once 1 stream aligned team or platform team solves the problem, this can trigger knowledge sharing across teams which further scales learning.
For this to happen effectively the focus needs to be on the long-term. Too many stream-aligned teams focus only on the short term and most immediate problems they face, for example the goals of the current sprint, or the next feature they need to deliver. This is where technical debt increases, making change all the more difficult to achieve. It is important that conflicts between long-term and short-term goals are explicitly acknowledged. The emphasis is put on goals that will benefit the stream-aligned team in the long-term.
Addressing the 2nd difficulty, balancing a stream-aligned team’s priorities.
Product transformation goals should address an important problem for the business and teams. If transformation opportunity is not important or urgent for the teams to act on, it probably does not align with business goals. Enabling teams should advise against the transformation if it isn’t aligned. This is an important role of an enabling team, whether internal, or external. It it’s not important, stream aligned team will not practice the improvement as part of it’s daily work.
This might conflict with making improvements in a safe way. But it doesn’t have to. Its a balancing act. This can be achieved by
trying the improvements in a lower stake environment first so that failure impact radius is small
supporting the team trying out the improvements with enough slack in their capacity so that they can devote time to improvements
having long-lived stream-aligned teams so that long-term learning is sticky
An example of this could be - your teams have identified that continuous delivery requires significant improvement. By improving this, teams will be able to release independently, serve their customers better and thereby improve - customer acquisition and retention. However, the leadership has picked a lower stake customer service team first to try out the improvements. This way even if the team fails in its first attempt, their lessons can be valuable and with a smaller impact radius.
We appreciate that 1st difficulty and 2nd difficulty are sometimes at odds with each other. It is a real challenge.
Addressing the 3rd difficulty, transformation goals do not adjust to new information in the environment.
Be open to which teams could play a key role in transformation goals. Spend time to understand various teams’ perspective of problems and its impact on their goals. This creates room to explore and adjust goals for all teams involved. This is an iterative process.
It is vital to build in feedback loops to the transformation. Feedback loops provide a mechanism for identifying what is working, or going well in the transformation, and what is not. Products should, and generally are, transformed iteratively thus providing natural points to gain feedback and act on that to adjust goals where needed.
Do Product transformation goals exist in isolation?
Of course not. Referring to “Team Topologies” again by Matthew Skelton and Manuel Pais, team topologies are heavily influenced by the following factors. These factors influence product transformation goals too.
One key factor is the team’s sphere of influence due to a fracture plane. According to team topologies - “A fracture plane is a natural seam in the software system that allows the system to be split easily into two or more parts.”
An example of fracture plane is business domain. Separate business domains drive separation of teams. This will imply the sphere of influence for each team may be limited by that business domain. And hence, transformation goals will be dictated by business domain. Let's take examples of personal insurance products. A motor insurance business domain is different to a life insurance business domain. This is because the risk calculations and inputs in each type of insurance will be different. Both journeys share the same payment domain. So we have at least 3 team types - motor insurance team, life insurance team, payments team. The product transformation goals for each of these 3 teams will be different.
Another key factor is team interaction modes. According to team topologies - “...three core team interaction modes simplify and clarify the essential interactions needed between teams building software systems: collaboration, X-as-a-Service, and facilitation”. Team interaction modes have a direct impact on teams' product transformation goals.
As an example, if team A is consuming automated service from team B. And team B is experimenting with a transformation. Team A will experience peaks and troughs in the quality of the service depending on how the transformation performs. Let's say, if both teams A and B want to simplify user experience. They might want to explore together. They might want to undertake user research as part of this exercise. Hence this transformation will be part of both team’s goals.
Other factors:
A team’s ability to sense problems: This is important because it changes how impactful the goals might be for the business
Funding culture: If funding for improvements is an annual exercise and not part of usual budgets, then there is no room for adapting to changing team and problem landscape