OKR: 2020 Q1 Scoring

[mikeal]

I need to get scores in from @vmx, @rvagg @warpfork and @creationix

[warpfork]

Added my scores. Also want to share what I put in the commit message somewhat more visibly because it might be a useful lesson:

(Possible lesson for future: might not be wise to target an OKR to more than one repo at a time: odds of getting halted in one and not the other because of transitive dependencies or other logistical issues is higher than not. At which point it becomes debatable how to score progress, and how someone at a distance could interpret that score.)

This was the case in one of my lines because it refers to "Selectors/Graphsync". Selectors got the updates described, 100% completely. Graphsync and further downstream did not. (It should surely be close; but when to engage it is a question best left for whoever's going to integrate that and do flow-control on changes in those downstreams.) And I consider this outcome both successful, and probably should've identified it as a likely one well in advance... which might suggest it's appropriate to track them separately.

Possible countpoint? Putting OKR entries with dependencies on other OKR entries is almost always also losing something in communication: dependency isn't clear in OKR format; "P{n}" values don't really indicate dependency either and hacking them to have that double-meaning creates a mess; we regularly would expect the things farther on the dependency path to get pushed out or be seen as stretch goals, and yet nothing communicates this. So, maybe reporting a combined item the way we did this time around is actually better, even though it sacrifices clarity in other ways and makes things seem incomplete when they're not and doesn't indicate where the baton stopped (and thus hint what could be most useful to pick it up).

Hm. Every choice seems wrong and miscommunicative. I guess I still don't actually like OKRs very much for planning work at our scale. It feels like if we were using them at a vastly bigger scale, and to describe things that are amorphous vague goals that we apply structure to via OKRs, then they might be more applicable... but using them to describe work items? Really feeling like it generates more mislead and noise than truth and clear signal.

(Take this as "two cents" notes. I just want to keep a log of what's working and what's not working organizationally, as I feel the pain. We don't have to do anything about it, but if we do decide to, this can be reference material input to future process consideration.)

[warpfork]

(Continuing those "two cents" just a bit more, in anticipation of some of the "you're holding it wrong" comments I can already imagine...)

"You're not supposed to use OKRs for work items"

Well, yeah, sure.

But consider the following: we use OKRs on a quarterly cycle.

If we try to write the OKRs to describe big, amorphous, Theory-of-Change-scale things (handwave), then for a team this size...

• we would have the same OKRs, with minor revisions, repeatedly. The vision isn't shifting that fast, and the road ahead is long. None of our vision-scale goals suddenly land in a quarter. We know this.
• if OKRs require DRIs, and we have about as many OKRs as we have people, then... look five minutes in the future, this writes itself: of course they degenerate to personal work items. Especially for a team of people with additional area-of-focus dividing lines based on language specialty, which is by nature what we have (and wouldn't have it any other way).

So, it's natural that if we start with "use OKRs; do them quarterly; we expect OKRs to change and be topical every quarter", the info flow degenerates to work items. This will just happen, time and time again, given the same scenario. It doesn't really help to just say "don't do that" if everything else about the setup and structure quietly says "this is the only thing that makes sense to do". If we don't like OKRs full of work items, then...

"Ok, so don't use OKRs on a quarterly cycle then."

Well, yeah, okay.

But we're using them as an attempted form of communication with larger entities who want briefer summaries.

(And that does provide real value. I wanna be clear here: I'm not trying to throw summary communication under the bus; I'm not trying to say "summaries are impossible, let's go shopping"... this whole brace of notes started off as remarks on some very specific ways in which our summaries are structurally inclined to inaccuracy, and this is all written out of a desire to improve on that.)

And somehow that gets quarters involved.

So, this means that if we want to change things, it's a larger conversation, and needs to be engaged at that scale.

Nothing's ever simple, is it. :)