5 ms·

That's why you stop asking permission to make quick fixes and just submit the PR. Obviously there is a balance here but if you can't "steal" a few hours in a we

That's why you stop asking permission to make quick fixes and just submit the PR. Obviously there is a balance here but if you can't "steal" a few hours in a week from the product driven roadmap to do so then there is something wrong in the engineering culture.

rrrrrrrrrrrryan 4y ago
Do any orgs explicitly ask the engineers themselves decide how to allocate a certain percentage of story points in a given sprint? Product people are great for selecting which features to build out and which bugs to address, but are poorly equipped to decide how to prioritize things like: performance optimizations, bugfixes that haven't (yet) been reported by the end users, code refactoring, paying down tech debt, modernizing tooling, misc quality of life improvements for the engineering team, etc.
- Drew_ 4y ago
  My last org did exactly that. The team lead that runs sprint planning was always an engineer. Product management is still there for direction and context, but the decision maker was always an engineer. I don't think this is particularly special way to do it, but I might be wrong.
- lmm 4y ago
  My first job worked like that. We explicitly had a 25% stream of technical improvements. It worked pretty well.
  - tomschlick 4y ago
    Same. When I was a team lead I always pushed for 30% of all story points being for maintenance / tech debt that product couldn't touch.
w0mbat 4y ago
Absolutely. If something is oddly slow, I run the profiler to see what's going on. If the profiler shows me something boneheaded like this that is a big win to fix, I fix it. Obviously I make sure the tests still pass, but then I check it in. If someone is going to give me shit for improving the product, that is not somewhere I want to work.
- tomschlick 4y ago
  The boy scout "leave it better than you found it" mantra has always served me well. Hell, sometimes that small fix can lead you down a rabbit hole that uncovers fixes to larger problems that have been plaguing an app for an eternity.
  - dylan604 4y ago
    What of those odd stories where somewhere else in the code another dev realized the segment of code was doing strange things and create a work around that now breaks because of the cowboy anything goes attitude changes? Usually with comments talking about it "being very weird to do this, but it works"
    - tomschlick 4y ago
      If the tests dont fail thats not my problem.
rendaw 4y ago
The solution is for ICs to stick their necks out, go over the product manager's head, and ignore the org chart? Not get a new product manager who cares about the product?
- tomschlick 4y ago
  The product manager shouldnt be the boss of an engineer. Thats what engineering managers are for. Product / Eng managers work together to set goals of what they want done, it shouldnt include how they want it done, and exclude potential side fixes. Thats how you kill the morale of an engineering team.
- billllll 4y ago
  I agree with Tom: a well functioning eng org allows engineers to fix critical bugs without going through a bureaucracy. This empowers the engineers and makes them a product owner as well, though you need good engineers who care. If you force every little bug to go through the product manager, you take time away from the PM to do big picture things by forcing them to track every little thing that's broken, and create a lot of friction for even the littlest bug to be squashed. This fosters an eng culture of "not my problem," which leads to bugs slipping through the cracks for years.
gabereiser 4y ago
Ask for forgiveness not for permission. Whole heartedly agree.
DeathArrow 4y ago
>That's why you stop asking permission to make quick fixes and just submit the PR. If the company pays me to close tickets and Jira stories, why should I care about improving its products? If the company pays me to actually improve its products, then sure, I would do that.
- superjan 4y ago
  Usually for perf issues like this, you and your colleagues also suffer. It is not just the time you lose waiting, but you also drop out of flow/get distracted and your productivity suffers more. The end user gains are just a side benefit.
- vexna 4y ago
  Because the existence of the problem bothers you implicitly. Or because it’s usually a good way to a promo

rrrrrrrrrrrryan 4y ago

Do any orgs explicitly ask the engineers themselves decide how to allocate a certain percentage of story points in a given sprint? Product people are great for selecting which features to build out and which bugs to address, but are poorly equipped to decide how to prioritize things like: performance optimizations, bugfixes that haven't (yet) been reported by the end users, code refactoring, paying down tech debt, modernizing tooling, misc quality of life improvements for the engineering team, etc.

Drew_ 4y ago
My last org did exactly that. The team lead that runs sprint planning was always an engineer. Product management is still there for direction and context, but the decision maker was always an engineer. I don't think this is particularly special way to do it, but I might be wrong.
lmm 4y ago
My first job worked like that. We explicitly had a 25% stream of technical improvements. It worked pretty well.
- tomschlick 4y ago
  Same. When I was a team lead I always pushed for 30% of all story points being for maintenance / tech debt that product couldn't touch.

w0mbat 4y ago

Absolutely. If something is oddly slow, I run the profiler to see what's going on. If the profiler shows me something boneheaded like this that is a big win to fix, I fix it. Obviously I make sure the tests still pass, but then I check it in. If someone is going to give me shit for improving the product, that is not somewhere I want to work.

tomschlick 4y ago
The boy scout "leave it better than you found it" mantra has always served me well. Hell, sometimes that small fix can lead you down a rabbit hole that uncovers fixes to larger problems that have been plaguing an app for an eternity.
- dylan604 4y ago
  What of those odd stories where somewhere else in the code another dev realized the segment of code was doing strange things and create a work around that now breaks because of the cowboy anything goes attitude changes? Usually with comments talking about it "being very weird to do this, but it works"
  - tomschlick 4y ago
    If the tests dont fail thats not my problem.

rendaw 4y ago

The solution is for ICs to stick their necks out, go over the product manager's head, and ignore the org chart? Not get a new product manager who cares about the product?

tomschlick 4y ago
The product manager shouldnt be the boss of an engineer. Thats what engineering managers are for. Product / Eng managers work together to set goals of what they want done, it shouldnt include how they want it done, and exclude potential side fixes. Thats how you kill the morale of an engineering team.
billllll 4y ago
I agree with Tom: a well functioning eng org allows engineers to fix critical bugs without going through a bureaucracy. This empowers the engineers and makes them a product owner as well, though you need good engineers who care. If you force every little bug to go through the product manager, you take time away from the PM to do big picture things by forcing them to track every little thing that's broken, and create a lot of friction for even the littlest bug to be squashed. This fosters an eng culture of "not my problem," which leads to bugs slipping through the cracks for years.

gabereiser 4y ago

Ask for forgiveness not for permission. Whole heartedly agree.

DeathArrow 4y ago

>That's why you stop asking permission to make quick fixes and just submit the PR. If the company pays me to close tickets and Jira stories, why should I care about improving its products? If the company pays me to actually improve its products, then sure, I would do that.

superjan 4y ago
Usually for perf issues like this, you and your colleagues also suffer. It is not just the time you lose waiting, but you also drop out of flow/get distracted and your productivity suffers more. The end user gains are just a side benefit.
vexna 4y ago
Because the existence of the problem bothers you implicitly. Or because it’s usually a good way to a promo