Ask the Community: How Do You Shift From Functional Teams to Value-Driven Teams?

When an organization shifts from delivery or feature teams to product teams, the first step is often a change to team structure.

Delivery and feature teams are often structured by function—front-end teams, back-end teams, mobile teams, etc. These teams can rarely deliver value on their own. Instead, they hand off work from team to team—the back-end engineers design the data model and system architecture, the front-end engineers build the interface elements, the mobile engineers work toward feature parity, etc.

The challenge with this way of working is that it is both slow and constraining. It’s easy for a back-end team to make decisions that limit what’s possible in the front-end. Feature parity across desktop and mobile is rarely what customers need or want.

If an organization wants to shift to product teams—teams empowered to drive outcomes—they need to structure their teams such that each team includes the necessary skills and abilities required to build and deliver customer value. This type of team might include a back-end engineer, a front-end engineer, a mobile engineer, and/or any number of full-stack engineers.

If an organization wants to shift to product teams (empowered to drive outcomes) they need to structure them so each team includes the necessary skills and abilities required to build and deliver customer value. – Tweet This

So what happens when you want to make the switch from one type of team to the other?

This was a question that recently came up in the Continuous Discovery Habits community, where one member was wondering about how to make this transition as smoothly as possible.

For this post, we’ll share both advice from the community as well as Teresa’s suggestions on how to best handle this situation.

Question: What advice do you have for companies moving from functional teams to value-driven, cross-functional squads?

This question came from Joel Beverley, Co-founder at RotaCloud, who explained that his company is looking to restructure from platform teams (e.g. back-end, web front-end, and mobile front-end) to squads. Joel turned to the community to see if anyone had any tips or advice on introducing these changes or any pitfalls to watch out for.

Sam Lightowler’s Advice: Use a Diagram to Demonstrate Value

Meet Sam Lightowler, Senior Manager of OTT Operations at Canadian Broadcasting Corporation.

Sam Lightowler, Senior Manager of OTT Operations at Canadian Broadcasting Corporation (CBC) stepped in to share her experience.

A little background on Sam and her organization: Sam oversees the four product teams that manage two streaming services, ICI TOU.TV and CBC Gem. These were previously two completely separate sets of products managed by separate French and English arms of the organization.

• Empowered product teams that own their outcomes, can measure the value they are delivering, and can autonomously deliver features with minimal dependencies and coordination with other teams.
• Having product teams become subject matter experts on audience patterns and behavior as it pertains to their portion of the overall product/user experience.
• Maintaining feature parity across as many of their platforms as possible.

We wanted empowered product teams that own their outcomes, can measure the value they are delivering, and can autonomously deliver features with minimal dependencies and coordination with other teams. – Tweet This

Sam says this transition at CBC involved about 50 people being reorganized into cross-functional product teams. “Creating four product teams comprising front-end, back-end, iOS, and Android developers made all of the above possible,” says Sam. “Each team has a clear mission and will have distinct product outcomes (I’m only on week three of the Defining Outcomes course, so this part is a work in progress!).”

They received a lot of pushback from the engineers initially because it created complexities around code reviews, tech debt management, release processes, etc. and it created confusion for the lead devs with regards to how they would participate in the teams. “Now that we are almost ten months in, most of those challenges have been resolved,” says Sam.

Sam found it really helpful to use a diagram to demonstrate the benefits to them.

Sam created a diagram to help demonstrate the benefits of organizing teams by value stream as opposed to code base. Click the image to see a larger version.

The top diagram is how the team was structured to complete the technology transformation project mentioned earlier. The diagram on the top left illustrates what it would look like without the Program Manager/Product Managers.

In reality, Sam says they had what’s depicted on the top right—one program manager, two product managers, and several project managers at the top coordinating all of the scope and dependencies. The teams in this case were essentially focused on a list of prioritized and well-defined outputs.

When the project was completed, they moved people into cross-functional product teams so that they could empower the teams to focus on core aspects of their audience experience and more easily maintain parity across all of the platforms they support. Sam explains, “It introduced several new challenges, but the purpose of me creating this diagram was to help illustrate that they gain empowerment and a lot of autonomy—though it does make the release process more complicated.”

Creating a diagram helped illustrate that value-driven teams gain empowerment and a lot of autonomy—though it does make the release process more complicated. – Tweet This

Sam says POs struggled initially to help the teams plan across the different functions because teams were used to project managers defining their work for them: “It took time to transition to a more self-organized team, but it’s working well now!”

Himanshu Swaroop’s Advice: Get Everyone on the Same Page with Clear Strategy and Tactics

Meet Himanshu Swaroop, Transformation Consultant.

Himanshu Swaroop, a Transformation Consultant, shared his experience as an advisor at an insurance client where teams used to be set up based on functions. The company was facing several problems with their old approach. “They had a clunky old half-baked journey—half online, half on the phone, and it received very poor customer feedback. It was also very expensive for them to run, so they wanted a simpler online journey that would delight the customer,” explains Himanshu.

The company decided to set up a new multi-functional team to build a new online claims journey. The new team was a group of about ten people, some who had moved roles from their old teams and some who were new hires across design and engineering.

Himanshu calls out a few of the things that went well while setting up this new team.

They started with a clear product strategy, aligning on the top customer problems they wanted to focus on in the first six months.

They enhanced their collaboration through a design sprint. In the first few weeks, the team made a false start, forming around previous functional expertise. “This didn’t jump-start any collaboration,” says Himanshu.

After a few weeks of spinning their wheels, they realized the engineers still had no idea of the what and why of the features that had been selected to build. To jump-start collaboration, they held a design sprint with a designer, domain expert/business analyst, front-end engineer, and back-end engineer to corroborate the desirability and usability of some of the features with early customer feedback. This forced the participants to understand the customer opportunity in more detail. They uncovered new assumptions as well as architecture constraints. The participants came out of the exercise better aligned and improved their future collaboration.

They became more intentional about the new joiners’ onboarding journey to ensure anyone who joined the team was brought up to speed on their approach to cross-functional collaboration. For example, they held pair programming sessions and domain experts would lead “lunch and learns” to explain the business, customer context, and product strategy.

They ran early usability testing to validate the team’s direction. “Design and user research combined to do testing on early prototypes which improved confidence in the team’s direction,” says Himanshu.

And finally, the engineering team identified early that delivery pipelines required manual approvals from security and compliance teams. The team had to spend the first three months coordinating with security and compliance teams to understand the minimum standards on software that would comply with security and compliance requirements. There was no standard for product teams before this team and this was an improvement opportunity.

However, not everything went smoothly. Himanshu calls out a few problem areas that he’d recommend looking out for.

Early in the process, they divided into two teams with five members each. The first team had the domain experts, design, user research and the second had all the engineers. They decided to fully break down the prioritized features into stories and hand them over to engineers to deliver. As expected, this didn’t move any work for about six weeks. Then the teams re-arranged themselves—this time broken down by part of the customer journey and each team now having all skills—domain experts, design, user research, front-end engineer, and back-end engineer. This improved collaboration immediately.

Another issue arose early in the team’s formation: ambiguity in role clarity held the team back from taking action. It took some time for the organization and teams to formalize the responsibilities of each team member. Once these were clarified, the team could collaborate much better, e.g. who decides what to build (PM), who drives customer research (PM and Designer), who helps to navigate dependencies in the organizations (Architect). “Obviously everyone on the team gives input in each scenario, but it helped in each case how we moved forward,” says Himanshu.

On the technical side, the product team discovered after two months that they had to rely on three legacy applications in the organization to deliver the APIs they needed to deliver the product. “This road was laced with uncertainty and risk without this exploration. We wished we had uncovered this sooner,” Himanshu says.

Similarly, poor app documentation and code practices made collaboration difficult. When an architect with in-depth knowledge of the legacy architecture left the team after six months, it led to a painful process of understanding legacy applications without good documentation and coding practices.

Finally, one of the most difficult lessons was, “Old systems die hard,” says Himanshu. While the new teams were all aligned to new customer outcomes on claims, the budgets and incentives were still all aligned in the organization to functional teams. “The team was confused by this contradiction.”

Old systems die hard. – Tweet This

Reflecting on this experience, Himanshu shares the following tips for anyone who’s thinking about moving to cross-functional squads:

• Define roles of people in the product trios/multi-functional teams. It’s good to clarify what everyone’s role is. Nominate product leaders who can coach the individuals in the team.
• Team cohesion takes time. This is why activities like the design sprint can help jump-start collaboration and expose big assumptions in the work that the team is going to undertake at the start.
• Expose tech and organization dependencies early. Product trios and multi-functional teams are sometimes formed around legacy applications and legacy organizations. The sooner they uncover these show-stopping dependencies, the sooner the product trios can work through them with the support of their leadership. This may be working out how their solution utilizes more API-based services from legacy applications.
• Clarify outcomes and goals for the newly formed team. Leaders need to work extra hard to clarify the outcomes of newly formed trios. This includes explaining that their success as a team together will be measured based on these outcomes. Openly acknowledge that this might require executive leadership support as this might be at odds with the old incentive structure.
• Create a safe space to share progress. If this is a new way of working, make it easy for the team to share their learnings and for them to get coaching from seasoned product leaders.

Team cohesion takes time. This is why activities like the design sprint can help jump-start collaboration and expose big assumptions in the work that the team is going to undertake. – Tweet This

Teresa’s Advice: Acknowledge That Learning Will Be Slow at First

In the long run, this type of change is usually pretty powerful. It allows teams to move faster as they can deliver a full value stream without dependencies on other teams.

But the transition can be tough. In a front-end team for example, people collaborate with folks who have the same skills as them. They have a lot of shared ground to work from. In your new model, collaboration is going to take deliberate effort.

To start, it’s going to feel slow and worse. You’ll all need to learn to take the time to explore the diverse perspectives on your team and to work together to get to better solutions. What is likely to happen in the short run is you’ll mimic how you work now, but within your teams—meaning you’ll have a lot of hand-offs between the team members instead of collaboration. So I’d push hard to get people talking to each other and working together.

Some tactical ways you can do that as a member of the team:

• When you are working on something, bring others in on the thought process/design work/decision, even if it’s not part of their expertise.
• Involve more people in everything.
• Over communicate. Adopt the ethos of “working out loud,” where you make the work you are doing visible.
• Socialize with your team. If you are remote, do some Zoom hangouts or Zoom working sessions. The sooner you get familiar with your new teams, the easier collaboration will be.
• Get familiar with what everyone does. You might take turns sharing your work experiences with each other over lunch.

While shifting from functional platform teams can be hard, most companies eventually reap the benefits. Teams have a stronger sense of ownership, they are able to move faster with fewer dependencies, and it’s much easier to adopt an outcome mindset.

While shifting from functional platform teams can be hard, most companies eventually reap the benefits. – Tweet This

If you are in the middle of transitioning from a functional platform team to a cross-functional value-driven team, you aren’t alone. Come get support in our CDH Slack community.

The post Ask the Community: How Do You Shift From Functional Teams to Value-Driven Teams? appeared first on Product Talk.

Ask the Community: How Do You Shift From Functional Teams to Value-Driven Teams? was first posted on March 13, 2024 at 6:00 am.
©2022 “Product Talk“. Use of this feed is for personal non-commercial use only. If you are not reading this article in your feed reader, then the site is guilty of copyright infringement. Please let us know at support@producttalk.org.