The Pitfalls of Combining PO With Other Roles | Mike Bowler

Summary

Scrum Master Toolbox Podcast Summary: "The Pitfalls of Combining PO With Other Roles | Mike Balor"

Introduction

In the episode titled "The Pitfalls of Combining PO With Other Roles," host Vasco Duarte engages with Mike Balor, an Agile Coach and Certified Scrum Master. The conversation delves into the challenges and negative patterns that emerge when the roles of Product Owner (PO) are merged with other positions, particularly management. This discussion offers valuable insights for Scrum Masters and Agile Coaches seeking to optimize team dynamics and leadership structures.

The Worst Anti-Pattern: PO as Manager

Mike Balor opens the discussion by identifying a significant anti-pattern within Scrum teams:

[00:50] Mike Balor: "The worst possible combination is when the product owner is also the manager. Far worse than the Scrum Master being the manager is when the product owner is the manager..."

Balor explains that when a PO also holds managerial responsibilities, it creates a conflict of interest. The individual becomes responsible not only for the product vision and backlog but also for overseeing and managing the team's performance. This dual role undermines the Scrum Master's authority and disrupts the balance of responsibilities essential for effective Scrum practices.

Real-Life Example of the Anti-Pattern

To illustrate the detrimental effects of this anti-pattern, Balor shares a real-life scenario:

[02:05] Mike Balor: "I had one team where the product owner was the manager. He was very direct, very controlling. The team actually liked him, but he had his way of wanting things done. The Scrum Master was unable to do anything... it was an absolute disaster in most cases."

In this example, the PO-manager's controlling nature stifled the team's autonomy and silenced the Scrum Master, preventing effective retrospectives and open communication. The team's reliance on the PO-manager led to a lack of genuine collaboration and innovation.

Addressing Dominant Personalities and Hero Culture

Balor further explores the impact of dominant personalities in leadership roles, connecting it to the concept of hero culture:

[03:13] Mike Balor: "Heroes are bad. We often think in stories that the hero is the great person, but a hero... becomes overwhelmed and everyone else disengages."

He warns against building a "hero culture," where the team becomes overly dependent on a single leader. This dependency can lead to burnout for the leader and disengagement from the rest of the team, ultimately harming the project's success.

Strategies for Effective Leadership

To counteract these challenges, Balor offers strategies aimed at fostering a more collaborative and empowered team environment:

[03:53] Mike Balor: "Ask them what they would think should be done first and then confirm or deny. You want your people to come up with the answers..."

He suggests that managers and POs should encourage team members to take ownership of decisions by prompting them to generate solutions before intervening. This approach diminishes the reliance on a single leader and promotes a culture of collective responsibility and continuous improvement.

Balor also references David Marquet’s "Turn the Ship Around" and his "ladder of leadership" as frameworks to help leaders transition towards more effective, curiosity-driven leadership styles.

Characteristics of Great Product Owners

Shifting focus to positive practices, Balor outlines the traits of exemplary Product Owners:

[06:26] Mike Balor: "A great product owner is there a lot of the time. One of the best product owners I've seen was actually working with the ensemble. She was actively in there... answering questions all day long, making sure that the team is there and being supported."

Great POs are deeply involved with their teams, participating in daily activities such as stand-ups and planning meetings. They maintain a balance between being present for immediate team needs and engaging in forward-facing responsibilities like stakeholder meetings. This active involvement ensures that the team has the support and clarity needed to succeed.

Enhancing Team Communication

Balor emphasizes the importance of reducing communication barriers between POs and team members:

[09:42] Mike Balor: "When you're here in the room part of the conversation, they're just going to ask you. They're not going to make any assumptions."

He highlights that when POs are physically or virtually present with the team, it fosters an environment where questions and clarifications flow naturally. This openness prevents misunderstandings and ensures that the team remains aligned with the product vision and goals.

Balor also points to remote ensemble work as an effective method for maintaining communication and collaboration in distributed teams, recommending listeners explore related episodes for practical implementation tips.

Resources and Further Reading

To support listeners in implementing these strategies, Balor mentions several resources:

• David Marquet’s "Turn the Ship Around": A guide on leadership transformation and fostering a culture of empowerment.
• Remote Ensemble Work Episodes: Techniques and tools for maintaining team cohesion and communication in remote settings.

He encourages the audience to seek these resources to enhance their leadership practices and team interactions.

Conclusion

In wrapping up the episode, Mike Balor shares information about his company, Gargoyle Software, and his three distinct blogs focused on Kanban and Scrum, agile technical excellence, and the intersection of neuroscience and Agile practices. These platforms serve as additional resources for Scrum Masters and Agile Coaches seeking to deepen their understanding and refine their craft.

Vasco Duarte concludes the conversation by acknowledging the valuable insights shared by Balor and encourages listeners to explore further content available through the podcast’s membership site and website.

Notable Quotes

• [00:50] Mike Balor: "The worst possible combination is when the product owner is also the manager."
• [02:05] Mike Balor: "When the product owner is also the manager, the Scrum Master no longer has any power at all."
• [03:13] Mike Balor: "Heroes are bad. We don't want to build up a hero in the manager."
• [06:26] Mike Balor: "A great product owner is there a lot of the time... answering questions all day long, making sure the team is supported."
• [09:42] Mike Balor: "When you're here in the room part of the conversation, they're just going to ask you."

This episode provides a comprehensive examination of the pitfalls associated with combining the Product Owner role with managerial responsibilities. By highlighting real-life examples and offering actionable strategies, Mike Balor equips Scrum Masters and Agile Coaches with the knowledge to foster healthier, more effective team dynamics.

Transcript

[Vasco Duart]

Hi, I'm your host, Vasco Duart. Welcome to the Scrum Master Toolbox podcast where we share tips and tricks from Scrum Masters around the world. Every day we bring you inspiring answers to important questions that all Scrum Masters.

[Mike Balor]

Face day after day. Hello, everybody. Welcome to our Friday DGIF and product owner episode this week with Mike Balor. Hey, Mike, welcome back.

Thanks for having me.

Absolutely. So, Mike, we are talking about product owners. We haven't talked much about product owners this week, but now it is the time. And we'll talk about what great product owners do in a minute. But before that, share with us. Mike, the worst potentially product owner anti pattern that you've witnessed in your career.

There are so many anti patterns, but the one that is the worst, in my opinion, is when the product owner is also the manager. That is the worst possible combination. Far worse than the Scrum Master being the manager is when the product owner is the manager. Because when then we have an environment where that person is responsible for not only what the team is doing, but also how they are doing it, because they are the manager. And at that point we have cut out the Scrum Master from the picture entirely. The Scrum Master no longer has any power at all when the product owner is also the manager. So it's the worst possible combination. Now, I have seen some managers pull it off well, but that's a rare manager. It's a really hard job for them to keep themselves isolated enough to still allow the Scrum Master to do what needs to be done. And I've seen it. It's an absolute disaster in most cases. So whenever I come into an environment where the product owner is the manager, I ask them to give up one of those two responsibilities. Either stop being the product owner or stop being the manager.

So let's go deeper. I don't know, maybe you have a story in mind of what was happening. We want like real life examples. Can you share with us what this looks like in practice?

Well, I had. There was one team that I'm thinking of where the product owner was the manager. He was very direct, very controlling. I don't want to say controlling in a bad way. He was a good guy. The team actually liked him. But he was very controlling in the sense that he had his way that he wanted things done. The the Scrum Master was unable to do anything. There were times that I literally would stand in the doorway and prevent him from entering the retrospective because nobody would talk if he was in the room because he had such complete control over what was going on and yet the product owner should be in the retrospective. That's, it's a wrong environment that we've got there. But he would, when he would make a statement to somebody, when he would say, well, I want things done this way, they would immediately not just follow what he wanted done as product owner, but how he wanted it done because he's also the manager. And so if he said, you know, I want it implemented in this way on this technology stack or in this way, the team had no choice because he was also their manager, whereas they should have had those decisions for themselves.

When you say that this was a very dominant personality, I immediately thought one of the conversations we had this week about leading with curiosity because dominant personalities show very little curiosity, right? They just, they either dictate or criticize, right? Do this that way or that was done wrongly. There's very little else in the interaction. There's no, hey, how did that go? And did you get some feedback? What did you try? Like these open ended questions usually don't come up. How do you help a manager? Especially a manager? Because that's kind of the root of this anti pattern. How do you help a manager be more curious with their team?

Well, if they're open to it, and obviously not all managers are, then I will actually, I'll role play. I will actually suggest, if somebody comes to you in this way, I suggest that you work in this way. I will often tell managers, throw the question back to your people. When they come to you asking a question, don't give them an answer. Ask them what they would think should be done first and then confirm or deny. You always have veto power as a manager, but you shouldn't be the one coming up with all the answers. You want your people to come up with the answers and then if you think that's a stupid idea, you can say, no, I'm going to change that. But still make them think about it first. Whereas if the more often you give them the answers, the more often they'll expect you to give them the answers. This is part of hero culture. We don't want to build up a hero in the manager. We don't want to build up a hero anywhere because heroes are bad. We often, you know, we think in stories that the hero is the great person, but a hero. When we have hero culture, then everybody depends more and more on one or sometimes two people and everybody else disengages. The heroes become overwhelmed and eventually they burn out and everybody else disengages because they're not interested anymore. So hero culture is really bad. And when we have a manager in that place, it's very easy for them to become the hero.

Yeah. When you were talking about this, kind of engaging the team, getting the suggestions from the team, and then as a leader, then either take ownership or accept that the idea is good. It really reminded me of this intent leadership by David Marquet, who wrote Turn the Ship Around. He's been on the podcast before and he has really great insights, ideas, and stories about how to bring that to our role as leaders. Because even as coaches, we are also leaders and we might also fall prey to this idea that we have to have the answer right.

Yes. And Marquet has a beautiful. The ladder of leadership that he has published is a beautiful way of helping somebody get from one end of that spectrum to the other. So here's a whole. I think it's six or seven different layers. And if you're at this one, here's what the questions would look like at the next level. And this is what the questions would look like at the next level. So if you're unsure how to make that transition, look up the leader of the ladder of leadership.

Absolutely. We'll put the link on the show notes for that as well. All right, Mike, so we're getting close to the end, but of course we haven't yet talked about what great product owners look like and what they do. So Mike, share that with us.

Well, the great product owners are, first of all, are with the team. A lot of what's going on. We do recognize that a product owner has a split role, that part of their job is supporting the team in the moment, and part of their job is forward facing. And when they are doing the forward facing part of their job, they need to be away. They need to be off in meetings with other groups, they need to be away from the team in some way. But we want to ensure that they're back with the team as much as possible. I've seen a lot of product owners who only occasionally check in with the team. They might be there for standup, they might be there for a planning meeting, but otherwise they're disengaged, they're out of it. A great product owner is there a lot of the time. One of the best product owners I've seen was actually working with the ensemble. So when I was doing ensemble or mob programming with the team, she was actively in there. She wanted. Wanted her turn on keyboard. She'd never written a line of code before in her life, but she wanted to be involved in the process. She wanted to be helpful. She wanted to be part of the experience to see what was going on. But just above that, she was answering questions all day long. It's a common thing when, for product owners, when we've done a day of ensemble work, that they will turn to me and they'll say, the team was asking me questions all day long. They don't normally do that. What's different about today? And I said, well, today you're here, you're not normally here. And there's a huge barrier between, you know, if I have to go and interrupt you in a meeting or I have to send you a text message, that's enough of a barrier that people often won't ask you the question and instead they'll make assumptions and they'll carry on. But when you're here in the room part of the conversation, they're just going to ask you. They're not going to make any assumptions. And so we've got these fabulous product owners who are working actually in the mob or in the ensemble, answering questions all day long, making sure that the team is there and being supported and getting all the right answers, and occasionally actually taking a turn on keyboard, because some product owners love that. Not everybody does, but I don't force any product owners to take a turn on the keyboard, but some love it.

One of the cool things about what you just described is this idea or concept that it's actually a lot easier for POS to put up barriers to communication than to create space for communication. Now, it's not because of the pos, it's not their fault, but it is very easy. For example, POs are usually in contact with people that are higher in the hierarchy of the company. And when they call, the POs don't want to say no.

Right?

Also, the POs already in their minds, communicate so much with the team. What else could they possibly want to ask me? Right? And this is especially true if the PO doesn't have a developer or tester background, because those will typically know why there are so many questions to ask. And this puts us in a position as coaches and, and scrum masters that we actually need to bring that to the PO and say, hey, it's very easy to create the barrier between you and the team. So we need to be very mindful and deliberate about creating those interaction and those spaces for the team to really ask unprompted, kind of organically appearing questions during a session of work. As an example, like you use the ensemble as an example of that?

Yes, absolutely. It's quite common. Even if we're not doing ensemble work, just the product owner sitting with the team. This was easier when we were all physically in a room. But the number of times that I've had a product owner say, now that I actually sit with you in the space and I'm overhearing the conversations that are going on, I understand better why this was so much work or why it was so difficult for you to make this change and so easy to make that change. Because I'm hearing the conversations. It becomes more difficult if we're remote. But even then, we can do remote ensemble work very effectively.

Yeah, absolutely.

So there are ways to lower that barrier, make it easier to have those conversations.

Yeah. And for those interested in remote ensemble work, there's a few episodes I'll link to them in the show notes where we actually talk to people that do this as practitioners and also to people who build products for this kind of remote ensemble work. So check those out. The link is in the show notes. Mike, it's been a pleasure. I mean, a great week filled with insights and great stories. But before we go, where can people find out more about you and the work that you're doing?

My company is Gargoyle Software. I am an independent coach, and so that is my primary point. I will send you the link to that. I also have three different blogs that I will send you links to where I have three very different audiences. So I have a blog that's all about Kanban and Scrum and process type stuff that is improving flow. I have one that's all about technical practices, agile technical excellence, and I have one that's all about the unconscious mind in neuroscience and psychology as it relates to agile. That's unconscious agile. I will send you links to all of those.

Absolutely. Mike, it's been a pleasure. Thank you very much for your generosity with your time and your knowledge.

Oh, you're very welcome.

[Vasco Duart]

One more week of the Scrum Master Toolbox podcast is over, but there's a lot more we have to share. We have developed our own membership site where you find a community of active and engaged Scrum Masters. In this site, you get access to exclusive content and get to interact with us, your podcast host, as well as the best Scrum Masters in the world. So join us@scrum scrummasterpodcast.com and keep this podcast free of advertising. See you next week for one more full week of Scrum Master tips and tricks. We really hope you liked our show, and if you did, why not rate this podcast on Stitcher or itunes. Share this podcast and let other Scrum Masters know about this valuable resource for their work. Remember that sharing is caring.

[Mike Balor]

It.