The way we handle this is by padding our sprints enough so that there's always "extra time" at the end.
E.g: If we as engs think we can do 12 tickets in a one-week sprint, we commit to 8. This leaves room to pick up any production issue related work, address tech debt, and have some breathing room so we're not rushing through jira tickets.
It's also workplace specific, but imo product people shouldn't be engaging in daily standups other than passive observation. If they are drilling through the jira board and asking for status updates, they're taking on the role of a micro-manager, not a product owner/manager.
Standups should be engineers talking to eachother and raising blockers/issues that would prevent them from meeting the sprint goal they committed to, not daily check ins with product (again, imo).
If you want to contribute to the value of the organization because you're a substantial equity holder, then talk to the founders. A sweatshop with high turnover should be less valuable to an acquirer than a strong team. Your initiative may be well received as leadership and you can get your promotion that way.
If you want to stay in the organization and get promoted by performance metrics, then figure out what numbers are being evaluated and work to maximize them, so that you appear as the model worker. It's not very hard to stay one step ahead of management if that's the game you're playing. If you have the best relationships and the best metrics, you should be able to get your promotions.
If you want to stay in the organization and coast, then who cares, just do what you want and they're almost certainly not going to fire you without plenty of warning. If you do get put on a PIP, then go find a new job immediately, and repeat. From what I can tell, most of the workforce does something similar to this for 30-40 years.
If you're not a leader, not a model worker, and not on autopilot, then you probably need to find a new organization where you can be one of those things.
Not just a name, but a whole collection of essays characterizing modern corporate life. And you just managed to summarise its takeaway very eloquently in ordinary, everyday language.
Such organization is begging for a quickly written code full of bugs. Then you do some overtime fixing it, and you are a hero for a moment. But before you get promoted, you get sick because your body cannot handle all that stress anymore.
Sometimes you learn to play around the rules. For example, if you are required to report your progress every day (and "sharpening the axe" is frowned upon), a possible solution is to report on Friday morning only half of what you did yesterday, and keep the rest for the Monday report.
The beauty with imaginary numbers (sometimes known as story points), is that that they are just that — imaginary. And as the dev, you know how to massage them to your liking.
Man, I wish this is how my last place did it. Instead, if we were getting through 12 we'd commit to 14 and then the dev manager would wonder why stuff wasn't getting done.
E.g: If we as engs think we can do 12 tickets in a one-week sprint, we commit to 8. This leaves room to pick up any production issue related work, address tech debt, and have some breathing room so we're not rushing through jira tickets.
It's also workplace specific, but imo product people shouldn't be engaging in daily standups other than passive observation. If they are drilling through the jira board and asking for status updates, they're taking on the role of a micro-manager, not a product owner/manager.
Standups should be engineers talking to eachother and raising blockers/issues that would prevent them from meeting the sprint goal they committed to, not daily check ins with product (again, imo).