9 ms·

We had a large disconnect between product and engineering. The directors solution was to have mandatory 8 hours of sprint ceremonies a week where we would revie

We had a large disconnect between product and engineering. The directors solution was to have mandatory 8 hours of sprint ceremonies a week where we would review the definition of “bug” and “epic”, every week. We also were required to sit in on all team meetings regardless if it was your team. We had two full time scrum masters for a team of six engineers. I suggested instead engineers get looped earlier into the process with stakeholders. The director said it was a bad idea as we couldn’t possibly hope to understand the business side of things. Very glad I got out

deleted 6y ago
[deleted]
danielheath 6y ago
In many companies, the 'product' department exists to protect the owners from the leverage developers would have if they had access to the business context.
- ShamelessC 6y ago
  That's interesting... I think. Could you give an example (as contrived as you wish) to illustrate this point?
  - irishloop 6y ago
    My guess is that if developers understood the business, they would understand how simplistic a lot of the business models are, and how much of the profit is derived directly from their skilled labor and yet how much of the profit goes directly towards someone else, and developers would suddenly realize they have leverage because they are essentially the profit model.
    - ta988 6y ago
      Note that this is the case in most industries, not just software. And that's why the "patrons" "bosses" "chiefs" whatever they are named over time always fought to keep their employees silenced, non-organized... Maybe now is the time to consider cooperatives and getting rid of all or part of the hierarchies (some cooperatives work well with simpler hierarchies). They want disruption, we cut the ties.
      - eru 6y ago
        Hmm, that is a weird conclusion to draw from the observations. The article and the conversation here suggests that the Silicon Valley model is a good way to give developers more leverage and also to get more out of them. That model is generally far from cooperatives and still has plenty of hierarchy. Getting 'organised' and into cooperatives might still work, I don't know? I'm just saying that the available evidence here points to a very different direction. (Cooperatives have been tried, and there are some software companies inside and outside of Silicon Valley that work along similar principles. But by-and-large they aren't the companies eating the world.) Matt Levine's Money Stuff often harps on the theme of investment banks being run like workers' cooperatives in practice.
        ta988 6y ago
        I would be interested if you have a few names of software cooperatives (still running or not). I don't think a company's purpose is necessary to eat the world but that's going into opinions so I will refrain.
        throw_away 6y ago
        This book had an interesting take on the subject: https://leanpub.com/developerhegemony https://leanpub.com/developerhegemony It asked why couldn't development firms be organized like how doctors or lawyers often organize themselves, as partnerships with the PMs, etc like nurses or paralegals.
        eru 6y ago
        On a more macro level, doctors and lawyers use regulation to keep the competition at bay. In some jurisdictions, there are limits that make it harder for outsiders to employ doctors or lawyers and sell their services like you would employ programmers. (In eg Germany, that even applies to pharmacists.)
        throw_away 6y ago
    - jshmrsn 6y ago
      As long as the engineers are replaceable by other engineers, that’s not really leverage. The leverage is the capital to pay the engineers’ salaries and the risk tolerance for the business model possibly failing.
  - danielheath 6y ago
    Essentially, developers with substantial domain experience / familiarity with the problem space tend to do what they think is best, instead of following orders. Accepting the value of that behavior requires a great deal of personal and organizational maturity, especially when you want to try something out quickly and your developers refuse. Sample phrases include: "Why did the customer ask for that - it sounds like our planned implementation won't satisfy their goals", or "Won't this change mean we operate at a loss to subsidize your other company, which will affect staff bonuses".
    - v8engine 6y ago
      >"Won't this change mean we operate at a loss to subsidize your other company, which will affect staff bonuses". I don't get it. Can you explain?
      - danielheath 6y ago
        Boss owns two companies. Staff at company A have negotiated a profit share / performance bonus. Boss directs company A to provide services “below cost” to company B. Company A now has no profit to share; it has been funnelled elsewhere to avoid paying the staff their bonus.
        tinix 6y ago
        This is a dirty tactic, but I've seen it used... a lot. It has slimy tax advantages too, for the company. If you're getting profit sharing, you should be able to see the books, and have controlling shares, too... IMO.
- wikibob 6y ago
  That...is so insightful that I am speechless. I’ve never considered it from that angle. Brilliant.
- dpeck 6y ago
  In my experience it is the opposite of that. Many ‘product’ groups exist because engineering teams kept complaining about meetings and just wanted to be told what the build. Collectively as a profession we have ceded away many of the things that made software development unique and powerful over the last 10 or so years.
  - spamizbad 6y ago
    This is true, but I've also seen "product leaders" in organizations not articulate a clear vision, requiring the engineering staff to do a Socratic-like process to pull tangible requirements out of said "product leader". It's a tedious process so I'm not surprised engineers throw their hands up and just have a PM do it. I do think SV puts more trust in their engineering teams to produce polished software, whereas other companies will burn through tons of dev resources over nit-picking or implementing speculative edge-cases.
    - dpeck 6y ago
      Completely agree, same thing has led to massive growth of product mangers, product owners, and various other titles that do similar things. The devs still tend to have to ask a lot of questions to get anywhere useful but in these situations the P* roles at least give them some traction to work from and get movement.
      - throwaway11121 6y ago
        Frankly, since I've moved to the Netherlands, every project I worked in seemed to exist exclusively to justify a comfy, lazy job for incompetent Dutch POs, scrum masters,"customer journey experts", copywriters, designers. There is way too much money in this country and an incredible amount of bullshit jobs.
        ido 6y ago
        Moved from where? It doesn't sound any different that what you'd get in any western country.
- idclip 6y ago
  My past work is Very much this. Edit: details. Our devops allies itself with management and kept “business secrets” from developers. It was abbhorant to witness. I eventually introduced functionality into the devops tools and openned it to developers and got bullied (2nd edit: by my own team and management, i was soft bullied: silence treatments, secret meetings without me, lies, etc. i was junior. My own confession: i did the work without discussing it with the team after being told “fuck the devs” by a senior.) to quit.
- nafey 6y ago
  Thats an interesting take. But wouldn't product end up having the same leverage? Or is the goal to divide product and engineering work so that no one person has the complete view of the business?
  - ntr-- 6y ago
    The product department (of a sizeable software company) generally lacks the technical ability to actually construct a competing product with the business knowledge they have. They understand the business' financials and interface directly with customers, but they don't understand how the product works. Any features or issues end up being proxied through these nontechnical resources. This is why you will hear devs complain loudly about the parasitic product department (or equivalent layer above them) that always just seem to be > getting in the way However, because developers often don't actually want to interface with customers and just want to build cool tech, and charming socialites are very glad to act as that interface, this usually works. As a secondary effect they (non-intentionally) obfuscate the inner workings of the company from the devs who would otherwise (as the GP points out) realise how much they are being (ab)used and turn the screws on the upper management.
  - oblio 6y ago
    Product folks (generally) can't implement their ideas on their own. Devs can.
tehjoker 6y ago
Business people love to think that their knowledge is somehow on a plane that others can't approach, but we see how many dumb decisions are made on a daily basis. The business would be comprehensible and steerable to everyone in the company, including the janitor, if education were institutionalized.
- cbozeman 6y ago
  I have to admit, its pretty arrogant to think someone can make it through high-level physics, chemistry, mathematics, logic, etc., but can't figure out your business classes. Almost makes me laugh out loud.
  - lordnacho 6y ago
    So much this. I actually studied a joint course of Engineering and business, which was supposed to be two thirds of the Engineering course, two thirds of the business course. When you put it together the Engineering was still about two thirds of the total, with the business stuff mainly being simple things that took a long time to read. Everyone thought it was unsubstantiated just-so stories (Betamax, five forces, etc), but the point was to know the stories so you could communicate with business people. If you look at things that are actually hard, nobody keeps you from getting the info. You're just not going to understand that graduate seminar in ergodic theory, though you're welcome to attend. The reason they keep you from the info is of course you'll see the naked emperor.
    - oblio 6y ago
      Business is super complicated. It's more complicated than science, because it's not science. Science is "easy" because we can model it, to a degree. Non-science is so hard that we can't even model it, it's that complicated. So instead we try to voodoo our way around it, rely on simple heuristics, history, etc.
      - 3pt14159 6y ago
        Business isn't really all that complicated. It's just opaque and intersects with other things that are complicated, like finance and law. But the man who invented 1-800-GOT-JUNK and plastered the phone number on the side of every one of his bins was not some better of Richard Feynman. He understood one thing really well: If you solve a problem, have simple messaging, and unabashedly self-promote you will win. The lawyers, and accountants, and technologists, will all come and help you with the complicated stuff in exchange for a piece of that mountain of cash.
hef19898 6y ago
It's funny, how that would be one of the major differences between Amazon and other companies I worked for. Only for Supply Chain management and logistics.
deleted 6y ago
[deleted]

deleted 6y ago

[deleted]

danielheath 6y ago

In many companies, the 'product' department exists to protect the owners from the leverage developers would have if they had access to the business context.

ShamelessC 6y ago
That's interesting... I think. Could you give an example (as contrived as you wish) to illustrate this point?
- irishloop 6y ago
  My guess is that if developers understood the business, they would understand how simplistic a lot of the business models are, and how much of the profit is derived directly from their skilled labor and yet how much of the profit goes directly towards someone else, and developers would suddenly realize they have leverage because they are essentially the profit model.
  - ta988 6y ago
    Note that this is the case in most industries, not just software. And that's why the "patrons" "bosses" "chiefs" whatever they are named over time always fought to keep their employees silenced, non-organized... Maybe now is the time to consider cooperatives and getting rid of all or part of the hierarchies (some cooperatives work well with simpler hierarchies). They want disruption, we cut the ties.
    - eru 6y ago
      Hmm, that is a weird conclusion to draw from the observations. The article and the conversation here suggests that the Silicon Valley model is a good way to give developers more leverage and also to get more out of them. That model is generally far from cooperatives and still has plenty of hierarchy. Getting 'organised' and into cooperatives might still work, I don't know? I'm just saying that the available evidence here points to a very different direction. (Cooperatives have been tried, and there are some software companies inside and outside of Silicon Valley that work along similar principles. But by-and-large they aren't the companies eating the world.) Matt Levine's Money Stuff often harps on the theme of investment banks being run like workers' cooperatives in practice.
      - ta988 6y ago
        I would be interested if you have a few names of software cooperatives (still running or not). I don't think a company's purpose is necessary to eat the world but that's going into opinions so I will refrain.
        throw_away 6y ago
        This book had an interesting take on the subject: https://leanpub.com/developerhegemony https://leanpub.com/developerhegemony It asked why couldn't development firms be organized like how doctors or lawyers often organize themselves, as partnerships with the PMs, etc like nurses or paralegals.
        eru 6y ago
        On a more macro level, doctors and lawyers use regulation to keep the competition at bay. In some jurisdictions, there are limits that make it harder for outsiders to employ doctors or lawyers and sell their services like you would employ programmers. (In eg Germany, that even applies to pharmacists.)
        throw_away 6y ago
  - jshmrsn 6y ago
    As long as the engineers are replaceable by other engineers, that’s not really leverage. The leverage is the capital to pay the engineers’ salaries and the risk tolerance for the business model possibly failing.
- danielheath 6y ago
  Essentially, developers with substantial domain experience / familiarity with the problem space tend to do what they think is best, instead of following orders. Accepting the value of that behavior requires a great deal of personal and organizational maturity, especially when you want to try something out quickly and your developers refuse. Sample phrases include: "Why did the customer ask for that - it sounds like our planned implementation won't satisfy their goals", or "Won't this change mean we operate at a loss to subsidize your other company, which will affect staff bonuses".
  - v8engine 6y ago
    >"Won't this change mean we operate at a loss to subsidize your other company, which will affect staff bonuses". I don't get it. Can you explain?
    - danielheath 6y ago
      Boss owns two companies. Staff at company A have negotiated a profit share / performance bonus. Boss directs company A to provide services “below cost” to company B. Company A now has no profit to share; it has been funnelled elsewhere to avoid paying the staff their bonus.
      - tinix 6y ago
        This is a dirty tactic, but I've seen it used... a lot. It has slimy tax advantages too, for the company. If you're getting profit sharing, you should be able to see the books, and have controlling shares, too... IMO.
wikibob 6y ago
That...is so insightful that I am speechless. I’ve never considered it from that angle. Brilliant.
dpeck 6y ago
In my experience it is the opposite of that. Many ‘product’ groups exist because engineering teams kept complaining about meetings and just wanted to be told what the build. Collectively as a profession we have ceded away many of the things that made software development unique and powerful over the last 10 or so years.
- spamizbad 6y ago
  This is true, but I've also seen "product leaders" in organizations not articulate a clear vision, requiring the engineering staff to do a Socratic-like process to pull tangible requirements out of said "product leader". It's a tedious process so I'm not surprised engineers throw their hands up and just have a PM do it. I do think SV puts more trust in their engineering teams to produce polished software, whereas other companies will burn through tons of dev resources over nit-picking or implementing speculative edge-cases.
  - dpeck 6y ago
    Completely agree, same thing has led to massive growth of product mangers, product owners, and various other titles that do similar things. The devs still tend to have to ask a lot of questions to get anywhere useful but in these situations the P* roles at least give them some traction to work from and get movement.
    - throwaway11121 6y ago
      Frankly, since I've moved to the Netherlands, every project I worked in seemed to exist exclusively to justify a comfy, lazy job for incompetent Dutch POs, scrum masters,"customer journey experts", copywriters, designers. There is way too much money in this country and an incredible amount of bullshit jobs.
      - ido 6y ago
        Moved from where? It doesn't sound any different that what you'd get in any western country.
idclip 6y ago
My past work is Very much this. Edit: details. Our devops allies itself with management and kept “business secrets” from developers. It was abbhorant to witness. I eventually introduced functionality into the devops tools and openned it to developers and got bullied (2nd edit: by my own team and management, i was soft bullied: silence treatments, secret meetings without me, lies, etc. i was junior. My own confession: i did the work without discussing it with the team after being told “fuck the devs” by a senior.) to quit.
nafey 6y ago
Thats an interesting take. But wouldn't product end up having the same leverage? Or is the goal to divide product and engineering work so that no one person has the complete view of the business?
- ntr-- 6y ago
  The product department (of a sizeable software company) generally lacks the technical ability to actually construct a competing product with the business knowledge they have. They understand the business' financials and interface directly with customers, but they don't understand how the product works. Any features or issues end up being proxied through these nontechnical resources. This is why you will hear devs complain loudly about the parasitic product department (or equivalent layer above them) that always just seem to be > getting in the way However, because developers often don't actually want to interface with customers and just want to build cool tech, and charming socialites are very glad to act as that interface, this usually works. As a secondary effect they (non-intentionally) obfuscate the inner workings of the company from the devs who would otherwise (as the GP points out) realise how much they are being (ab)used and turn the screws on the upper management.
- oblio 6y ago
  Product folks (generally) can't implement their ideas on their own. Devs can.

tehjoker 6y ago

Business people love to think that their knowledge is somehow on a plane that others can't approach, but we see how many dumb decisions are made on a daily basis. The business would be comprehensible and steerable to everyone in the company, including the janitor, if education were institutionalized.

cbozeman 6y ago
I have to admit, its pretty arrogant to think someone can make it through high-level physics, chemistry, mathematics, logic, etc., but can't figure out your business classes. Almost makes me laugh out loud.
- lordnacho 6y ago
  So much this. I actually studied a joint course of Engineering and business, which was supposed to be two thirds of the Engineering course, two thirds of the business course. When you put it together the Engineering was still about two thirds of the total, with the business stuff mainly being simple things that took a long time to read. Everyone thought it was unsubstantiated just-so stories (Betamax, five forces, etc), but the point was to know the stories so you could communicate with business people. If you look at things that are actually hard, nobody keeps you from getting the info. You're just not going to understand that graduate seminar in ergodic theory, though you're welcome to attend. The reason they keep you from the info is of course you'll see the naked emperor.
  - oblio 6y ago
    Business is super complicated. It's more complicated than science, because it's not science. Science is "easy" because we can model it, to a degree. Non-science is so hard that we can't even model it, it's that complicated. So instead we try to voodoo our way around it, rely on simple heuristics, history, etc.
    - 3pt14159 6y ago
      Business isn't really all that complicated. It's just opaque and intersects with other things that are complicated, like finance and law. But the man who invented 1-800-GOT-JUNK and plastered the phone number on the side of every one of his bins was not some better of Richard Feynman. He understood one thing really well: If you solve a problem, have simple messaging, and unabashedly self-promote you will win. The lawyers, and accountants, and technologists, will all come and help you with the complicated stuff in exchange for a piece of that mountain of cash.

hef19898 6y ago

It's funny, how that would be one of the major differences between Amazon and other companies I worked for. Only for Supply Chain management and logistics.

deleted 6y ago

[deleted]