4 ms·

My suspicion is that a lot of this comes down to budget pressure causing management to constantly discourage efforts by technical teams to invest time in the qu

• nine_zeros 3y ago
  > My suspicion is that a lot of this comes down to budget pressure causing management to constantly discourage efforts by technical teams to invest time in the quality of their systems rather than push out more features. This is only partly true. It is true that management sometimes faces budget pressure. But the real skill lies in what they do next. They could - easily - come up with a strategy of feature delivery, and communicate it clearly. Ask engineers to pause red tape, be scrappy for the next few quarters, talk to dependent teams to make certain flows easier. Explicitly use their authority to set the rules aligned with leadership. But this is not what they do. The average management simply pushes indirectly, via 1:1s or individual blaming. > After the manager declines to invest in engineering quality a few times, they have sent a clear message that quality and reliability are secondary to the desire to get things our the door. Then they blame the staff for their mistake. Truth.
  • hinkley 3y ago
    It's not what down-managers do. It is what up-managers do. And you can see this passion play coming a mile away if you figure out which one of these you have when times are still good.
• CraigJPerry 3y ago
  >> a lot of this comes down to budget pressure causing management to constantly discourage efforts by technical teams to invest time in the quality of their systems Anecdata follows but I’m certain this has been getting better in recent years. It’s more common today for management to be swayed by data - my recollections of the 2000s were interactions more along the lines of “I’ve been doing this for 20 years son, whatever your little spreadsheet contains, I’ve already accounted for just by feeling the air in the room through my superb gut”. - management at that time had gone from playing with Sinclair spectrums in their bedrooms to leading huge multimillion dollar teams, partly because software development had exploded and someone needed to lead those teams. So several managers I ran across seemed to see their position as a result of their greatness and not really anything at all to do with growth in the industry leading to bigger roles needing filled. This is a long way to say it used to be very hard to penetrate a charismatic self-aggrandising tech leader’s thought bubble. Today I definitely see it as different. E.g. if you rock up with a download of CI job runtimes and a couple of off the cuff quotes from team members about what they do when waiting for CI builds (I.e. not much of value), I’d expect you to pretty easily succeed in establish a case for investing in speeding up that feedback loop and the outcome / measured results chart of that work would likely make its way through at least a couple of senior management slide decks over the next few weeks.
  • slotrans 3y ago
    > E.g. if you rock up with a download of CI job runtimes and a couple of off the cuff quotes from team members about what they do when waiting for CI builds (I.e. not much of value), I’d expect you to pretty easily succeed in establish a case for investing in speeding up that feedback loop and the outcome / measured results chart of that work would likely make its way through at least a couple of senior management slide decks over the next few weeks. No you will be waved away like always, they don't care. Features features features, nothing else matters.
    • breischl 3y ago
      If your management is waving off the waste of something so immediately convertible into dollars as their (probably) highly-paid engineers' time, then they're idiots. Usually the hard part is collecting the numbers and defending their validity.
  • PH95VuimJjqBqy 3y ago
    Did it ever occur to you that perhaps you're the one dismissing them by claiming they only got there because the industry was growing?
  • deleted 3y ago
    [deleted]
• joeig 3y ago
  I think it helps to speak the same „language“ as the manager. Add price tags to the infrastructure development or technical debt. This may add an important perspective to the discussion for both sides.
  • chopin 3y ago
    But exactly that is hard. Backups have a high price tag when missing but none when not needed.
    • VierScar 3y ago
      Similar issues happen for justifying security. But if you've got a price tag, then just do expected utility. What's the odds that you'll need a backup? 1%? 0.1%? Per year? And what's the value of that backup price tag during that time? $10m? 0.1% per year * 10m = 10k per year.
      • deleted 3y ago
        [deleted]
    • mateo411 3y ago
      Give the price tag when missing. The argument is we need to fix this in order to insure against this catastrophic event. Or take the price tag when missing multiply by the probability of needing it over the course of one year. This is a more accurate estimate for the annual cost of not creating the backup.
  • madeofpalk 3y ago
    As developers you should be doing this anyway to understand why you want to do something. Gut feeling for "it's just better" doesn't get you far - no wonder you can't get anyone else on board.
• lasereyes136 3y ago
  > Then they blame the staff for their mistake. That is the behavior of a pathological leader in a pathological organization. It is all too common.