4 ms·

This sounds terrible and I would leave this team fast. I work in a high performing FAANG team. Deadlines get pushed all the time

bumby 4y ago
Does one ever question why deadlines constantly get pushed? At best, it means those high performers are bad at setting initial deadlines. Or is it that meeting deadlines isn't considered a performance metric? Now if deadlines are important, maybe it's just relative performance that you're speaking to. So if everyone misses deadlines you can still be high-performing, but it's like saying you're the skinniest kid at fat camp. It's normalization of deviance, and not a trait of high performing teams.
- xxpor 4y ago
  Because setting precise deadlines is nearly impossible without a massive investment up front, that companies aren't willing to make. Software engineering projects aren't run like a civil engineering project where you have precise blueprints done before you set construction timelines. There's also a big difference between being a month late and a year late. It's also a lot easier to explain you're going to miss a deadline 3 months in advance than a week before. You don't get high performing teams by forcing crunch time because the deadline is the deadline. This is also why I'm grateful not to work in video games; you can't reschedule Christmas.
  - bumby 4y ago
    >Software engineering projects aren't run like a civil engineering project where you have precise blueprints done before you set construction timelines. Ironically, the civil engineering projects are one of the best examples of missed budgets and schedules. Almost every civil project at large scale becomes rife with change orders because coordinating different domains is complex, even if those domains have "precise" blueprints. Those blueprints always change, which is why the industry has "design" documents and "as-built" documents. So what do you think it is? Why do they have an inability to coordinate large complex pieces of a project? Optimism bias? Can we really call someone a high-performer when they display those shortcomings? Or do we just normalize them so they aren't considered a problem?
- greatpostman 4y ago
  The software is way too complex to gauge how long something will take. It’s also extremely risky to make a mistake in production. Projects slated for three months can take two years. If you’re engineers are constantly hitting deadlines, probably it’s greenfield development or the problem space is simple
  - bumby 4y ago
    I agree. But if we don't manage it well at scale, that underscores that we don't really understand the complexity of the problem. Can you call someone a "top performer" when they don't understand the complexity of the problem? We can write complex code with minimal errors[1]. "the last three versions of the program — each 420,000 lines long-had just one error each. The last 11 versions of this software had a total of 17 errors. Commercial programs of equivalent complexity would have 5,000 errors." But I worry when we facilely normalize sub-optimal behavior because we've normalized it. Especially as FAANG and adjacent companies work on safety-critical software and when that attitude pervades other domains. [1] https://www.fastcompany.com/28121/they-write-right-stuff https://www.fastcompany.com/28121/they-write-right-stuff

bumby 4y ago

Does one ever question why deadlines constantly get pushed? At best, it means those high performers are bad at setting initial deadlines. Or is it that meeting deadlines isn't considered a performance metric? Now if deadlines are important, maybe it's just relative performance that you're speaking to. So if everyone misses deadlines you can still be high-performing, but it's like saying you're the skinniest kid at fat camp. It's normalization of deviance, and not a trait of high performing teams.

xxpor 4y ago
Because setting precise deadlines is nearly impossible without a massive investment up front, that companies aren't willing to make. Software engineering projects aren't run like a civil engineering project where you have precise blueprints done before you set construction timelines. There's also a big difference between being a month late and a year late. It's also a lot easier to explain you're going to miss a deadline 3 months in advance than a week before. You don't get high performing teams by forcing crunch time because the deadline is the deadline. This is also why I'm grateful not to work in video games; you can't reschedule Christmas.
- bumby 4y ago
  >Software engineering projects aren't run like a civil engineering project where you have precise blueprints done before you set construction timelines. Ironically, the civil engineering projects are one of the best examples of missed budgets and schedules. Almost every civil project at large scale becomes rife with change orders because coordinating different domains is complex, even if those domains have "precise" blueprints. Those blueprints always change, which is why the industry has "design" documents and "as-built" documents. So what do you think it is? Why do they have an inability to coordinate large complex pieces of a project? Optimism bias? Can we really call someone a high-performer when they display those shortcomings? Or do we just normalize them so they aren't considered a problem?
greatpostman 4y ago
The software is way too complex to gauge how long something will take. It’s also extremely risky to make a mistake in production. Projects slated for three months can take two years. If you’re engineers are constantly hitting deadlines, probably it’s greenfield development or the problem space is simple
- bumby 4y ago
  I agree. But if we don't manage it well at scale, that underscores that we don't really understand the complexity of the problem. Can you call someone a "top performer" when they don't understand the complexity of the problem? We can write complex code with minimal errors[1]. "the last three versions of the program — each 420,000 lines long-had just one error each. The last 11 versions of this software had a total of 17 errors. Commercial programs of equivalent complexity would have 5,000 errors." But I worry when we facilely normalize sub-optimal behavior because we've normalized it. Especially as FAANG and adjacent companies work on safety-critical software and when that attitude pervades other domains. [1] https://www.fastcompany.com/28121/they-write-right-stuff https://www.fastcompany.com/28121/they-write-right-stuff