Your middle manager likely cares less about your productivity than about sucking up to those above your middle manager in the hierarchy, and your productivity is at best only tenuously related to that.

In fact your middle manager is responsible for enforcing the C-suite's directives on you. Any deviation from that, even if it increases your productivity, is likely to result in punishment rather than reward for your manager.

So true, our company monitors PR counts, it’s all pushed from higher level execs. So my manager, the middle manager, tells us, “make sure your PR counts do not stand out negatively” and pretty much independently of this, make sure you deliver value. We need to keep the PR count up, so that execs see charts going up, and need to work on things that matter so that they don’t realize those are BS metrics to enforce. The thing is measuring what matters is not trivial for software engineering, so they measure what’s easy to measure, and they can pat themselves on the back for being data driven.

And while PR counts and friends aren't a metric to measure people by, that sure are a signal to keep an eye on.

It measures what matters - it helps identify potential problems. Maybe your process started slowing people down, maybe your CQ/CI became a royal pain, maybe a problem is much harder than expected - and maybe some people are slackers.

Or do you mean being more productive doesn’t automatically translate to it being visible.. yeah that is a tricky one..

Their goal is to attach their name to as many features/initatives as possible, owning the successes and orphaning failures, to impress their bosses. Another related goal is to have as many reports as possible. Delivery is relative to the average velocity: often, it's preferable to have a slow, inefficient operation so you can sandbag your bosses AND increase your headcount.

When it comes to improving processes and tools, managers prefer low-risk, iterative improvements which they can (somewhat) grasp. They also enjoy one-off prototypes and half-baked hacker projects which use new and shiny technology. Both categories make great fodder for PowerPoint presentations in front of shirts.

When it comes to larger, fundamental shifts which they cannot grok nor plausibly attach their name to, many managers will actively impede such efforts, as this risks upsetting the status quo which is (probably) working for them. The exceptions are usually the smart middle-managers looking to create a rising tide.

I've worked at a company that had dozens upon dozens of teams working on precisely the same problems (standard build->deploy->test->release fare), using many of the same tools, each with their own half-baked and poorly maintained configuration, plugins, dependencies, and custom libraries (sometimes, they even wrote a few tests!).

You can probably guess the majority of the proposal I put together, it's foundational stuff. It was presented and discussed among our senior+ engineers, and with managers.

>"You know... maybe there's value in letting teams be innovative..."

More precisely about benefit derived from the delivery. Best case scenario is the team is part of the benefit thinking but that is not a given. Also the layer above may engineer a situation where team and manager benefits from delivery are in conflict.