5 ms·

Have you ever been in a situation where communicating and breaking things down takes longer than the actual work? IMHO most disasters I’ve seen occur when ‘Pro

Have you ever been in a situation where communicating and breaking things down takes longer than the actual work? IMHO most disasters I’ve seen occur when ‘Product’ tries to strictly control the ‘Developers’. It just does not work for certain kinds of projects. It also diminishes the developers’ involvment and leads to a culture of mediocrity and CYAs. Also, a person that does not have to do the work will always be waaaay more optimistic about how much it takes to do the work. How do you fix it? Trust and ownership. Product and Dev need to have an interface - a boundry if you will - and the discussions and talk are about defining this interface and setting expectations. Product trusts Dev on implementation. Dev owns the delivery and makes it happen.

lostcolony 8y ago
This is why agile tries to push the business stakeholders to define -problems- rather than -solutions-. Developers then try and come up with a solution, and pitch it to the business (effectively). Almost every issue I've had with the business/developer dichotomy (and I use that instead of product because different orgs place product differently) has been due to the business trying to pitch solutions to dev that invariably end up not actually addressing the problem (even simple things like "that's the wrong color" or similar, are because they believe they're responsible for the solution, and they have a very clear idea of what the solution should be, without actually being able to articulate or recognize the problem. Does the color actually matter? If you have a problem that implies it does, yes, if you just came up with a solution on your own and in your head that solution was yellow, no).
- mirceal 8y ago
  Maybe, maybe not. I’m very suspicious of things that are pitched as a panacea for everything. The real world is a messy place where even with a good team, a good plan and sensible expectations you can fail spectacularly. If there is one thing that I really like is aggressive validation of the assumptions that are being made + keeping the product as small and lean as humanly possible (and the latter should apply across the board to everything you do). Complexity and Entropy are preparing the coffin for your work even before you have the idea. You can give ‘em a run for their money, but in most cases you’re going to end up 6 feet under. As soon as you accept this and are genuinely open to failure you will be ready for the opposite.
  - lostcolony 8y ago
    Oh, I'm not saying it's a panacea for everything. Just that most issues I've seen along these lines were also accompanied with a perspective on the business side that their role was to give solutions, which were invariably insufficient, led to the dev team just doing the minimum (since they had no idea what the core problem was and thus were unable to determine where 'sufficient' really was), and that compounded.
    - mirceal 8y ago
      That definitely happens and it’s... unfortunate
fokinsean 8y ago
> Product trusts Dev on implementation Currently having issues with this one right now, and it is the most frustrating thing I've experienced at a job.
- bittcto 8y ago
  The problem is that product and dev are different people. Product managers don’t understand their product as well as the devs do. devs should manage the product definition and work with feature requesters at a very high level, where the details are the choices of the devs (or senior devs acting as product managers.)
- mirceal 8y ago
  you're not alone. I would say that lack of trust is the norm not the exception when it comes to software dev teams :(
- jrs235 8y ago
  Ditto. A colleague called into question an off the top of my head estimate. A 2 day estimate and tried squeezing me to cut it down more... For work I wouldn't even be doing. Nope. Not going to do it. I tried to call into question his estimate of how long it would take for one of his sales guys to sell the lead he received yesterday. Once he threw out a number I asked why so long? Needless to say the conversation didn't end on a good note. Live and learn. We'll talk it out tomorrow. A quick way to lose trust and respect is implying incompetency and squeezing/trying to manipulate people. Really kinda pissed at him right now.

lostcolony 8y ago

This is why agile tries to push the business stakeholders to define -problems- rather than -solutions-. Developers then try and come up with a solution, and pitch it to the business (effectively). Almost every issue I've had with the business/developer dichotomy (and I use that instead of product because different orgs place product differently) has been due to the business trying to pitch solutions to dev that invariably end up not actually addressing the problem (even simple things like "that's the wrong color" or similar, are because they believe they're responsible for the solution, and they have a very clear idea of what the solution should be, without actually being able to articulate or recognize the problem. Does the color actually matter? If you have a problem that implies it does, yes, if you just came up with a solution on your own and in your head that solution was yellow, no).

mirceal 8y ago
Maybe, maybe not. I’m very suspicious of things that are pitched as a panacea for everything. The real world is a messy place where even with a good team, a good plan and sensible expectations you can fail spectacularly. If there is one thing that I really like is aggressive validation of the assumptions that are being made + keeping the product as small and lean as humanly possible (and the latter should apply across the board to everything you do). Complexity and Entropy are preparing the coffin for your work even before you have the idea. You can give ‘em a run for their money, but in most cases you’re going to end up 6 feet under. As soon as you accept this and are genuinely open to failure you will be ready for the opposite.
- lostcolony 8y ago
  Oh, I'm not saying it's a panacea for everything. Just that most issues I've seen along these lines were also accompanied with a perspective on the business side that their role was to give solutions, which were invariably insufficient, led to the dev team just doing the minimum (since they had no idea what the core problem was and thus were unable to determine where 'sufficient' really was), and that compounded.
  - mirceal 8y ago
    That definitely happens and it’s... unfortunate

fokinsean 8y ago

> Product trusts Dev on implementation Currently having issues with this one right now, and it is the most frustrating thing I've experienced at a job.

bittcto 8y ago
The problem is that product and dev are different people. Product managers don’t understand their product as well as the devs do. devs should manage the product definition and work with feature requesters at a very high level, where the details are the choices of the devs (or senior devs acting as product managers.)
mirceal 8y ago
you're not alone. I would say that lack of trust is the norm not the exception when it comes to software dev teams :(
jrs235 8y ago
Ditto. A colleague called into question an off the top of my head estimate. A 2 day estimate and tried squeezing me to cut it down more... For work I wouldn't even be doing. Nope. Not going to do it. I tried to call into question his estimate of how long it would take for one of his sales guys to sell the lead he received yesterday. Once he threw out a number I asked why so long? Needless to say the conversation didn't end on a good note. Live and learn. We'll talk it out tomorrow. A quick way to lose trust and respect is implying incompetency and squeezing/trying to manipulate people. Really kinda pissed at him right now.