5 ms·

Curious, why does one or two people leaving make it suck? If this is often the case, maybe management should find ways to address. More money, more opportunitie

Curious, why does one or two people leaving make it suck? If this is often the case, maybe management should find ways to address. More money, more opportunities. etc.

vinceguidry 5y ago
Generally speaking on most software teams, one or two devs do most of the work, bear most of the responsibility, and it's a huge game of catch-up for the rest of the team if they leave. The reason why this is is twofold. First, this is knowledge work, the main task you're doing is fitting stuff in your head. Once one person has something fit into their head, the benefits for the second person doing the work of fitting it also into their head is not nearly as much. So knowledge becomes siloed, and 'knowledge transfer' doesn't work because there's very little the person with the knowledge can do to speed along the process of another person cramming it into their head. Second, infrastructure become unavoidably, yet unnecessarily complex. Decisions about which software projects to use and depend on get handed down by decision-makers who never have to touch those projects themselves. An example from my current team is GitHub Actions. We had to throw away a working Cloud Build CI infra because they liked the pretty interface. But the rest of our infra is on GCP. This complicated the setup such that it was very difficult for other people on the team to build working pipelines. So the knowledge about how it all works gets further siloed into a few people, who find showing others how it works difficult, because of the complexity. In practice the people that know end up doing the hard complex parts for them, no knowledge gets shared, and piling on to the list of things the rest of the team has to learn once they leave. In larger companies, this is solved at the management level like you say. They'll pressure the devs to come up to speed faster as much as they can get away with, incentivize key resources to stick around. The root cause can't be solved at a management level because management can only manage, they have no insight into software complexity and team dynamics. In smaller companies, the resources for doing this are non-existent, it can only be solved through prevention. Not over-complicating the stack, avoiding endless churn. Proactively rotating devs onto other parts of the team to facilitate knowledge transfer. Doing it before someone leaves. Spotting silos and getting someone else in there to learn what's going on.
steveBK123 5y ago
Sometimes you get newer management with NIH syndrome. So existing "legacy" project teams (the ones that are actually in production) can get squeezed on both ends. First they get a lot of BAU pressure to not have outages / ship features faster / etc. Second they also get Change pressure to completely re-architect while doing the BAU and not increasing staffing. For some who play chess in the department head seat, it is win win. If the legacy team has more outages / doesn't speed up on features, he has his remit to build his new pet project replacement and 2-3 years before theres any accountability for the outcome. If the legacy team succeeds in re-architecting then he also gets a win.
mym1990 5y ago
The same reason that LeBron leaving the Lakers would put them at the bottom of the table overnight. While knowledge sharing and thorough documentation is a way to mitigate risk, I don't think it will ever address the loss of an impactful person's vision, knowledge, work ethic, etc... Sometimes other people will also lose morale or see it as a chance to leave themselves... It also takes considerable time to onboard a replacement, which can drastically affect timelines/budgets/etc...

Curious, why does one or two people leaving make it suck? If this is often the case, maybe management should find ways to address. More money, more opportunities. etc.

vinceguidry 5y ago

Generally speaking on most software teams, one or two devs do most of the work, bear most of the responsibility, and it's a huge game of catch-up for the rest of the team if they leave. The reason why this is is twofold. First, this is knowledge work, the main task you're doing is fitting stuff in your head. Once one person has something fit into their head, the benefits for the second person doing the work of fitting it also into their head is not nearly as much. So knowledge becomes siloed, and 'knowledge transfer' doesn't work because there's very little the person with the knowledge can do to speed along the process of another person cramming it into their head. Second, infrastructure become unavoidably, yet unnecessarily complex. Decisions about which software projects to use and depend on get handed down by decision-makers who never have to touch those projects themselves. An example from my current team is GitHub Actions. We had to throw away a working Cloud Build CI infra because they liked the pretty interface. But the rest of our infra is on GCP. This complicated the setup such that it was very difficult for other people on the team to build working pipelines. So the knowledge about how it all works gets further siloed into a few people, who find showing others how it works difficult, because of the complexity. In practice the people that know end up doing the hard complex parts for them, no knowledge gets shared, and piling on to the list of things the rest of the team has to learn once they leave. In larger companies, this is solved at the management level like you say. They'll pressure the devs to come up to speed faster as much as they can get away with, incentivize key resources to stick around. The root cause can't be solved at a management level because management can only manage, they have no insight into software complexity and team dynamics. In smaller companies, the resources for doing this are non-existent, it can only be solved through prevention. Not over-complicating the stack, avoiding endless churn. Proactively rotating devs onto other parts of the team to facilitate knowledge transfer. Doing it before someone leaves. Spotting silos and getting someone else in there to learn what's going on.

steveBK123 5y ago

Sometimes you get newer management with NIH syndrome. So existing "legacy" project teams (the ones that are actually in production) can get squeezed on both ends. First they get a lot of BAU pressure to not have outages / ship features faster / etc. Second they also get Change pressure to completely re-architect while doing the BAU and not increasing staffing. For some who play chess in the department head seat, it is win win. If the legacy team has more outages / doesn't speed up on features, he has his remit to build his new pet project replacement and 2-3 years before theres any accountability for the outcome. If the legacy team succeeds in re-architecting then he also gets a win.

mym1990 5y ago

The same reason that LeBron leaving the Lakers would put them at the bottom of the table overnight. While knowledge sharing and thorough documentation is a way to mitigate risk, I don't think it will ever address the loss of an impactful person's vision, knowledge, work ethic, etc... Sometimes other people will also lose morale or see it as a chance to leave themselves... It also takes considerable time to onboard a replacement, which can drastically affect timelines/budgets/etc...