6 ms·

I've also seen some instance where gatekeeper were pretty effective at filtering users demands because some of those requests were too dumb and the "paying" use

I've also seen some instance where gatekeeper were pretty effective at filtering users demands because some of those requests were too dumb and the "paying" users were used to have everything they wanted, and because they "paid" the dev department, "they had to do everything they wanted". Like asking for a 6months dev work to help them save 1 hour annually on an annoying task they had to do.

hatchnyc 5y ago
My experience has been the exact opposite, if the developers understand what the business is trying to accomplish and what the incentives are then they are in a much better position to prioritize and build the right thing. Every single time I’ve seen 6 months of work on a useless or low value feature it has been the result of the dev team getting requests via some PM telephone game.
- robertlagrant 5y ago
  This is a tricky balance. Developers can also get overwhelmed with requests for estimates, automation tasks, etc etc, and get annoyed that people have so much contact with them. But it is a tricky balance; there's no obvious solution.
  - kragen 5y ago
    Sometimes it's helpful to have some division of labor between field/sales/support engineers who go to handhold customers, understand their particular problems, and prototype fixes, and "product engineers" who have less customer interaction. This is somewhat similar to the SRE/SWE split at places like Google. If I were designing an organization with such a division of labor, those wouldn't be different job descriptions but different activities within a single job description; maybe I'd spend 22 days a month doing product-engineer stuff like adding features, and 3 days a month doing support-engineer stuff like visiting customer sites, diagnosing customer problems, and answering calls, while maybe hatchnyc would prefer to spend 22 days a month doing support-engineer stuff and 3 days a month doing product-engineer stuff. The reason is that, doing either activity, you gain an enormous amount of knowledge that's crucial to the other activity, but very difficult to even put into words, much less into a knowledge base. Bill Gates found it useful to answer tech support calls as late as 01989: https://www.entrepreneur.com/article/289857 https://www.entrepreneur.com/article/289857
    - robertlagrant 5y ago
      > Bill Gates found it useful to answer tech support calls as late as 01989 This is good, but it's easier when you're a very extraordinary human, and your own boss!
      - kragen 5y ago
        Yeah, but Bill Gates managed to do it too.
pc86 5y ago
> Like asking for a 6months dev work to help them save 1 hour annually on an annoying task they had to do. I see this as a complaint a lot, but... in a private company, they're the ones writing the checks. So if they want to spend hundreds of thousands of dollars to save an hour, that's their prerogative. It's certainly our obligation to point out the cost (including ongoing maintenance) but again in a private company you don't really have the option of saying "no" except with your feet.
- cheschire 5y ago
  Of course you have the option of saying "no" unless the company culture / leadership climate does not allow it. That's far from the inherent obligation you're describing. I do however agree with leaving any organization that does not allow you to express disagreement.
  - pc86 5y ago
    I think that depends on whether "no" means a nice way of saying "this is stupid" - which I agree with, and have done before, to mixed results - vs. outright refusing to do work that's been requested. I don't think an employee who is being paid a wage by an employer has the right to refuse to do something just because it's a stupid idea.
    - alach11 5y ago
      I'd much rather have an employee who will refuse to do work that is stupid than one who will do whatever is asked of them. Especially if it's something as bad as the GP example of six months of dev work to save one person-hour per year.
    - deleted 5y ago
      [deleted]
- Frost1x 5y ago
  Yea, I don't see the complaint here. It's part of my job to let whomever the client may be that what they're doing may be a bad use of resources (typically in a documented email in a very positive tone with lots of "decision makers" on the email, also with a nice lead in explanation as to a way it could be efficient under some set of circumstances so they can copy paste that as their "well we weren't sure" pathway forward). After that, I really really don't care anymore, that's someone else's problem. I've played that soapbox and it's a waste of my time and energy. I make sure responsibility is passed back, documented and proceed. If you want to throw hundreds of thousands or millions at me and whomever to some wasteful request, go for it. You have the option, you've been warned, and I've given you a valid excuse to proceed with high risk, high uncertainty of ROI option with everyone important involved. I do a lot of contractual/consulting work so even warning can mean early termination of work forward, so I'm taking a risk even informing you (some people actually listen and work stops early during consulting time and development follow up never occurs, these are the smart people and they're bad for my livelihood)--I could just do whatever you ask and get paid. If I were salaried, there's even less risk of me losing income forward by informing so I say in those cases just do your professional due diligence go let people know it's a bad idea without creating political land mines for anyone, then allow them to step on land mines at their own discretion.
spaetzleesser 5y ago
I have seen it more often that gatekeepers filtered user demands based on their own knowledge and not on technical feasibility or effort. So you are told that a user needs a certain thing in a certain way but when you talk directly to the user you learn that the user actually had a different need which you can fulfill in an easier way than the gatekeeper thought possible. In general I think there is a huge advantage if developers know first hand how their product is being used and not through gatekeepers.
- hiptobecubic 5y ago
  The whole point is that this doesn't scale. What do you do when there are too many users to interview them all over coffee?
  - lifeisstillgood 5y ago
    Honestly that's the whole problem with Democracies. And we solve it with sampling and surveys. Probably if we can come up with a better answer, we will improve Scrum, and Democracies :-)
  - datavirtue 5y ago
    You have key business ops people AND their key users (direct reports) involved. It scales.
    - hiptobecubic 5y ago
      Unless you work on an internal tool "business ops" are not your users. I'm talking about real products with external users that are only really identifiable as an "account" unless it's a massive contract with dedicated sales team.
kragen 5y ago
Even when the possible goals are identified, someone has to prioritize them at some point, since there are always more goals you could achieve than goals you will achieve. To prioritize, you need to know both the benefit of a goal (which is really a probability distribution, not a number) and its cost (which is notoriously a wide probability distribution before you have done it). Sometimes this involves trading off the needs of different "goal donors"; in XP these all filter through a single "goal donor", confusingly called the "customer", who decides how to order the cards in the box once they're estimated. The goal donor (who may or may not be the gold owner, another confusing name) can reorder the cards at the beginning of each iteration, either because new information has appeared about the benefits, about the costs, or about the possible goals. It sounds like what you're describing is the lack of such prioritization. It isn't necessary to keep the developers ignorant of new user "demands" in order to prioritize them; they just need to be empowered to follow the priorities the team has chosen instead of accommodating every demand. Sometimes it's easier to accommodate a demand than to write up a card and estimate it, though. Sometimes a bug fix or layout tweak is obvious enough that doing it takes only a minute or two; then, it's just a question of process overhead whether the actual cost of doing it is five minutes or five hours: potentially multiple forwarded email round trips, a fresh checkout, pair programming or other code review, compilation time, test suites, commit comments, merge requests. Usually, in my experience, if you have extreme overhead, most of those changes never get requested, because they don't get prioritized the way they would with the order-of-magnitude lower cost a lightweight process can provide. The result is that they never get done, so the product is full of easily observable minor problems, which is experienced as shoddiness.

hatchnyc 5y ago

My experience has been the exact opposite, if the developers understand what the business is trying to accomplish and what the incentives are then they are in a much better position to prioritize and build the right thing. Every single time I’ve seen 6 months of work on a useless or low value feature it has been the result of the dev team getting requests via some PM telephone game.

robertlagrant 5y ago
This is a tricky balance. Developers can also get overwhelmed with requests for estimates, automation tasks, etc etc, and get annoyed that people have so much contact with them. But it is a tricky balance; there's no obvious solution.
- kragen 5y ago
  Sometimes it's helpful to have some division of labor between field/sales/support engineers who go to handhold customers, understand their particular problems, and prototype fixes, and "product engineers" who have less customer interaction. This is somewhat similar to the SRE/SWE split at places like Google. If I were designing an organization with such a division of labor, those wouldn't be different job descriptions but different activities within a single job description; maybe I'd spend 22 days a month doing product-engineer stuff like adding features, and 3 days a month doing support-engineer stuff like visiting customer sites, diagnosing customer problems, and answering calls, while maybe hatchnyc would prefer to spend 22 days a month doing support-engineer stuff and 3 days a month doing product-engineer stuff. The reason is that, doing either activity, you gain an enormous amount of knowledge that's crucial to the other activity, but very difficult to even put into words, much less into a knowledge base. Bill Gates found it useful to answer tech support calls as late as 01989: https://www.entrepreneur.com/article/289857 https://www.entrepreneur.com/article/289857
  - robertlagrant 5y ago
    > Bill Gates found it useful to answer tech support calls as late as 01989 This is good, but it's easier when you're a very extraordinary human, and your own boss!
    - kragen 5y ago
      Yeah, but Bill Gates managed to do it too.

pc86 5y ago

> Like asking for a 6months dev work to help them save 1 hour annually on an annoying task they had to do. I see this as a complaint a lot, but... in a private company, they're the ones writing the checks. So if they want to spend hundreds of thousands of dollars to save an hour, that's their prerogative. It's certainly our obligation to point out the cost (including ongoing maintenance) but again in a private company you don't really have the option of saying "no" except with your feet.

cheschire 5y ago
Of course you have the option of saying "no" unless the company culture / leadership climate does not allow it. That's far from the inherent obligation you're describing. I do however agree with leaving any organization that does not allow you to express disagreement.
- pc86 5y ago
  I think that depends on whether "no" means a nice way of saying "this is stupid" - which I agree with, and have done before, to mixed results - vs. outright refusing to do work that's been requested. I don't think an employee who is being paid a wage by an employer has the right to refuse to do something just because it's a stupid idea.
  - alach11 5y ago
    I'd much rather have an employee who will refuse to do work that is stupid than one who will do whatever is asked of them. Especially if it's something as bad as the GP example of six months of dev work to save one person-hour per year.
  - deleted 5y ago
    [deleted]
Frost1x 5y ago
Yea, I don't see the complaint here. It's part of my job to let whomever the client may be that what they're doing may be a bad use of resources (typically in a documented email in a very positive tone with lots of "decision makers" on the email, also with a nice lead in explanation as to a way it could be efficient under some set of circumstances so they can copy paste that as their "well we weren't sure" pathway forward). After that, I really really don't care anymore, that's someone else's problem. I've played that soapbox and it's a waste of my time and energy. I make sure responsibility is passed back, documented and proceed. If you want to throw hundreds of thousands or millions at me and whomever to some wasteful request, go for it. You have the option, you've been warned, and I've given you a valid excuse to proceed with high risk, high uncertainty of ROI option with everyone important involved. I do a lot of contractual/consulting work so even warning can mean early termination of work forward, so I'm taking a risk even informing you (some people actually listen and work stops early during consulting time and development follow up never occurs, these are the smart people and they're bad for my livelihood)--I could just do whatever you ask and get paid. If I were salaried, there's even less risk of me losing income forward by informing so I say in those cases just do your professional due diligence go let people know it's a bad idea without creating political land mines for anyone, then allow them to step on land mines at their own discretion.

spaetzleesser 5y ago

I have seen it more often that gatekeepers filtered user demands based on their own knowledge and not on technical feasibility or effort. So you are told that a user needs a certain thing in a certain way but when you talk directly to the user you learn that the user actually had a different need which you can fulfill in an easier way than the gatekeeper thought possible. In general I think there is a huge advantage if developers know first hand how their product is being used and not through gatekeepers.

hiptobecubic 5y ago
The whole point is that this doesn't scale. What do you do when there are too many users to interview them all over coffee?
- lifeisstillgood 5y ago
  Honestly that's the whole problem with Democracies. And we solve it with sampling and surveys. Probably if we can come up with a better answer, we will improve Scrum, and Democracies :-)
- datavirtue 5y ago
  You have key business ops people AND their key users (direct reports) involved. It scales.
  - hiptobecubic 5y ago
    Unless you work on an internal tool "business ops" are not your users. I'm talking about real products with external users that are only really identifiable as an "account" unless it's a massive contract with dedicated sales team.

kragen 5y ago

Even when the possible goals are identified, someone has to prioritize them at some point, since there are always more goals you could achieve than goals you will achieve. To prioritize, you need to know both the benefit of a goal (which is really a probability distribution, not a number) and its cost (which is notoriously a wide probability distribution before you have done it). Sometimes this involves trading off the needs of different "goal donors"; in XP these all filter through a single "goal donor", confusingly called the "customer", who decides how to order the cards in the box once they're estimated. The goal donor (who may or may not be the gold owner, another confusing name) can reorder the cards at the beginning of each iteration, either because new information has appeared about the benefits, about the costs, or about the possible goals. It sounds like what you're describing is the lack of such prioritization. It isn't necessary to keep the developers ignorant of new user "demands" in order to prioritize them; they just need to be empowered to follow the priorities the team has chosen instead of accommodating every demand. Sometimes it's easier to accommodate a demand than to write up a card and estimate it, though. Sometimes a bug fix or layout tweak is obvious enough that doing it takes only a minute or two; then, it's just a question of process overhead whether the actual cost of doing it is five minutes or five hours: potentially multiple forwarded email round trips, a fresh checkout, pair programming or other code review, compilation time, test suites, commit comments, merge requests. Usually, in my experience, if you have extreme overhead, most of those changes never get requested, because they don't get prioritized the way they would with the order-of-magnitude lower cost a lightweight process can provide. The result is that they never get done, so the product is full of easily observable minor problems, which is experienced as shoddiness.