Examples could be around:
- Find ways to cut costs - Solve an organizational/process issue - Make something more efficient
Can be a one-off or ongoing thing.
But the company has been hellbent for several years on diminishing the number of engineers and the influence that engineers have, and we are just on a slow march towards the next major accident. But until somebody dies, nothing will really change.
The salami-slicing reduction in engineering decision-making authority also means that there is no path to escalate issues.
There's a discontentment felt by every engineer in the organisation resulting in cynicism and disengagement, and yet to hear the upper management speak, we are all bursting with excitement at what exciting times we are living in, and relishing the diversity and inclusion.
I don't know what the answer is but I think code reviews are fundamentally broken. They need to be more dynamic and more intelligent, simply requiring a code reviewed by someone is close to worthless.
If I'm the JavaScript expert then I should be able to tag myself as such so I know about every piece of JavaScript that's going into the codebase before it's merged. But more importantly, if I'm the expert on some section of the codebase I should be able to "lock" that code to myself in such a way that any changes to that code must first go through me.
Maybe this kind of thing is already possible, but I've just not seen it. Half the time code reviews are worthless because it's one dev who doesn't really know what they're doing reviewing code of another dev who doesn't really know what they're doing.
Edit for motivating factors.
Not sure if it's interesting to tackle. ;)