• SorteKaninOPA
    link
    fedilink
    arrow-up
    26
    ·
    10 days ago

    I was kinda baffled by this too. I like the general idea that they present (you need to pay your own long-tenured engineers higher than market rate cause they actually know more about your own system), but this idea of a formula? What, are you gonna start counting git commits? A formula sounds like a super weird way to solve that problem.

    Just look at the engineers that add value in your company and pay them a fair market rate. When someone leaves, find out what salary they get in the new job and ensure all your remaining engineers get at least that amount and adjust as you go along. Something like that perhaps.

    • wewbull@feddit.uk
      link
      fedilink
      English
      arrow-up
      15
      ·
      10 days ago

      Sometimes your longest serving engineers can be your biggest anchor. Good engineers are (justifyably) highly opinionated about what can be done, but sometimes it turns into “what I do works, so all other ways are wrong”. At that point the best move for them might be to go learn how somebody else does it. Wish them well, and back a different horse.

      • Lysergid@lemmy.ml
        link
        fedilink
        arrow-up
        2
        ·
        10 days ago

        Though in reality, management will push back any unorthodox approaches/solutions/approaches as risk and additional losses on R&D.

    • lad@programming.dev
      link
      fedilink
      English
      arrow-up
      4
      ·
      10 days ago

      The hard part is “that add value”. Not only it’s hard to measure, but highly depends on scope of what is done

    • haulyard@lemmy.world
      link
      fedilink
      arrow-up
      2
      ·
      edit-2
      10 days ago

      Counting commits is exactly the type of stuff starting to happen. linearb.io for example. I’m seeing this used as a way to rank dev value under the guise of “we’re just trying to help teams improve throughput”

      edit: corrected url