Status reporting within orgs

Story time:

Back in my first job out of school, when I didn't really have much broad context on software development, I was working for Lockheed Martin as an entry-level developer. One of my weekly tasks was to write a status report email to my manager, in paragraph form, describing all the things I had been doing that week, and the value that they provided for various projects and initiatives. This was something which all the developers in the team needed to do, and my understanding was that it was a fairly common thing in the company (and by assumption at the time, within the broader industry).

At some point, I was asked to also write these in the third person, which was a bit odd, until I realized what was going on with them. My manager was aggregating them into a larger email communication to his manager, in which he was informing his management as to all the value that his team was providing under his "leadership". I don't know to what extent he was taking credit for those accomplishments (explicitly or implicitly), but I do know that he didn't do anything directly productive per se: his entire job was attending meetings and writing reports, as far as I could tell (Lockheed had separate project management and people management, and he was my people manager, so not involved in any projects directly). I rarely spoke to him, aside from sometimes providing on-demand status updates, or getting information on how to navigate corporate processes as necessary.

Furthermore, my understanding was that there was an entire hierarchy of "people managers", who all did only that: composing and forwarding emails with status information, and helping navigate corporate processes (which in many cases, they also created). Their time was also billed to projects which their reports were attached to, as "management overhead".

I raise this point because, as my career progressed, I realized this was not uniform practice in the industry. In fact, practices like Agile explicitly eschew this methodology; Agile strongly promotes developer agency and trust, minimizing process overhead, developer team self-organization, and only reporting blockers as necessary. In large part, Agile is built upon the premise that organizations can eliminate status reporting and still get good outcomes in terms of product development; or, implicitly, the presumption that middle managers receiving and forwarding status reports provide little to no value to the overall organization.

I've always found that presumption interesting, and I think it's very much an open question (ie: value vs cost for management). I've experienced what I would consider to be good managers; these are people who do not add much overhead, but efficiently unblock development efforts, usually through come combination of asymmetric communications, resource acquisition unblocking, or process elimination (ie: dealing with process overhead, or eliminating it entirely). I've also experienced managers who I thought provided very little value in my perception; these are people who frequently ask for status reporting information, mainly just "pass the buck" when blockers arise, and seem unable to reduce or offload any overhead (and/or add more). Those "low value" managers can also add substantial overhead, particularly when they do not understand technical details very well, but nevertheless involve themselves in technical discussions, and thus require additional hand-holding and people management efforts to "manage up", and try to prevent these individuals from making bad decisions (which might contravene or undermine better decisions by people under them in the company hierarchy).

So, then, the next open question is: how does an organization differentiate between "good" and "bad" management, as articulated here (if they were so inclined)?

In my mind, I'd start with looking at the amount of status reporting being done (in light of the Agile take on the overall value of such), as a proxy for how much value the management is providing, vs overhead they are creating. Obviously reports could also be surveyed as another indirect measurement for this, although there is inherently more bias there, of course. But generally speaking, ideally, status information should be communicated and available implicitly, via the other channels of value-add which a good manager is providing (eg: by providing general career advice to reports, and mitigating overhead for people, a manager should then be implicitly aware of the work efforts for their reports). If explicit status reporting is necessary and/or solicited, that could be a sign that the value-add being provided by the other activities is not extensive, and be a point of concern for the org.

Anyway, those are some of my thoughts on the topic, and as-noted different orgs have different approaches here. I don't think there's a "right" or "wrong" here, but I do think there are tangible trade-offs with different approaches, which means it is a facet of business where there is potentially room for optimization, depending on the circumstances. That, by itself, makes it an interesting point of consideration for any organization.