6 ms·

Slightly OT thought, but related to ticket tracking systems and the idea of reduced backlogs: As we move more and more towards ubiquitous "Product Orgs," separ

Slightly OT thought, but related to ticket tracking systems and the idea of reduced backlogs: As we move more and more towards ubiquitous "Product Orgs," separate from engineering, I think we're seeing backlogs just explode in size at most places. People need to realize that a large engineering backlog has a lot of negative effects on the SDLC (& velocity) as a whole. I wish more people would embrace heavy-handed WIP limits, even for backlog. But, since backlog is now the primary output of "product orgs" at many (less-than-great) companies, you now have an entire org whose jobs depend on not learning that lesson. I don't know what the answer is, but I really am starting to hate this entire "product org" concept in general. It feels like we used to be able to just engineer our way around many of these challenges ("here, look what I built last week to justify my case"), or just get people into a room and talking. But once the decision channels become explicitly siloed off into a separate org with C-Suite-level autonomy, I'm not sure how you effectively bridge the gaps that form. Any engineers who feel like having a separate product org has been a benefit to your company's product quality and delivery speed want to comment on how you see this sort of thing working effectively?

lifeisstillgood 6y ago
By product org do you mean a silo of an organisation dedicated to one particular product (so if a company has five "apps" they have five siloes and five marketing teams five engineering teams and five board members ?
- LukeShu 6y ago
  I understand it to mean that there is a part of the org (separate from the engineering team) that shapes the direction of the product; decides "these are the features we're going to implement, these are the issues we're going to address"; one way of looking at it is that their primary output is putting things in to the engineering team's backlog.
  - Benjammer 6y ago
    Yeah, this is what I was talking about. Software product management as a separate functional org from engineering. Not like old-Dupont-style product orgs.
    - lifeisstillgood 6y ago
      Aha - so you are saying there is a product manager (plus "org") whose job it is to produce big backlogs separate from the people who will implement them. yeah that's never gonna work :-(
coliveira 6y ago
What I wish is that companies had people specialized in handling issue tracking systems. Expecting developers to do this is absurdo, a lot of the work is just making sure that the ticket is not a duplicate, and similar issues.
- Benjammer 6y ago
  On some level, I kind of wish the entire cottage industry of "issue tracking systems" would just go away. What's wrong with a simple Kanban board? What has ever been wrong with that? It seems to me like, in a lot of cases, engineers just lost their nerve in terms of confidently talking to sales people and the business side of the company, and couldn't deal with the (imo, healthy) tension any more. I understand that people want estimates and timelines and stuff like that, and those are totally reasonable. But flagellating ourselves over absurdly small timelines, and hand-wringing over tiny pieces of features of projects as the core driver for engineering productivity, just seems crazy to me. It seems a lot more like purely signalling to the business side some vague ideas about "commitment," or "hustle," or whatever without having to speak to "those obnoxious sales people."
mumblemumble 6y ago
Depending on your company culture, this may be difficult to do, but I've seen good luck with moving toward a model where the product team doesn't push things into developers' to-do lists. The product folks supply a strictly prioritized wish list, and developers pull from it. Always one thing at a time, always the very first thing on the list. It's the only way I've seen to get the product people to shift their thinking from, "What's a giant list of all the things we wish we could build?" to, "What is thing we actually need to build next?" And, without that change in thinking, the natural impulse is going to be to try and pack more features into the product using a close analogue to the technique that farmers use to produce foie gras. You may have to be willing to sit back and let them drop the ball and get burned for it a few times. If they're pure business folks with little customer support experience, they might never personally understand how fixing a bug can be more valuable to the business than building a new feature, if you don't give them a chance to talk to a user who's irate about some piece of deferred maintenance.
- Benjammer 6y ago
  What kind of scope level do you think works when talking about that list? Like project level instead of tasks, and then engineering figures out how to deliver the prioritized project? Otherwise it kinda just sounds like a backlog to me, just curious how you see the difference there. Also, I've seen product orgs that focus a lot of energy on not being burned, regardless of the scenario. They use their position at the crux of many communication channels to subtly shift blame around. Which is relatively easy to do when your role is complex and many-faceted.
  - mumblemumble 6y ago
    It's going to invariably depend on how your company is organized, and its culture. If you're at all able to start with something approaching the business-facing parts of Scrum, I think that's a great place to start. In Scrum, there are ideally two completely separate queues: The product backlog belongs to the business folks, and is organized in a way that works for them, and the dev team's list of tasks belongs to dev, and probably shouldn't look similar at all. And the only way for things to move from one queue to the other is during a regular meeting where the dev team says, "OK, it looks like we've got room to take on X additional work, what can you give us?" And then, and I think this is secretly one of the most important things, the dev team physically creates new tickets for the new work they're taking on. You should never be able to just drag-and-drop tickets from one queue to the other. Ideally, it shouldn't even be physically possible to do so. Where I am right now, one is in $JIRA_COMPETITOR, and the other is an Excel spreadsheet. (If we all worked out of the same office, I'd probably go for an Excel spreadsheet and yellow sticky notes on a wall. Yellow sticky notes on a wall are awesome. They're a great deterrent to keep the PHBs from generating reports and dashboards for bothering people with KPIs.) This little ceremony, and the associated firewall between two related but separate business functions, is, I think the heart and soul of what Scrum should be. It's the thing that sets up all the little firewalls and incentives that encourage business and dev to maintain a relationship that's more functional than dysfunctional. Everything else - sprints, story points, standup meetings, all that jazz - is just window dressing that some teams may or may not find makes that ceremony go more smoothly. And if you can get a formal handoff like that in place, and get people to respect it, my (admittedly hopelessly idealistic) belief is that the rest of it gets easier to figure out. What's the correct scope and size of individual requests that the product people make of the dev team? Whatever size and scope best enables people to come out of the meeting feeling good about how it went. But if everything's being jammed into one gimongous ticketing system, like all the ticketing system vendors seem to want you to do, you're doomed.
jiveturkey 6y ago
yes. engineers almost always make poor product decisions if the customer is not also an engineering team, in my (vast) experience. this is because engineers aren't product experts. and if the customer is an engineering team, then engineers mostly make mediocre decisions, typically because of poor incentives (gaming story points). in every company i've been at that is larger than a handful of people that all know each other, a separate product org is a requirement if you want a product with broad appeal. i'm not sure what your complaint about the product backlog is. product people should be generating a large backlog. that is literally their job, is it not? it's only through a large backlog that you can say, hey we need more engineers. or hey, our vision doesn't match our capabilities -- refine it. and so on. How exactly does a large backlog have a negative effect on velocity?
- golemiprague 6y ago
  You say it as if it is a fact, what are you basing it on? There are so many examples of start up companies where most of the team were engineers and they created very popular and successful products. It might be even the opposite, many times product people are not necessary really, a middle man between customer facing people and engineering that nobody really needs.
- Sodman 6y ago
  Having an entire separate org whose sole job is to create backlog items inevitably ends up with 100s of items, 15-30% of which are "high" priority. Many of these will have out of date specs by the time engineering can pull them in. I would much rather have product folks embedded in the engineering team. That way they can be working on making sure any issues on deck to be worked on next have up to date, clear requirements, and issues are prioritized correctly. Having product people separated into their own organization almost always leads to a "throw it over the wall" situation.
- Benjammer 6y ago
  >engineers almost always make poor product decisions You seem to be misinterpreting my thoughts as being against the idea of a product manager role. That's not what I mean. I'm talking about product as a separate autonomous org with a CPO, versus embedded PMs reporting to EMs alongside the rest of the product development team. I have similar, though less strong, feelings about Design as a separate org as well, for many of the same reasons (communication overhead/bottlenecks). With regard to backlog, there is actually some capacity planning math that can show that (unintuitively) backlog size negatively affects product delivery velocity. I'm not an expert there, I've just watched some internal tech talks about it in the past. At a higher level, think about what happens when the business side requests a new feature, or a product change. What is the difference in terms of confidence of estimates that can be given if you have 20 tasks in the backlog, versus 200. Sure, for that one thing you can up the priority and jam it in above a bunch of other stuff. But then, once that starts happening to people where you prioritize a newer request above theirs, how does that affect their confidence in your planning ability on a longer timeline? > in my (vast) experience Lastly, maybe pump the brakes a bit here, boss. This statement doesn't make me trust you more, independent of your ideas. We're on a web forum, not in a board room.
jacques_chester 6y ago
> As we move more and more towards ubiquitous "Product Orgs," separate from engineering I've only seen this separation recently and I am not a fan. It just seems like a terrible wasteful way to consume time, money and goodwill. I've never seen anything more effective than small balanced teams.

lifeisstillgood 6y ago

By product org do you mean a silo of an organisation dedicated to one particular product (so if a company has five "apps" they have five siloes and five marketing teams five engineering teams and five board members ?

LukeShu 6y ago
I understand it to mean that there is a part of the org (separate from the engineering team) that shapes the direction of the product; decides "these are the features we're going to implement, these are the issues we're going to address"; one way of looking at it is that their primary output is putting things in to the engineering team's backlog.
- Benjammer 6y ago
  Yeah, this is what I was talking about. Software product management as a separate functional org from engineering. Not like old-Dupont-style product orgs.
  - lifeisstillgood 6y ago
    Aha - so you are saying there is a product manager (plus "org") whose job it is to produce big backlogs separate from the people who will implement them. yeah that's never gonna work :-(

coliveira 6y ago

What I wish is that companies had people specialized in handling issue tracking systems. Expecting developers to do this is absurdo, a lot of the work is just making sure that the ticket is not a duplicate, and similar issues.

Benjammer 6y ago
On some level, I kind of wish the entire cottage industry of "issue tracking systems" would just go away. What's wrong with a simple Kanban board? What has ever been wrong with that? It seems to me like, in a lot of cases, engineers just lost their nerve in terms of confidently talking to sales people and the business side of the company, and couldn't deal with the (imo, healthy) tension any more. I understand that people want estimates and timelines and stuff like that, and those are totally reasonable. But flagellating ourselves over absurdly small timelines, and hand-wringing over tiny pieces of features of projects as the core driver for engineering productivity, just seems crazy to me. It seems a lot more like purely signalling to the business side some vague ideas about "commitment," or "hustle," or whatever without having to speak to "those obnoxious sales people."

mumblemumble 6y ago

Depending on your company culture, this may be difficult to do, but I've seen good luck with moving toward a model where the product team doesn't push things into developers' to-do lists. The product folks supply a strictly prioritized wish list, and developers pull from it. Always one thing at a time, always the very first thing on the list. It's the only way I've seen to get the product people to shift their thinking from, "What's a giant list of all the things we wish we could build?" to, "What is thing we actually need to build next?" And, without that change in thinking, the natural impulse is going to be to try and pack more features into the product using a close analogue to the technique that farmers use to produce foie gras. You may have to be willing to sit back and let them drop the ball and get burned for it a few times. If they're pure business folks with little customer support experience, they might never personally understand how fixing a bug can be more valuable to the business than building a new feature, if you don't give them a chance to talk to a user who's irate about some piece of deferred maintenance.

Benjammer 6y ago
What kind of scope level do you think works when talking about that list? Like project level instead of tasks, and then engineering figures out how to deliver the prioritized project? Otherwise it kinda just sounds like a backlog to me, just curious how you see the difference there. Also, I've seen product orgs that focus a lot of energy on not being burned, regardless of the scenario. They use their position at the crux of many communication channels to subtly shift blame around. Which is relatively easy to do when your role is complex and many-faceted.
- mumblemumble 6y ago
  It's going to invariably depend on how your company is organized, and its culture. If you're at all able to start with something approaching the business-facing parts of Scrum, I think that's a great place to start. In Scrum, there are ideally two completely separate queues: The product backlog belongs to the business folks, and is organized in a way that works for them, and the dev team's list of tasks belongs to dev, and probably shouldn't look similar at all. And the only way for things to move from one queue to the other is during a regular meeting where the dev team says, "OK, it looks like we've got room to take on X additional work, what can you give us?" And then, and I think this is secretly one of the most important things, the dev team physically creates new tickets for the new work they're taking on. You should never be able to just drag-and-drop tickets from one queue to the other. Ideally, it shouldn't even be physically possible to do so. Where I am right now, one is in $JIRA_COMPETITOR, and the other is an Excel spreadsheet. (If we all worked out of the same office, I'd probably go for an Excel spreadsheet and yellow sticky notes on a wall. Yellow sticky notes on a wall are awesome. They're a great deterrent to keep the PHBs from generating reports and dashboards for bothering people with KPIs.) This little ceremony, and the associated firewall between two related but separate business functions, is, I think the heart and soul of what Scrum should be. It's the thing that sets up all the little firewalls and incentives that encourage business and dev to maintain a relationship that's more functional than dysfunctional. Everything else - sprints, story points, standup meetings, all that jazz - is just window dressing that some teams may or may not find makes that ceremony go more smoothly. And if you can get a formal handoff like that in place, and get people to respect it, my (admittedly hopelessly idealistic) belief is that the rest of it gets easier to figure out. What's the correct scope and size of individual requests that the product people make of the dev team? Whatever size and scope best enables people to come out of the meeting feeling good about how it went. But if everything's being jammed into one gimongous ticketing system, like all the ticketing system vendors seem to want you to do, you're doomed.

jiveturkey 6y ago

yes. engineers almost always make poor product decisions if the customer is not also an engineering team, in my (vast) experience. this is because engineers aren't product experts. and if the customer is an engineering team, then engineers mostly make mediocre decisions, typically because of poor incentives (gaming story points). in every company i've been at that is larger than a handful of people that all know each other, a separate product org is a requirement if you want a product with broad appeal. i'm not sure what your complaint about the product backlog is. product people should be generating a large backlog. that is literally their job, is it not? it's only through a large backlog that you can say, hey we need more engineers. or hey, our vision doesn't match our capabilities -- refine it. and so on. How exactly does a large backlog have a negative effect on velocity?

golemiprague 6y ago
You say it as if it is a fact, what are you basing it on? There are so many examples of start up companies where most of the team were engineers and they created very popular and successful products. It might be even the opposite, many times product people are not necessary really, a middle man between customer facing people and engineering that nobody really needs.
Sodman 6y ago
Having an entire separate org whose sole job is to create backlog items inevitably ends up with 100s of items, 15-30% of which are "high" priority. Many of these will have out of date specs by the time engineering can pull them in. I would much rather have product folks embedded in the engineering team. That way they can be working on making sure any issues on deck to be worked on next have up to date, clear requirements, and issues are prioritized correctly. Having product people separated into their own organization almost always leads to a "throw it over the wall" situation.
Benjammer 6y ago
>engineers almost always make poor product decisions You seem to be misinterpreting my thoughts as being against the idea of a product manager role. That's not what I mean. I'm talking about product as a separate autonomous org with a CPO, versus embedded PMs reporting to EMs alongside the rest of the product development team. I have similar, though less strong, feelings about Design as a separate org as well, for many of the same reasons (communication overhead/bottlenecks). With regard to backlog, there is actually some capacity planning math that can show that (unintuitively) backlog size negatively affects product delivery velocity. I'm not an expert there, I've just watched some internal tech talks about it in the past. At a higher level, think about what happens when the business side requests a new feature, or a product change. What is the difference in terms of confidence of estimates that can be given if you have 20 tasks in the backlog, versus 200. Sure, for that one thing you can up the priority and jam it in above a bunch of other stuff. But then, once that starts happening to people where you prioritize a newer request above theirs, how does that affect their confidence in your planning ability on a longer timeline? > in my (vast) experience Lastly, maybe pump the brakes a bit here, boss. This statement doesn't make me trust you more, independent of your ideas. We're on a web forum, not in a board room.

jacques_chester 6y ago

> As we move more and more towards ubiquitous "Product Orgs," separate from engineering I've only seen this separation recently and I am not a fan. It just seems like a terrible wasteful way to consume time, money and goodwill. I've never seen anything more effective than small balanced teams.