Clayton Lengel‑Zigich: Welcome to another episode of the Agile Monthly podcast, I’m Clayton Lengel‑Zigich.

Derek Neighbors: I’m Derek Neighbors.

Roy vandeWater: I’m Roy vandeWater.

Clayton: I tried to think of all the reasons why we didn’t record a podcast, but they were all excuses.

Roy: The real reason is we went to the bar and went drinking instead.

My Boss Told Me To Do This Driven Development

Clayton: That sounds like an excuse. Today we’re going to talk about a common pattern that we have observed in a few different places, and it goes something like this.

You’ve got maybe some direction from the product side of the fence where the product owner’s got a boss, and they’ve got a boss, and somebody comes down and someone’s boss’s boss says, “The team should do this.” So the product owner comes in and says “OK here’s what we’re doing, because my boss told me to do this.”

Maybe that gets going a little bit, gets some traction and there’s some idea of what the team’s supposed to be doing, but then maybe someone on the technical side of the fence, like the dev manager or the dev manager’s boss, might say “Well, I want something to be done on the team and I don’t want to go in the backlog to get that stuff done. That might take too long.”

They force the dev manager to direct the team to do something. And since the team reports to the dev manager, the team feels obligated to do that. It’s like a bunch of different parties in the organization playing puppet master with the team. And the team never really gets a whole lot of traction. Would you say that’s a fair assessment, Derek?

Development Managers Undermining Product Owner Authority

Derek: Yeah, I mean, the first pattern is that usually the product manager, product person has trouble a extending…The pattern I tend to see is the product owner has trouble establishing authority and priority in the backlog because of stakeholders that they report to.

About the time they figure out how to get that done and they actually start to get the team baked a little bit and get going, what happens is the dev management side starts to realize that they’re no longer in control of their team, which was probably an illusion to begin with. And so to reassert control or authority back over their team, they tend to start asking their team to do things that aren’t part of that prioritized backlog.

Then the team a gets confused and there’s all sorts of tension between the product owner and the dev manager and the team doesn’t know what to do because they want to do what product wants them to do but they don’t want to be fired and they report to the dev manager. And so there’s just this crazy alpha thing that starts to happen and then the team generally starts to go fairly batshit about that time and all productivity goes out the window.

Clayton: Yes, I’ve always wondered when we see that if it’s a situation where the team feels obligated to do what the product owner says because they feel like, I read the Scrum book, or someone told me about Scrum and that’s how it’s supposed to work.

But, the fact that they all report to the dev manager, if the dev manager can instill a certain control, I wonder maybe it’s because usually the product owner is not at the same level or above the dev manager in the organization. So, they don’t really have the authority to go tell this person, “Too bad. You have to do things through the backlog.”

Mis-Alignment Within The Organization Around Product Owner Authority

Derek: What tends to happen is they tend to report usually to different tree structures. Then their bosses tend to report to different people. Often time in an organization they don’t report…their tree structures don’t cross paths, until you’re at the top tier of the organization.

What happens is the struggle goes up a level or two, and then at that level it’s like, I don’t want to bring this to my boss. Clayton, you and I report to the CEO, and I’m the VP of project management and you’re the CTO.

Our underlings are having this out a little bit, which really we’re having it out, we’re just doing it through our direct reports. But we don’t want to go to our boss and have it out because our boss is going to say, “Are you being a bunch of stupid little children? Why can’t you get along”?

Clayton: No, we can’t solve this pithy little problem on our own.

Roy: I think that’s the answer. It sounds like the development manager and the product owner just need to talk, and be like, “Hey, this isn’t working.” I like the idea of the development manager being organizationally apart from the product owner. I feel like one shouldn’t be above the other.

Loss Of Perceived Control

Derek: The trouble that you run into is when you start to go, at least on the Scrum side, you start to do something that’s more Scrum‑oriented, you start to give a lot of power to the team through empowerment, so the direct dev manager feels like they’re losing a lot of authority that they probably never really had anyway, because they don’t feel in control.

From a product perspective the product owner starts to take a lot more authority about the direction of the product. A lot of times the CTO or the senior dev manager or the dev director or the program director, or whatever you want to call it on the dev side, usually used to have a ton of influence in how the product was developed.

They start to feel like their control, or their influence, is going away. I think a lot of it is insecurity of, “Wait a minute product, you don’t actually need me and my management structure, you just need my developers.” Now a lot of times what you then see is it’s almost like the product owner is almost like the manager or the developers because the developers have respect for the product owner and are listening to the product owner and doing work for the product owner.

I think what happens is you get panic and the panic is like, “I have this urge that I still have control over these people. I’m going to ask them to do something and if they do it I know I still have control.” If they don’t do it and they refer to the product side of the fence then I know I’m losing my control and then that creates blowback upstream.

Clayton: Yeah, we’ve seen teams that have been fractured along those lines where there have been some people on the team who have the allegiance to the dev manager and not the whole structure. Then some of them they just don’t like that person or don’t get along with their manager.

They gravitate on the other person that has somewhat resemblance to the manager who is usually the product owner at this position of authority. You get this kind of fractured team.

Even if the two people aren’t trying to do it purposefully as a power struggle, maybe the dev manager overhears some conversation from the product owner or the product group saying, “I wish the teams would go faster.”

Maybe they’re not even trying to be malicious about it, but they think, “Oh I need to jump in there and make the teams faster. That’s my job, I manage the teams.” Those are the things that you could accidentally cause a rift in the team when you don’t even mean to.

Roy: I think it’s just a matter of making a mental switch from commander/control manager to more of a servant leader, right. Whereas a development manager you start to think more in line of like, “How can I help the team”? Rather than “How can I get the team to do what I want”?

With the product owner that’s a pretty common thing I’ve seen on multiple scrum teams, where the product owner start to take up the role of like the manager of the developers rather than being a member of the team. I think that’s a mistake, it’s very important to make the distinction between like, “You’re the product owner, not the team owner.”

The Product Owner As Part Of The Delivery Team

Clayton: Derek you were sharing some drawings that you had about how you’ve seen some team structure where the product owner is also the manager and they’re outside the team or sometimes they’re inside the team and sometimes they’re also the scrum master and all these different things.

I thought that was pretty interesting, I think in my experience. There are so many product owners that don’t ever treat themselves like a team. Most of the time they don’t, except when it behooves them. If there’s a decision to be made or they’re involved somehow and what the team is going to do next or something like that, then they’re definitely a part of the team.

When it comes to maybe being responsible for everything or like the not special treatment scenarios, they always view themselves as like, “Oh, I know I’m just separate, I’m not part of the team. I’m this product person throughout the organization. I report to the different tree.”

Derek: Yeah, I think it’s difficult. I go back‑and‑forth between where I think the product owner really…I definitely think the team should not be reporting to the product owner from an organizational structure or perspective. I definitely don’t see a ton of value in that or any value in that, I see a lot of conflict.

I go back‑and‑forth