5 ms·

I recognize this is an extract from a larger book I haven't read, but my main reaction is: prove it. All of this reads to me like a software developer complain

by larrik 2y ago

I recognize this is an extract from a larger book I haven't read, but my main reaction is: prove it. All of this reads to me like a software developer complaining at the pub. The wording is strong and the premise that "employee churn is lethal to software companies" is an extreme claim. Yet, not one company is used an example of one that died due to employee churn. In short, I don't buy it. There's generally only a tenuous relationship between software quality and business success to begin with, and history has shown over and over that the importance of software quality is far more important at the beginning of a business (or product) than after it's established. So to claim that employee churn kills entire companies needs a lot to back that up, starting with numbers (which there are none in here)

f1shy 2y ago
My 2 cts: churn has objectively a cost. At some point that cost can kill a business. Where exactly is that point, depends on many different factors. There is to my knowledge, in this regard, nothing special about software, that cannot be said about other development activities.
- bunderbunder 2y ago
  I would guess that, like technical debt, churn is something you can have both too much and too little of. Stagnation also has a cost. When I work with teams that have had the same members for a long time, it seems that they've always lost their edge. They get attached to their existing code, and resistant to making changes that might require major alterations to it. To the point of pushing back hard against new business goals. I think that from the business folks' perspective, you might say they're no longer playing to win, they're just playing to not lose. Which, in many portions of the tech space, is a recipe for inexorable decline.
from-nibly 2y ago
I think lethal is a bit exagerated. I think developers often underestimate the resilience of a company. Howrver, if you read the related programming as theory building it explains these thoughts in greater detail. It explains a lot about how code becomes legacy and the friction that comes in from inheriting a 0 handoff software project.
- somestag 2y ago
  I'm continually shocked at how well companies can continue on despite serious internal problems. I do think it usually catches up with them though, and there are a lot of "terminally ill" products out there that are going to die eventually. I've seen those projects first hand, and I've seen the slow decay of the product that happens when a company loses control of its tech stack. It can take years. I think that cuts both ways though, because I think even the business people would be shocked at how well things can seem to work despite serious dysfunction. If an entire team dies off but 3 months later things seem "fine," the business types will just assume everything is as good as it ever was. I know it's popular these days to say that good tech and good business are not always the same thing, but I do think that many of those same businesses would be a little worried if you actually convinced them that their tech was coming off the rails and was only going to get worse. Some businesses just want to be acquired and don't care what happens after that, but not every business thinks they're on a clock. If you're big enough, like say you're a trillion dollar megacorp, then important teams folding up and being reborn is just part of your ecosystem. I've seen big tech power through churn for years with nothing but human wave tactics until the business climate changed enough that the team in question became less critical, and that's when they let it die.

by larrik 2y ago

f1shy 2y ago

My 2 cts: churn has objectively a cost. At some point that cost can kill a business. Where exactly is that point, depends on many different factors. There is to my knowledge, in this regard, nothing special about software, that cannot be said about other development activities.

bunderbunder 2y ago
I would guess that, like technical debt, churn is something you can have both too much and too little of. Stagnation also has a cost. When I work with teams that have had the same members for a long time, it seems that they've always lost their edge. They get attached to their existing code, and resistant to making changes that might require major alterations to it. To the point of pushing back hard against new business goals. I think that from the business folks' perspective, you might say they're no longer playing to win, they're just playing to not lose. Which, in many portions of the tech space, is a recipe for inexorable decline.

from-nibly 2y ago

I think lethal is a bit exagerated. I think developers often underestimate the resilience of a company. Howrver, if you read the related programming as theory building it explains these thoughts in greater detail. It explains a lot about how code becomes legacy and the friction that comes in from inheriting a 0 handoff software project.

somestag 2y ago
I'm continually shocked at how well companies can continue on despite serious internal problems. I do think it usually catches up with them though, and there are a lot of "terminally ill" products out there that are going to die eventually. I've seen those projects first hand, and I've seen the slow decay of the product that happens when a company loses control of its tech stack. It can take years. I think that cuts both ways though, because I think even the business people would be shocked at how well things can seem to work despite serious dysfunction. If an entire team dies off but 3 months later things seem "fine," the business types will just assume everything is as good as it ever was. I know it's popular these days to say that good tech and good business are not always the same thing, but I do think that many of those same businesses would be a little worried if you actually convinced them that their tech was coming off the rails and was only going to get worse. Some businesses just want to be acquired and don't care what happens after that, but not every business thinks they're on a clock. If you're big enough, like say you're a trillion dollar megacorp, then important teams folding up and being reborn is just part of your ecosystem. I've seen big tech power through churn for years with nothing but human wave tactics until the business climate changed enough that the team in question became less critical, and that's when they let it die.