We consider the role of a first level manager as both producer and consumer of status.
In Reinventing Status Reports we first start thinking of how federation and reflection combine to enable the "collaborative interpretation of status" or Status Reports 2.0 if you will.
Uploaded image
Our integration of neighborhood sitemaps makes clear that careful enumeration of collaborators creates a "status space" where the activity has implicit meaning.
See Ward and Michael's Westwind collaboration as viewed from the rollup site. website 
See also Heroku's status page for some graphical inspiration. website .
First some assumptions:
1. Status reporting provides the situational awareness that allows a company to both prepare and act.
2. Status reporting is best as a "conversation of record" between roles we might call status makers and status interpreters.
3. A first level manager is a status interpreter in the conversations with developers and a status maker in conversations higher up.
And now conclusions:
1. A first level manager should keep two wikis, one with clones of pages from developers, a second with pages to be cloned in the act of "making status" headed upward.
2. A manager reports upward by cloning content from one conversation in to the upward facing wiki of the second conversation.
3. A manager is expected to "interpret" status into a form that is actionable above as part of this cloning (and refactoring) process.
This is where my Federation Changes mechanism shines. Because it picks up information from the neighborhood, the first level manager simply consults the neighborhood that matters at a given time. See About Activity Plugin.
There are three conversational "situations" that need attention: 1. conversing with reports; 2. conversing with superiors; and (this surprised even me) 3. conversing with yourself as you pull thoughts back and forth.
We've decoupled reflection from reporting and find this to be quite a relief. See Status Deployment Report
todo: case analysis within each situation.
todo: steps and affordances for each case
todo: requirements for pilot study
todo: look into feeding git logs into sfw