There’s been a lot of talk about this at Slack but with a very limited audience, and I just thought I’d open a simple Discuss post where people can share their thoughts.
I couldn’t vote on them because my SNT was on hardware wallets when the contract got created.
For developer OKRs I would prefer that we focus on “feature” OKRs like Implement perfect forward secrecy for chat, including draft of a formal spec rather than off-ground OKRs with random numbers like Increase chat daily active users by 500% (currently at < 400 DAUs) to have more relatable goals.
During finalizing OKRs, we came up with the Wall Of Shame. That was really insightful document. The same goes to principles definition that objectives should derive from or be benchmarked by.
What could’ve gone better?
It was not clear to me how OKRs proposed by the core team and community got merged and finalized.
Some OKRs were very abstract without a specific plan how we wanted to achieve them. I am not sure if that’s the proper way of doing it because when we measure objectives later, we measure a lot of unknowns and research.
How would you prefer we do them for Q4?
It was mentioned that team OKRs should play bigger role. I am not sure about it but worth to consider.
It would be nice to have more abstract overall goals for the Q4 but OKRs should be less abstract. For example, “Solve cluster as a single point of failure” as a goal and a few objectives that will make it happen but at the same time being measurable.
Ditto Adam; the wall of shame provided helpful clarity on what is critical to Status.
What could’ve gone better?
In my opinion, the brainstorming phase was a bigger issue than even the SNT voting and all its complications.
I’ve got a friend who is a former PM at Google and shed some light on her experience with OKRs. Her team always had multiple meetings dedicated to evaluating the current work and product performance, and discussing future goals. All key stakeholders were involved, and it was a surprise to no one when a team announced their OKRs, because so much thought and effort had gone into determining them.
Two things seem to be preventing this level of engagement at Status:
The difficulty of remote brainstorming. I’ve yet to successfully have a robust discussion about anything over video conference. Async collaboration seems to be more effective, but in the case of Q3 OKRs, there was low engagement with the thought starter doc I pulled together, possibly because…
People don’t care that much. If they cared, they’d speak up.
How would you prefer we do them for Q4?
For Core, I think we should have team-level OKRs rather than one set of OKRs that applies to all teams. Teams having their own OKRs will be more relevant and create more accountability.
I think that POs/TOs and swarm leads should be responsible for brainstorming on OKRs and bringing suggestions to their teams. Anybody else who is interested in the brainstorming process can of course participate, but team leaders should be accountable.
Once OKRs are determined and prioritized with SNT voting, perhaps team members should cryptographically sign to indicate they fully acknowledge the team’s goals and are on board. Hopefully, major disagreements or feedback would arise before this stage.
The number of P0/P1 items was pretty manageable and made it easy to know what to focus on.
Also agree with Adam here, the WoS list made for a very good platform on which to frame future work and priorities.
I think visibility could greatly improve. The current Google Docs list is too crowded and could probably be pared down to only P0/P1 items after we’ve agreed on the priorities.
Having a one-stop dashboard site allowing us to see the progress of each team/organelle would help keep the OKRs front and center, as well as provide insight to the larger community on how we are doing in the quarter.
I have the impression that OKRs worked better at @previousJob, but on the other hand, they were totally top-down and handed down to the teams once per quarter, which of course is the opposite of our philosophy. The way it was organized was pretty easy to grasp though. You had company level OKRs, like “grow paying userbase by x%” and then a connection was made to team-level OKRs, like “launch Apple TV client app at WWDC”, and “improve funnel analysis” which would drive the user-base growth required to achieve that company goal. For the teams, it made for very actionable OKRs, while at the same time giving executives the high-level overview they needed.
Just brainstorming a potential timeline/approach given our F2F time in Prague:
Fri-Sun @ Hackathon. Existing teams/swarms (see other thread for semantics between the two, from now referred as swarms) get together and start to brainstorm ideas for OKR’s. The brainstorm should be done in an open forum/document (e.g. notes.status.im) where anyone can contribute ideas.
Any new swarms can also be formed during this time as well. Similar to [1], a new swarm brainstorms what can be built, as well as why the idea should be funded/will be impactful.
Team day (the Mon): Swarms collect the brainstormed ideas and perform dot voting (or similar) to help prioritise the best ideas.
Tuesday Oct 30: All OKR’s merge into a large Core pool, which is then voted on by the community (using the Voting DApp or similar) for a one week period. cc @Graeme for functionality consideration (e.g. using a hw wallet)
Week of Nov 5th The output should be a set of OKR’s prioritised by SNT holders. New or existing swarms will have clear ideas on the priority of their proposals.
Note: Some OKR’s could be picked to be experimented with, where Status Treasury and/or other CC’s can attach some sort of SITG for their success in a given time period (e.g. a swarm is given X SNT for executing on an OKR, then rewarded Y SNT based on their success as determined by the fund contributors).
Timeframe Proposal: Since it will be short quarter, and there is the Xmas/NY break in the middle, maybe we can consider Q4 + Q1 OKR’s be rolled into one long 4.5 month OKR timeframe?
I personally liked the direction the most important OKRs took, regarding living up our principles.
I don’t think that the async process for brainstorming went that well. If there is no specific time to brainstorm, it is very easy to be “too busy” to participate.
I would prefer an event (f2f or remote) to try to figure out
(1) the pool of ideas to vote for (let’s say we vote only for objectives).
(2) each objective should be split into KRs, to get more actionable tasks, this can be done in a smaller subset of people (PO/TO + anyone who wants to participate).
I think as @naghdy said Prague might be a good time for (1). (2) can be done remotely.
One more thing to think about is that we have this twice-a-year cadence of f2f off-sites. We might use each of that to think a bit more into the future and to have “tick” and “tack” OKRs where “tick” is more dramatic and discussed f2f, where “tack” process is remote, but more maintenance and course-correction oriented.
They helped give direction and drive our priorities. It was easier to understand how an idea aligned to the goals set by the OKRs.
What could’ve gone better?
Voting dApp, built specifically for gathering feedback about OKRs: Implementation resulted expensive for the final user, hence it did not have the expected volume/use. Also during this time, the network was sluggish, hence a higher gas price than normal. Also, we were lacking support for hardware wallets, which made lots of people not being able to vote.
Some ideas were discarded due lack of bandwidth / low priority (like Tribute to Talk) and were associated to key OKRs.
How would you prefer we do them for Q4?
OKRs should have a more prominent role. It would be great if we had a dashboard where we could see the ideas associated to OKRs and their progress, so it’s easier to track the health of these, and be able to act accordingly.
Voting dApp has been revamped, minimizing costs; and right now Metamask offers support to hardware wallets, so probably on Q4 we’ll be able to use the dApp more effectively
I’m coming at this from an approach of bringing decentralized governance tools into the mix to produce good decisions. Below is a proposed format to do that.
Step 1: Creating OKRs.
Inspired by swarm wise, anyone can create a proposal for an OKR, but in order for that proposal to be considered it needs at a minimum two signatures. This signing can be facilitated using the signing dapp which we used to sign the Status principles.
Step 2: Swarms agreeing on an OKR
Every member of Status belongs to a team or a swarm of some sort. It’s assumed that there will be a lot of OKRs and that these swarms will need to work on the OKRs. How do we decide as a swarm which OKR’s to take on and which to put aside? I recommend using consensus circles, a method whereby every member has a right to veto an OKR. This is better than voting as voting creates loses. It also means that swarm reaches consensus on the OKR’s it puts forward.
To facilitated this using a decentralized tool we can use a multi-set wallet which requires every member of swarm to a approve an OKR.
Step 3: Community Voting
Using the voting dapp, SNT holders will be able to vote on the OKR’s collected. SNT holders (in theory ) will vote on the OKRs that they believe will increase the value of SNT. The outcome of the vote helps us prioritise the OKRs for the next quarter. This informs what we take in and what we take out.
It’s important to note for timelines that voting needs to start before the vote in the sense that community members are well aware of whats happening before voting begins.
Step 4: Prediction Market to inform deadlines
Futarchy is a hot topic in decentralised governance and is practical due to Dapps like Augur. Based off the practical work in the field from Robin Hanson prediction markets when used in organisations are incredible effective in informing deadlines. To this end we put an OKR on a prediction market specifying the date when it should be finished, people then bet on if it will or will not be completed by the date. The predictions are refunded with liquidity so there is an incentive to bet on the outcomes.
The OKR’s which the market seems most realistic to hit by the end date are further prioritised as the items to start working on. There is even the potential to set bonuses based on the likely hood of hitting OKR in the sense that the more unlikely the market deems us to hit an OKR, the higher the reward for hitting it.
I noticed a lot of people liked the principles / wall of shame inspired approach (in fact, it was one of the few positives people had to say about 18Q3ish OKRs), so let’s double down on it. See Status.app for how. I’d love it if we could get some substantial wall of shame (even per principle) there and vote on it in terms of severity.
I like this as a practical proposal, and it doesn’t have a lot of dependencies on other stuff getting sorted out.
I think it’d be great if individual swarms/teams can have their own OKRs, and then bubble the p0/p1 up to core OKRs and then org OKRs, for example by voting. From what I can tell, that would make most people who expressed strong opinions about this happy.
Another thing which I think would be useful but I’m not quite sure how to institutionalize, but perhaps it can be used as inspiration: use paired OKRs. A paired OKR is something which has both a qualitative and a quantitative metric. The idea is that you generally want to push up some growth metric, but you don’t want to do it at expense of wore quality. In our case that’d likely be number of contributors or transacting users, while principles/wall-of-shame would be the qualitative metric. This would also enable people who have different leanings happier since they can push the thing they think is most meaningful, but as an org we can do both.
Consensus circles are sometimes good, we just need to make sure they are done at the right level of granularity. I.e. it doesn’t make sense for 100 people to have a consensus circle about a specific team/swarm concern - in that case it’s better for that group of people to lead by action.