I used to manage a developer whose claim to fame was how many "story points" they crushed. There was no rhyme or reason to their work, they would never say no t

I used to manage a developer whose claim to fame was how many "story points" they crushed. There was no rhyme or reason to their work, they would never say no to anything, and it didn't matter if their changes caused performance regressions or added broken windows to the code base: closed was closed and nothing else mattered. Working with them was difficult: they saw themselves as this productivity machine but the rest of the team was dealing with all of the extra work their productivity brought: more outages and incidents, code complexity, etc. I can't tell if that's what you're doing but it was a good lesson for them to think more strategically and be focused on what matters to the team and to them. Being able to deliver and make progress at a reasonable pace is a good thing but, in our case, delivering lines per hour was not the metric we were measuring. Maybe what you need to do is have an honest conversation with your team or team lead. What does the team value? What are the expectations? Update: fixed spelling/grammar