4 ms·

I 100% agree as a consultant working in product development. I think what drives this is a lack of ability for anyone to understand the end-to-end product from

I 100% agree as a consultant working in product development. I think what drives this is a lack of ability for anyone to understand the end-to-end product from a technical standpoint and make coordinated decisions about direction. Instead, you have 30 teams with their own architects and roadmaps (which often overlap functionality) so you build the same thing 5 times across the org, then 3 of them end up drawing meaningful adoption so you have to figure out how to support that on an ongoing basis. All of this leads to non-technical sales people becoming the de-facto source of product feedback. Which leads to non-technical middle managers making product decisions with a short-term mindset. It's impossible to do a good job under conditions like this, so folks just check out and clock their 40 per week. I think this is the cause of a lot of burnout. People get emotionally invested in their work, but the way tech is structured, quality doesn't matter as much as velocity. Individuals don't fully understand how much impact their work has, so it can seem like toiling away in obscurity for years on end. That doesn't feel good to anyone, but when the company is making 35% margins it's really easy for them to ignore the cash bonfire.

masonhensley 7y ago
Huge problem in many orgs. Many product decisions are made on the fly by the wrong person in an attempt to check a box and get something out the door quick. Or if the right decision gets made upstream, teams downstream don’t align for a litany of reasons. Haven’t been able to put my finger on it exactly (definitely a multi dimensional issue), but I don’t think the issues you outlined will continue to fly if you want something of quality that’s not half baked. This excerpt from agile manifesto comes to mind as part of the problem that I’ve coming to disagree with (at least how I’ve seen it implemented in the past): > The best architectures, requirements, and designs emerge from self-organizing teams.
- BlueTemplar 7y ago
  Do you have any counter-example in mind ?
  - Aeolun 7y ago
    The best architectures, requirements and designs come from a team with a fantastic lead/architect/product manager?
    - maemilius 7y ago
      This. 100% this. Any product of real complexity _must_ have a single person or very small group of people overseeing it. This is doubly true if you're product is using micro-services. The product my current employer is working on suffers immensely from a lack of central leadership to the point where each of the pieces of the application have different (and sometimes contradictory!) ideas of what the world looks like. It's absolutely maddening.
      - closeparen 7y ago
        Any product of real complexity is too big for any one person to hold in their head with sufficient detail. That's why we have modularity. (Microservices are just one kind of module boundary). In my experience, central leaders want to impose grand sweeping worldviews that just aren't true when you get into the weeds of particular use cases. The Director gets a pretty architecture diagram but the engineers actually building and maintaining the feature live in a train wreck. And for what? You don't actually need uniformity across unrelated parts of the system. Architecture shouldn't be about a director's view of his kingdom, but about engineers' ability to sustainably deliver business value, which starts with using the right abstractions for the problem at hand.
        Aeolun 7y ago
        I think we would be able to deliver business value a lot easier if everyone was consistent in the major ways. As it is, everyone has their own idea of what constitutes a dropdown.
    - masonhensley 7y ago
      Yes. If you think of it, the industry has been growing faster than fantastic leads/architects/ project managers can be developed. Those roles take time & experience to nurture, develop battle scars & grow. As a backfill, many orgs are forcing people to pinch hit that are in over their head (not their fault, often times they are also stepping up to help which is great!) The problem is that these people & teams get to the point where they are just trying to survive until the next sprint. Wash & repeat sprint to sprint, deploy something to check the box but it’s building a house of cards.
ilteris 7y ago
This comment nails it. Is there anyway to fix this problem? Not the burnout as that's the symptom but the cause, bad structure.
- 0xffff2 7y ago
  I'm a software engineer in a research environment. GP sticks out to me because it's nearly the opposite of how it works for me. I as the architect/lead software engineer make basically all of the important decisions about the software. I have a project manager and about 6 researchers who are, theoretically, my customers, but they all know that they're not software engineers so they tell me what they need and defer all intermediate decisions to me. Combining my experience with GP, the glib, almost tautological, answer is that you fix the problem by not letting "non-technical middle managers" make technical decisions. Actually implementing this in an organization that already suffers from it is a political problem which I don't have any advice on. For orgs where this isn't a problem yet, the answer is simple. If you're a technical organization, don't hire non-technical managers. Every single person in my management structure started out as an engineer or researcher and it works remarkably well.
  - RugnirViking 7y ago
    On your average project, how many people write code? I'm guessing less than 6. The op is talking about problems that generally start to manifest once the number of programmers are more than the amount of people that can reasonably crowd around the same computer/whiteboard discussing architecture at once
- wayoutthere 7y ago
  Enterprise architecture done well; but the tooling is incredibly difficult, it's expensive and you need a culture devoted to engineering discipline over raw productivity. Other industries manage this just fine: manufacturing and defense contracting are two that come to mind. Both industries have pretty good work / life balance for their employees. Tech is just worse because we haven't unionized like both of those industries did, so the companies are able to operate in a way that is more exploitative of its workers. I think that's actually the source of the outsized margins we see in tech. Agile is just shorthand for "it's too expensive to coordinate things so we'll just make our engineers do that on top of being engineers". The solution is to unionize and start to demand some standards in engineering discipline that allow people to have both a career and a life.
kbr2000 7y ago
I experienced this several times as an employee. It becomes hard to stand when you realize that every positive contribution just results in more money being shoveled out of the window behind your back (mainly because of greed, inefficiency, keeping the status quo, and wreckless behaviour caused by trust in your capabilities to somehow fix it again, every time over again) -- as opposed to contributing to a more efficient way of working for everyone. Been doing extreme over-hours in the hope of fixing stuff once and for ever, only to realize your job becomes more and more like shit-shoveling, since management starts to feel invincible (and protected by your contributions), which leads them to make even more errors without accountability. I've seen some of them with tears in their eyes when I finally quit. 'nuff said. Profiteurs!
- penetrarthur 7y ago
  > Been doing extreme over-hours in the hope of fixing stuff once and for ever, only to realize your job becomes more and more like shit-shoveling, since management starts to feel invincible (and protected by your contributions) Isn't that when you start earning a lot of money?
  - tanseydavid 7y ago
    > Isn't that when you start earning a lot of money? This is very dangerous thinking. Figure out why this true if it is not already obvious. * Not sustainable * Not healthy * Not scalable No sarcasm here. Try to avoid this thinking-trap.
    - kbr2000 7y ago
      Correct. Also, they won't give you that money if they know your motivation is the will to fix things. The money flows instead to the ones who have receiving more money as their motivation.
- netwanderer3 7y ago
  This is actually a very common systemic problem, even happened at organizations like NASA. When the risk is reduced in a single area within a system, people would tend to increase risky behaviors in other areas because they unconsciously justify those behaviors with a perception that the entire system has now become safer. I'm afraid there's no solution to this. In the end we are all humans. How does one even begin to solve a psychological problem at a large scale like this?
Redsquare 7y ago
This is so so very true
exadeci 7y ago
Hello Google messaging apps!

masonhensley 7y ago

Huge problem in many orgs. Many product decisions are made on the fly by the wrong person in an attempt to check a box and get something out the door quick. Or if the right decision gets made upstream, teams downstream don’t align for a litany of reasons. Haven’t been able to put my finger on it exactly (definitely a multi dimensional issue), but I don’t think the issues you outlined will continue to fly if you want something of quality that’s not half baked. This excerpt from agile manifesto comes to mind as part of the problem that I’ve coming to disagree with (at least how I’ve seen it implemented in the past): > The best architectures, requirements, and designs emerge from self-organizing teams.

BlueTemplar 7y ago
Do you have any counter-example in mind ?
- Aeolun 7y ago
  The best architectures, requirements and designs come from a team with a fantastic lead/architect/product manager?
  - maemilius 7y ago
    This. 100% this. Any product of real complexity _must_ have a single person or very small group of people overseeing it. This is doubly true if you're product is using micro-services. The product my current employer is working on suffers immensely from a lack of central leadership to the point where each of the pieces of the application have different (and sometimes contradictory!) ideas of what the world looks like. It's absolutely maddening.
    - closeparen 7y ago
      Any product of real complexity is too big for any one person to hold in their head with sufficient detail. That's why we have modularity. (Microservices are just one kind of module boundary). In my experience, central leaders want to impose grand sweeping worldviews that just aren't true when you get into the weeds of particular use cases. The Director gets a pretty architecture diagram but the engineers actually building and maintaining the feature live in a train wreck. And for what? You don't actually need uniformity across unrelated parts of the system. Architecture shouldn't be about a director's view of his kingdom, but about engineers' ability to sustainably deliver business value, which starts with using the right abstractions for the problem at hand.
      - Aeolun 7y ago
        I think we would be able to deliver business value a lot easier if everyone was consistent in the major ways. As it is, everyone has their own idea of what constitutes a dropdown.
  - masonhensley 7y ago
    Yes. If you think of it, the industry has been growing faster than fantastic leads/architects/ project managers can be developed. Those roles take time & experience to nurture, develop battle scars & grow. As a backfill, many orgs are forcing people to pinch hit that are in over their head (not their fault, often times they are also stepping up to help which is great!) The problem is that these people & teams get to the point where they are just trying to survive until the next sprint. Wash & repeat sprint to sprint, deploy something to check the box but it’s building a house of cards.

ilteris 7y ago

This comment nails it. Is there anyway to fix this problem? Not the burnout as that's the symptom but the cause, bad structure.

0xffff2 7y ago
I'm a software engineer in a research environment. GP sticks out to me because it's nearly the opposite of how it works for me. I as the architect/lead software engineer make basically all of the important decisions about the software. I have a project manager and about 6 researchers who are, theoretically, my customers, but they all know that they're not software engineers so they tell me what they need and defer all intermediate decisions to me. Combining my experience with GP, the glib, almost tautological, answer is that you fix the problem by not letting "non-technical middle managers" make technical decisions. Actually implementing this in an organization that already suffers from it is a political problem which I don't have any advice on. For orgs where this isn't a problem yet, the answer is simple. If you're a technical organization, don't hire non-technical managers. Every single person in my management structure started out as an engineer or researcher and it works remarkably well.
- RugnirViking 7y ago
  On your average project, how many people write code? I'm guessing less than 6. The op is talking about problems that generally start to manifest once the number of programmers are more than the amount of people that can reasonably crowd around the same computer/whiteboard discussing architecture at once
wayoutthere 7y ago
Enterprise architecture done well; but the tooling is incredibly difficult, it's expensive and you need a culture devoted to engineering discipline over raw productivity. Other industries manage this just fine: manufacturing and defense contracting are two that come to mind. Both industries have pretty good work / life balance for their employees. Tech is just worse because we haven't unionized like both of those industries did, so the companies are able to operate in a way that is more exploitative of its workers. I think that's actually the source of the outsized margins we see in tech. Agile is just shorthand for "it's too expensive to coordinate things so we'll just make our engineers do that on top of being engineers". The solution is to unionize and start to demand some standards in engineering discipline that allow people to have both a career and a life.

kbr2000 7y ago

I experienced this several times as an employee. It becomes hard to stand when you realize that every positive contribution just results in more money being shoveled out of the window behind your back (mainly because of greed, inefficiency, keeping the status quo, and wreckless behaviour caused by trust in your capabilities to somehow fix it again, every time over again) -- as opposed to contributing to a more efficient way of working for everyone. Been doing extreme over-hours in the hope of fixing stuff once and for ever, only to realize your job becomes more and more like shit-shoveling, since management starts to feel invincible (and protected by your contributions), which leads them to make even more errors without accountability. I've seen some of them with tears in their eyes when I finally quit. 'nuff said. Profiteurs!

penetrarthur 7y ago
> Been doing extreme over-hours in the hope of fixing stuff once and for ever, only to realize your job becomes more and more like shit-shoveling, since management starts to feel invincible (and protected by your contributions) Isn't that when you start earning a lot of money?
- tanseydavid 7y ago
  > Isn't that when you start earning a lot of money? This is very dangerous thinking. Figure out why this true if it is not already obvious. * Not sustainable * Not healthy * Not scalable No sarcasm here. Try to avoid this thinking-trap.
  - kbr2000 7y ago
    Correct. Also, they won't give you that money if they know your motivation is the will to fix things. The money flows instead to the ones who have receiving more money as their motivation.
netwanderer3 7y ago
This is actually a very common systemic problem, even happened at organizations like NASA. When the risk is reduced in a single area within a system, people would tend to increase risky behaviors in other areas because they unconsciously justify those behaviors with a perception that the entire system has now become safer. I'm afraid there's no solution to this. In the end we are all humans. How does one even begin to solve a psychological problem at a large scale like this?

Redsquare 7y ago

This is so so very true

exadeci 7y ago

Hello Google messaging apps!