3 ms·

One of the main reason I have come to to make peace with that, is that these companies are not optimizing for delivery and product quality first. They are opti

One of the main reason I have come to to make peace with that, is that these companies are not optimizing for delivery and product quality first. They are optimizing against risk (of change, of loss of control over the whole process from ideating to selling/shipping). If you can build the product/service in 2 months with a tight focused team of 3-5 people, in a 100+ engineers company, how do you manage if this 3-5 people leave (whatever the reason): how do you manage to infuse their experience/expertise over the thing they built, to 10/20/30 other people to mitigate then this risk? You can manage to do so when your company grows, because... you don't have a choice, you started small. When you've grown already, to mitigate this risk, you have to start to infuse things across many people and layers of people you have, so that when, 3-5 people leave, it's almost barely noticeable an event. Maybe there's a better set of reasons. But this one made me understand better the whole world of big corporations and especially (big) consulting sofware companies (which are often several ones contracted on the same big projects). Edit: you may also understand "optimizing for" as "scared to death about".

Juliate 4y ago
That also explains the "design by committee" thing and the ugly/desperate UX some corporate apps have.
regularfry 4y ago
That would be justifiable if the risk was proportional to the cost. Frequently it just isn't. As a case in point, if "when, 3-5 people leave, it's almost barely noticeable an event" then you've almost certainly over-compensated for the general case. Why? Because the entire set of people who know anything about a given project simultaneously leaving should be incredibly rare. If that's your benchmark event probability, and your risk mitigation costs are linear in the risk probability (which they probably are, by vague handwavy analogy to finance thinking), then you're constantly bearing costs that aren't justified by the downsides you're likely to encounter unless the specific project in question is company-breakingly critical. If an entire dev team up and leaving isn't a rare event, you've got deeper problems.
- emteycz 4y ago
  This incredibly rare event has happened at almost every firm I've ever worked at (except small startups), multiple times a year (different teams/products, but sometimes also the same product with its new team)... Yeah they should fix the actual issue many layers above, but that's not something the guy planning for this can do at huge corporations. You just deal with whatever it throws at you.
  - regularfry 4y ago
    Interesting. I think I've seen it once in a 20-year career.
- WJW 4y ago
  I think rather frequently the impact of such a "rare" event could indeed be company-breakingly critical, depending on which part of the company that team was running. As a thought experiment, if all DBAs left tomorrow and the database fell over the next day, how much time would the next-most-capable person need to figure out the backup policies and scripts, restore the db and bring everything back up? I've personally seen this sink a company outright. It's only anecdotal evidence ofc, but it is still something that happens. Worse, people leaving a team are not independent events. People leaving a certain team is often highly correlated to other people leaving the same team, because there is some common cause like a toxic manager.
- Juliate 4y ago
  "should be incredibly rare". Not incredibly, it's rare, but it happens (seen it in two small companies, it killed them; saw it in several ESN/consultancy projects, it killed the contract, but was a manageable event in the whole company; saw it in medium software companies, it killed the projects and sometimes pushed for strategy changes). It happens enough for many (not all) individuals to have noticed across their career (especially when in management, where a big part of their role is already to manage risk). It happens enough for any single company to be quite traumatized by it when it happened, and to try to avoid it in the future. Where some companies do it differently is: they don't overreact, they understand that this is a risk management issue and that you can balance it, and/or they don't setup a "general case" for all projets/teams (depending on the type of the project). This requires quite some serenity and perspective.
jokethrowaway 4y ago
I disagree. In most of the large companies I worked for there was zero documentation (+1000 employees, +100 engineers) or very very little or only in a few projects. When people were leaving, someone else was getting hit with a shitty undocumented project, they would spend some time learning it - and that was it. In the worst case a doomed-to-fail-rewrite started and troubled the team for a couple of years. I think the main issue is that: - People are given tasks from the board of directors (trickling down layers and layers of management), they don't feel like it's their problem - There is little accountability, tracking performance is very hard; tons of companies don't bother, but some of them do (after HR intervention, CTO being in trouble justifying the costs) and they can't find decent metrics to use for performance, so the bosses are basically flying blind / trusting middle managers. - No high growth stocks that will make you rich - Middle managers feeling like they need to prove they're doing something imposing weird and useless rituals: meetings, presentations, etc These factors allow people to slack off as much as they can and take as long as they can to do anything. As long as they can come up something for standup, it's all good.
- Juliate 4y ago
  This does not look like disagreement to me, but rather a distinct perspective of the same thing (was it the issue, or the symptom?). Getting hit with a shitty undocumented or doomed to fail project is part of the problem/risk being managed or not: on some occasion, it can kill the team/project/company, on some other, it can be managed more or less successfully, but still in a way that is _not regular_ against the baseline. When you get a project handled by a larger team of people apparently doing "not much", 1/2/3 of these leaving will not change the baseline of the project they were working on (or if it does, then comes the pressure to reorganize again to avoid that disruption). It's "a bit" similar to the 40% lazy ants thing (https://boingboing.net/2017/09/12/living-larders.html https://boingboing.net/2017/09/12/living-larders.html).
sam_lowry_ 4y ago
Here are a few personally lived counter-examples: 1. a unicorn where someone implemented a a CI/CD system that none else can work with nor comprehend 2. a public institution where dozens of people work against the clock to replace the software maintained by a few old farts close to retirement 3. a critical financial institution where secrecy and nepotism made anyone with 30+ years of service into a major failure point. IMO, the bigger the organisation, the more they are shifting from internal risk management to outsourcing all risk. When the risk is handled by third parties via contractual obligations, life get easy for middle management. Needless to say, many of those contractual obligations are not worth the paper they are written on. Many organisations survive largely on the good will of the lowest-rank employees.

Juliate 4y ago

That also explains the "design by committee" thing and the ugly/desperate UX some corporate apps have.

regularfry 4y ago

That would be justifiable if the risk was proportional to the cost. Frequently it just isn't. As a case in point, if "when, 3-5 people leave, it's almost barely noticeable an event" then you've almost certainly over-compensated for the general case. Why? Because the entire set of people who know anything about a given project simultaneously leaving should be incredibly rare. If that's your benchmark event probability, and your risk mitigation costs are linear in the risk probability (which they probably are, by vague handwavy analogy to finance thinking), then you're constantly bearing costs that aren't justified by the downsides you're likely to encounter unless the specific project in question is company-breakingly critical. If an entire dev team up and leaving isn't a rare event, you've got deeper problems.

emteycz 4y ago
This incredibly rare event has happened at almost every firm I've ever worked at (except small startups), multiple times a year (different teams/products, but sometimes also the same product with its new team)... Yeah they should fix the actual issue many layers above, but that's not something the guy planning for this can do at huge corporations. You just deal with whatever it throws at you.
- regularfry 4y ago
  Interesting. I think I've seen it once in a 20-year career.
WJW 4y ago
I think rather frequently the impact of such a "rare" event could indeed be company-breakingly critical, depending on which part of the company that team was running. As a thought experiment, if all DBAs left tomorrow and the database fell over the next day, how much time would the next-most-capable person need to figure out the backup policies and scripts, restore the db and bring everything back up? I've personally seen this sink a company outright. It's only anecdotal evidence ofc, but it is still something that happens. Worse, people leaving a team are not independent events. People leaving a certain team is often highly correlated to other people leaving the same team, because there is some common cause like a toxic manager.
Juliate 4y ago
"should be incredibly rare". Not incredibly, it's rare, but it happens (seen it in two small companies, it killed them; saw it in several ESN/consultancy projects, it killed the contract, but was a manageable event in the whole company; saw it in medium software companies, it killed the projects and sometimes pushed for strategy changes). It happens enough for many (not all) individuals to have noticed across their career (especially when in management, where a big part of their role is already to manage risk). It happens enough for any single company to be quite traumatized by it when it happened, and to try to avoid it in the future. Where some companies do it differently is: they don't overreact, they understand that this is a risk management issue and that you can balance it, and/or they don't setup a "general case" for all projets/teams (depending on the type of the project). This requires quite some serenity and perspective.

jokethrowaway 4y ago

I disagree. In most of the large companies I worked for there was zero documentation (+1000 employees, +100 engineers) or very very little or only in a few projects. When people were leaving, someone else was getting hit with a shitty undocumented project, they would spend some time learning it - and that was it. In the worst case a doomed-to-fail-rewrite started and troubled the team for a couple of years. I think the main issue is that: - People are given tasks from the board of directors (trickling down layers and layers of management), they don't feel like it's their problem - There is little accountability, tracking performance is very hard; tons of companies don't bother, but some of them do (after HR intervention, CTO being in trouble justifying the costs) and they can't find decent metrics to use for performance, so the bosses are basically flying blind / trusting middle managers. - No high growth stocks that will make you rich - Middle managers feeling like they need to prove they're doing something imposing weird and useless rituals: meetings, presentations, etc These factors allow people to slack off as much as they can and take as long as they can to do anything. As long as they can come up something for standup, it's all good.

Juliate 4y ago
This does not look like disagreement to me, but rather a distinct perspective of the same thing (was it the issue, or the symptom?). Getting hit with a shitty undocumented or doomed to fail project is part of the problem/risk being managed or not: on some occasion, it can kill the team/project/company, on some other, it can be managed more or less successfully, but still in a way that is _not regular_ against the baseline. When you get a project handled by a larger team of people apparently doing "not much", 1/2/3 of these leaving will not change the baseline of the project they were working on (or if it does, then comes the pressure to reorganize again to avoid that disruption). It's "a bit" similar to the 40% lazy ants thing (https://boingboing.net/2017/09/12/living-larders.html https://boingboing.net/2017/09/12/living-larders.html).

sam_lowry_ 4y ago

Here are a few personally lived counter-examples: 1. a unicorn where someone implemented a a CI/CD system that none else can work with nor comprehend 2. a public institution where dozens of people work against the clock to replace the software maintained by a few old farts close to retirement 3. a critical financial institution where secrecy and nepotism made anyone with 30+ years of service into a major failure point. IMO, the bigger the organisation, the more they are shifting from internal risk management to outsourcing all risk. When the risk is handled by third parties via contractual obligations, life get easy for middle management. Needless to say, many of those contractual obligations are not worth the paper they are written on. Many organisations survive largely on the good will of the lowest-rank employees.