In today’s meeting, I triggered some churn in the format of the notes document (https://snowdrift.sylphs.net:8002/p/meeting). I apologize for that. I had a legitimate issue with the formatting, but I wasn’t in charge of keeping notes for the meeting, so going and actually reformatting it was overstepping—especially since I did it in real-time.
And now for something almost entirely unrelated. In a previous meeting, I suggested adding a “metrics” segment to the document, which was duly added. I didn’t make it clear what I intended for that section, so let me do it now. Consider what follows my “meeting metrics proposal”. If adopted, we should probably document this in our governance repo.
Meeting metrics proposal
Meeting metrics are measurable things, ideally numbers, that are mentioned in a meeting. Including them provides some helpful accountability and gives the organization a heartbeat.
Adding and removing meeting metrics is a decision made within the meeting proper. Individuals are encouraged to measure as many things as they want for their own purposes, but adding metrics to a meeting impacts everyone within the meeting, so they need to be a given a chance to object. Is it pointless? Is it measuring the wrong thing? Is it really a measure, or is it a check-in? (The latter belongs to the agenda.) Can I chart it on a graph?
I’m sure I’m duplicating existing work that describes metrics. If someone wants to dig up a better description that what I’ve provided or that provides good nuance/justification/context, please do so!
Here’s one nuance: if there’s something that you’d like to be a metric, but can’t think of how to make it measurable/graphable, create an agenda item to discuss it[1]. There are lots of ways to make a thing measurable, but it requires creativity: something many minds working together are good at fostering.
Thank you, I really appreciate both the mindfulness/reflection and the apology.
I agree with your issue. However, after a couple iterations, I actually ended up reverting the format to what it was, plus a few cosmetic (etherpad-only) changes.
The current format came from a series of iterations to solve specific problems, and none of the things I tried today were able to resolve your issue without re-creating the issues from earlier iterations.
I’m happy to keep iterating. I think I’d prefer to do it in real time, though. Too much effort to polish my thoughts enough to be worth posting.
One nuance / potential source of confusion: we have a check-in round which is explicitly not for status updates on work (it’s for sharing your mindset and getting distractions out in the open, so they can be put aside).
Separately, there’s updates on work. They are agenda items; it’s valuable to cover them first. Today I tried putting them in the same section as metrics, but didn’t communicate this well. Sorry about that.
I think we should try it for a couple weeks, then put it into the governance docs if we stick with it. Letting conversations like this document short-term/experimental changes before codifying them in the governance docs seems like a good tradeoff between flexibility and clarity to me.
In a previous meeting, I suggested adding a “metrics” segment to the document, which was duly added. I didn’t make it clear what I intended for that section, so let me do it now. Consider what follows my “meeting metrics proposal”. If adopted, we should probably document this in our governance repo.