3 ms·

"Herd those cats" - that's where "self organizing teams" come in. Turns out, most groups of people who are told "Hey, you're all accountable for (X). Work toget

"Herd those cats" - that's where "self organizing teams" come in. Turns out, most groups of people who are told "Hey, you're all accountable for (X). Work together on it" will actually work together. That includes figuring out what the business actually needs (not what they say they want), and what tradeoffs may be necessary. I've been on a project in the past that for most of its life had no product owner (or equivalent), just devs, QA, and a team lead, and we delivered what the business flat out said was the biggest success our department had ever given them. We still had internal issues on our team that we had to work around, we still had disagreements, but when everyone is invested in the success of the product, you learn the domain, learn when you need to ask questions, when you need to listen, and when you need to overrule the business (and how to do that in a way they can appreciate). You should have someone in charge (a technical manager say) to handle personnel disputes and otherwise play tie breaker in the event of disagreements, but that's a very specific, and very different, role, compared to what product/project owner/manager entails.

geofft 9y ago
What are your individual incentives and expectations, and who sets them? Who has the power to say "Look, this will be cheaper and better for the business if we spend $50,000 on this SaaS and 3 person-months of dev time integrating it instea of building it in house from scratch"? Are you all individually measured on value to the business and not engineering productivity? My worry with unmanaged teams is that they work well when the right option, with all the data, is to just let some engineers do the engineering they're familiar with / excited about, and very poorly when that's not the right option. So if you don't know in advance which case you're in, you want someone who's able to herd the cats if necessary.
- lostcolony 9y ago
  If the technical people don't understand the tradeoffs and prioritize the business' actual needs (sometimes even above the business' stated wants), why do you think a non-technical person (which is 100% of the POs I've encountered) will be able to?
  - TheCoelacanth 9y ago
    Because the non-technical person has time to dedicate to learning about business' needs while the technical person is busy doing technical stuff for most of their day.
    - lostcolony 9y ago
      And then they have to communicate that to the dev team, and sit with the dev team to come up with proper stories, which effectively saves little to no time (and leads to a game of telephone; is what the PO telling you -really- what the business needs or just what they heard the business tell them they wanted?). Or, be technical enough that they don't need to communicate it to the dev team in the first place but can just write the stories. I've yet to encounter one sufficiently technical
  - geofft 9y ago
    Because technical people aren't often incentivized to prioritize the business' actual needs. This isn't about skillset, it's about how long you're going to stick around at the company if you're doing a different job from what management expects you to be doing.
wgerard 9y ago
Yeah, I see your point and I've been on similar teams. But I think you're: 1) Drawing a lot of conclusions from a single data point (the project you were on) I've been on teams like the one you're referring to as well. I've also been on teams full of great people who needed someone to manage all of those things. Some teams are better at self-organization than others, and I don't think it's a fatal flaw for a team not to be capable of that (to the extent that a business requires, anyway). I've been on many more teams full of excellent people who were incredibly relieved to have someone else do all the organizational work, even if they themselves could've done it quite easily. Organization is overhead. Your team lead was likely filling in the role of "product manager" even if it didn't seem like they were (and in fact, the great ones sometimes make it seem like they're not doing anything at all). 2) Misinterpreting my point The article's suggesting more specialization, whereas it seems like you're arguing for less. The article is suggesting that the role of "product manager" should be split into multiple roles, whereas it seems like you think the role should be subsumed by developers and team leads. Team organization becomes exponentially more difficult if your team is composed of many different roles and specialists. That's what I meant by "herd those cats".
- lostcolony 9y ago
  Oh, of course we filled in that role, and to a point that's what I mean by team lead. But the standard is having both a team lead, and a product owner. Why? What is the PO doing that the team and it's lead aren't better able to do? If there is something, by all means, have that person, but typically there isn't. Which I think is this article's point
  - wgerard 9y ago
    > What is the PO doing that the team and it's lead aren't better able to do? I think you've either been very lucky with teams or you've had terrible luck with product managers. Let me turn it around, actually: Why have a team lead at all? Why can't the developers just collectively meet with higher-ups, decide on timelines, etc.?
    - 9y ago

geofft 9y ago

What are your individual incentives and expectations, and who sets them? Who has the power to say "Look, this will be cheaper and better for the business if we spend $50,000 on this SaaS and 3 person-months of dev time integrating it instea of building it in house from scratch"? Are you all individually measured on value to the business and not engineering productivity? My worry with unmanaged teams is that they work well when the right option, with all the data, is to just let some engineers do the engineering they're familiar with / excited about, and very poorly when that's not the right option. So if you don't know in advance which case you're in, you want someone who's able to herd the cats if necessary.

lostcolony 9y ago
If the technical people don't understand the tradeoffs and prioritize the business' actual needs (sometimes even above the business' stated wants), why do you think a non-technical person (which is 100% of the POs I've encountered) will be able to?
- TheCoelacanth 9y ago
  Because the non-technical person has time to dedicate to learning about business' needs while the technical person is busy doing technical stuff for most of their day.
  - lostcolony 9y ago
    And then they have to communicate that to the dev team, and sit with the dev team to come up with proper stories, which effectively saves little to no time (and leads to a game of telephone; is what the PO telling you -really- what the business needs or just what they heard the business tell them they wanted?). Or, be technical enough that they don't need to communicate it to the dev team in the first place but can just write the stories. I've yet to encounter one sufficiently technical
- geofft 9y ago
  Because technical people aren't often incentivized to prioritize the business' actual needs. This isn't about skillset, it's about how long you're going to stick around at the company if you're doing a different job from what management expects you to be doing.

wgerard 9y ago

Yeah, I see your point and I've been on similar teams. But I think you're: 1) Drawing a lot of conclusions from a single data point (the project you were on) I've been on teams like the one you're referring to as well. I've also been on teams full of great people who needed someone to manage all of those things. Some teams are better at self-organization than others, and I don't think it's a fatal flaw for a team not to be capable of that (to the extent that a business requires, anyway). I've been on many more teams full of excellent people who were incredibly relieved to have someone else do all the organizational work, even if they themselves could've done it quite easily. Organization is overhead. Your team lead was likely filling in the role of "product manager" even if it didn't seem like they were (and in fact, the great ones sometimes make it seem like they're not doing anything at all). 2) Misinterpreting my point The article's suggesting more specialization, whereas it seems like you're arguing for less. The article is suggesting that the role of "product manager" should be split into multiple roles, whereas it seems like you think the role should be subsumed by developers and team leads. Team organization becomes exponentially more difficult if your team is composed of many different roles and specialists. That's what I meant by "herd those cats".

lostcolony 9y ago
Oh, of course we filled in that role, and to a point that's what I mean by team lead. But the standard is having both a team lead, and a product owner. Why? What is the PO doing that the team and it's lead aren't better able to do? If there is something, by all means, have that person, but typically there isn't. Which I think is this article's point
- wgerard 9y ago
  > What is the PO doing that the team and it's lead aren't better able to do? I think you've either been very lucky with teams or you've had terrible luck with product managers. Let me turn it around, actually: Why have a team lead at all? Why can't the developers just collectively meet with higher-ups, decide on timelines, etc.?
  - 9y ago