| I would frame this slightly differently: managers care about delivery above all else, not necessarily productivity or efficiency. 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.