Ruby Video
Talks
Debugging Product Teams
Amy Newell
@amynewell
#debugging
#team-dynamics
#systems-thinking
#team-building
Summarized using AI

Debugging Product Teams

by Amy Newell

In her talk "Debugging Product Teams" at RubyConf 2021, Amy Newell addresses the challenges faced by software product teams and offers a systems approach for diagnosing and resolving issues. Rather than providing quick fixes, Newell emphasizes the importance of observation, understanding, and iterative intervention to improve team dynamics and effectiveness. She defines a product team as a cross-functional group typically comprising engineers, designers, and a product manager and discusses how these teams exist within broader organizational and societal systems.

Key points of the presentation include:
- Systems Approach: Newell advocates for viewing product teams as complex distributed systems influenced by various external and internal factors. Observing these systems holistically enables better comprehension of team dynamics.
- Assumptions: The talk assumes listeners are tech leads or engineering managers and highlights the need for radical curiosity regarding team issues, particularly for those new to their roles.
- Debugging Process: Newell outlines a circular debugging process that involves mapping systems, observing team interactions, forming hypotheses, and implementing interventions. This process is continuous and allows for ongoing adjustments based on new observations.
- Observation Techniques: Real-life examples are crucial. Newell suggests observing interpersonal relationships, understanding career goals, and identifying power dynamics within the team to gather insights regarding performance and morale.
- Interventions: Based on observations, leaders can choose small, impactful interventions. Newell emphasizes the importance of feedback, communication, and working to foster a positive team culture. However, she warns against trying to solve every problem at once and stresses that team members should prioritize their own well-being.
- External Factors: Newell discusses how managers may have little control over external influencing factors like industry competition or funding. However, they can work on resilience within the team and communicate upward about challenges impacting performance.

The conclusion reassures managers that while debugging teams is challenging, it is essential to set boundaries to avoid burnout and maintain mental health. Newell encourages taking deliberate steps toward understanding team dynamics and fostering a collaborative spirit. Ultimately, the ability to debug product teams lies in being observant, adaptive, and sensitive to the complex interplay of systems surrounding them.

00:00:11 Hello, this is debugging product teams.
00:00:14 I'm Amy Newell. The other day, I told someone that I couldn't get to a thing for them because I had to write this talk.
00:00:18 They asked, 'What's the talk about?' I said it's about the problems in software product teams and how to solve them.
00:00:25 They responded, 'Oh, how many days long is this talk?' I told them it's not even half an hour long. So, I will not be telling you how to solve all your product team problems.
00:00:36 What I will be doing is offering a systems approach to reasoning about problems on product teams and a process you can use for understanding and influencing them.
00:00:51 On the way, I will be offering some examples of the kinds of problems that can arise within a product team, but obviously, I cannot give an exhaustive accounting of these.
00:01:02 Thirty seconds about me: I'm Amy Newell. I've been a software engineer since 1999, a part of the Ruby community since 2007, and have been leading engineers for about a decade.
00:01:07 I write and speak on topics around engineering leadership, like I'm doing right now, and I also offer career and leadership coaching and consulting. If you like what you hear today and want to learn more, let's talk.
00:01:20 You can find links to all of my articles at aminole.com and find me on Twitter at Amy Newell.
00:01:35 Okay, first, what is a systems approach to product teams? It's thinking about a product team as a complex distributed people system, embedded in and impacted by multiple other complex distributed people systems.
00:01:43 This perspective also includes working within, and being affected by one or more complex distributed software systems.
00:01:58 The more you can understand and observe about all the systems impacting the team, the richer your understanding of the problems on the team will be, and the more opportunities you'll see to intervene productively.
00:02:12 I'm not going to focus here on the software systems, because there is already a lot of information available for engineers about those and how to reason about them. Instead, there is less information about people systems.
00:02:26 Here are some assumptions I will make that you should consider: I'm assuming a product team is a cross-functional team that includes engineers, designers, and a product manager.
00:02:40 I also assume that you're the tech lead or the engineering manager responsible for the team, and that you're relatively new to the team or that it is in a new configuration.
00:02:54 If that's not true, it's particularly important for you to reset yourself to a position of radical curiosity and openness about what's going on, because you may think you know what the problems are.
00:03:09 However, there are dynamics occurring on the team and in the surrounding system that you can't see. So, you need to actively search for these.
00:03:20 If you're not a manager or lead of the team, you can still use this whole process to reason about the team's problems and try out some interventions.
00:03:34 There are likely good interventions you can try, and you can also try to influence your manager or lead.
00:03:38 Okay, why are you debugging this team at all? Someone in your organization thinks there's something wrong with this team.
00:03:49 I don't assume that it's because the team is not delivering on whatever it has been explicitly asked to do. It doesn't matter if there are people unhappy with the team, either inside or outside of it.
00:04:07 Even if the team appears to be delivering what it's expected to, you must still explore why concerns exist around them.
00:04:19 Here are some caveats that do matter: people typically want to do a good job, but it's not always clear what that means, nor is it always feasible for them to achieve what's being asked of them.
00:04:38 Change is hard and may take time. I once had a team that struggled for a whole year after I took it on; it was a series of complex interactions within the team and organization.
00:05:00 You also have limited ability both to observe and influence; you might not see or be able to impact some of the reasons the team is struggling.
00:05:09 In attempting to observe, you may expend a lot of energy, which is a prime territory for burnout.
00:05:18 It's crucial to understand your limits and take care of yourself throughout this process.
00:05:27 What is this debugging process? This is a circular process where all the pieces are interconnected.
00:05:34 I'm not oversimplifying it, but there are essentially four steps: map the systems impacting the team, observe and ask questions to understand what's happening, formulate hypotheses, and choose interventions.
00:05:49 After implementing the interventions, take a moment to observe the outcomes and then repeat the process, as it is circular.
00:06:04 When I talk about mapping the systems, I'm referring to various levels: each person on the team, the team itself, the software systems they are working with, and other teams in the organization.
00:06:18 You need to consider other individuals or teams in the product organization, the leadership dynamics, and even industry factors that can impact the team's performance.
00:06:33 These could include how much funding is coming into your industry, competition, compliance issues, and even societal factors like the pandemic.
00:06:43 You're essentially casting a wide net from macro systems to micro-level individuals. It’s important to note the feelings of team members and areas of friction or misunderstanding.
00:06:56 You're not trying to create a perfect map; the maps you create will likely be messy and confusing, intended to help you develop a richer understanding of the territory.
00:07:10 You must also factor in the broader business context, whether you have influence in that area or not. Changes in the landscape can significantly affect your organization.
00:07:25 For example, changes in funding or competition could trickle down to your team, so you might need to understand what other teams are experiencing.
00:07:40 Let’s consider a hypothetical product team in fintech. The map of such a team would illustrate all the interactions and pressures impacting it.
00:07:55 In this chaotic scenario, you can see other teams and their roles, along with external factors like funding from venture capital that causes stress on sales due to competition.
00:08:16 While attempting to deal with your internal factors, it's vital to remember the external influences on the team's dynamics.
00:08:34 Next, you're going to observe, starting with the individuals on the team and understanding what’s going on in their lives that impacts their work.
00:08:50 Consider their career goals, how they interact, and power dynamics among them, as these can significantly affect the team's functioning.
00:09:02 Regarding the software systems, while it's essential to tackle those challenges, information is already abundant in existing resources.
00:09:15 That said, it’s crucial to recognize which aspects of the software system negatively impact team satisfaction, even when the team is performing well.
00:09:29 Understanding the internal dynamics among the team members helps identify potential performance issues.
00:09:35 You might see performance problems arising from unacknowledged power dynamics or toxic behaviors, which can influence team morale.
00:09:49 A culture that discourages collaboration or interpersonal disputes could arise from personal relationships that impact the working atmosphere.
00:10:00 Sometimes, unresolved personal tensions can bleed into work relationships, and while it’s challenging to address, it’s essential to recognize.
00:10:16 You may observe conflicts among team members from different departments over differing opinions, which can lead to a lack of trust and misunderstandings.
00:10:25 You could also find problems tied to processes and tools, such as not meeting often enough or issues with continuous integration.
00:10:40 However, if problems surface around processes, sometimes the underlying cause may be interpersonal and not readily apparent.
00:10:54 Much of the time, when people address process issues at retrospectives, they are avoiding discussing the deeper, sometimes personal dynamics.
00:11:07 As you gather information, make sure to observe interactions in pull requests, Slack messages, and other meetings to look for patterns.
00:11:19 Look for signs of dissent, misunderstandings, or notable frustrations among team members, as those can highlight where improvements may be needed.
00:11:32 When observing interactions, note when individuals disengage or openly disagree about matters like coding practices.
00:11:44 Recognize when someone appears overwhelmed due to pressure from other team members or external factors, leading to burnout.
00:11:58 In another scenario, find out why someone isn't getting work done by understanding the underlying personal struggles that may be impacting their productivity.
00:12:12 If you're seeing patterns that confuse you, ask questions to clarify behaviors or feelings you're observing within the team.
00:12:30 For instance, if you notice someone getting frustrated in a meeting, don’t hesitate to reach out and ask them about it.
00:12:48 As you proceed, remember to accept the limits of your position. You can only observe so much and may not always get the complete picture.
00:13:02 This is particularly true if you have power dynamics at play, impacting what others may share with you.
00:13:16 Engage in discussions with various individuals to gain a broader understanding of the situation and your role in it.
00:13:31 Moving on to interventions: just because you've mapped systems and observed patterns does not mean you must empty your personal resources.
00:13:45 You have the choice of how to spend your energy, and while you might have rich insights, use them wisely to choose interventions strategically.
00:14:00 Look for small opportunities to intervene and motivate positive change within the team dynamics.
00:14:14 As a manager, that might mean having some difficult conversations or providing necessary coaching.
00:14:25 Even if you are an individual contributor, your behavior can influence the team, and you might create small changes to build a more positive atmosphere.
00:14:40 For example, encourage collaboration through a positive acknowledgment when team members support each other effectively.
00:14:55 Engagement in problem-solving is essential, but if toxic dynamics exist, don't put the entire team together to address them, as this can stifle the honest expression of concerns.
00:15:05 If someone in leadership, like Jack, is causing conflict within the team, take action to remove or address it quickly before it escalates.
00:15:19 As an individual contributor, if you identify someone like Jack as a negative influence, it's complicated to call that out directly.
00:15:32 It might be necessary to report it to a leader, but gauge what's appropriate based on your relationships and the environment.
00:15:45 Concerning factors external to the team, maintain the mapping and observation you've conducted, and denoting your feelings about external challenges is crucial.
00:16:01 If that's where the core of the issue lies, consider how you can express those challenges to your direct leaders or peers.
00:16:19 You should pinpoint areas that cause friction or hardship and see if there’s a way to have upstream conversations that address these externalities.
00:16:32 However, always recognize that your ability to impact these systems is limited, especially when unreasonable expectations exist.
00:16:44 If you find yourself in a situation where clarity about team objectives and performance is lacking, remember to adapt accordingly.
00:17:01 In these instances, you must proceed with decisions on what the team will focus on, even without explicit direction.
00:17:15 Ultimately, the specifics causing your team to struggle with morale or performance are unique, but the debugging mindset is crucial.
00:17:27 The debugging skill comprises mapping the team and systems, learning about the energy flow, and wisely choosing interventions.
00:17:44 After implementing changes, observe outcomes and accept the limitations of your actions, as you cannot control others or their feelings.
00:18:01 Remember, while you can encourage change, you cannot enforce it, much like parenting teenagers.
00:18:12 Be mindful as you delve into this work; it can be taxing both intellectually and emotionally, necessitating boundaries for your health.
00:18:26 This is my introduction to debugging product teams. I'm Amy Newell. If you need help debugging a product team, you can find me at aminole.com.
00:18:35 Feel free to reach out for assistance. I also write about these topics and encourage you to sign up for my mailing list at amywrightsports.com.
00:18:52 Thank you so much, RubyConf. I love you, miss you, and hope to see you all in person next year.
00:19:05 Goodbye!
Edit
Explore all talks recorded at RubyConf 2021
+92