I think the largest takeaway is that there’s a lack of accountability and a disconnect between the current active teams and the wider community. There’s a big difference between creating an ongoing log of “we are working on this and we completed this,” but we haven’t really assessed the impact of any of these deliverables in quite some time. This makes it extremely difficult to tell if we’re successful in having any impact.
In the original framework OKRs were suggested as a way to define performance goals and indicators. However, a task isn’t an objective. For those unfamiliar with OKRs, you can read a good overview here.
The OKR framework, by definition, has two core components:
- Objective: what you’re trying to accomplish
- Key results: how you’ll measure whether you achieve the objective
What are objectives?
In the OKR framework, objectives are qualitative goals and should be inspiring and ambitious. An objective can be long-lived or can have a firmer deadline like the end of the year, the next quarter, or even the next month.
The objective of an OKR goal should be hard — the point is to push yourselves as a team or organization. When writing your OKR’s objective, keep the following qualities in mind:
- OKR objectives are “stretch goals” or “moonshots,” pushing the limits of your team’s capabilities while remaining within the realm of possibility
- OKR objectives are limited in number, which constrains focus to core priorities
- OKR objectives are designed with your business strategy, mission, and vision in mind
Example objective: Dominate our category mind space through content and community.
What are key results?
Your OKR’s key results are quantitative metrics that measure progress toward your objectives. Key results are used to ground your objectives in reality, allowing you to break down an objective into tangible milestones and specifically define the outcomes to be achieved.
For this reason, it’s critical that they always have a number to measure progress by so there’s a clear answer to whether it’s achieved. Key results also act as a mechanism for accountability, particularly for goals that have a long timeframe and may easily go off track.
For each OKR objective you create, you’ll typically assign two to four key results.
The current PTBRs lack any objectives. They list projects that will be completed but often lack any quantitative way for impact or success to be measured. There aren’t any stretch goals and the assessment made quarter-to-quarter is simply: did we complete the deliverables, yes or no?
For at least three quarters, the teams have been operating without any shared objectives and it’s unclear what the impact the deliverables are intended to have. When the public launch was being planned, there were no metrics offered such as “Target TVL after 1 month, 3 months, 6 months, 12 months” or “onboard X Poolers to V5 and reach 500 deposited Poolers by Y time” with a clear path to meet that objective through supporting key results.
It’s not just the length of time an RFC and PTBR are up for view, although an improvement is sorely needed. It’s a defined objective and the path to achieving the objective(s) through well defined key results that the community can measure. Transparency is an important component, but the changes needed are at the organization level among the teams. Communication with the community and between the teams needs to be improved if we want to achieve successful outcomes.
In the roadmap for 2022, you shared a great thought that I hold to be true:
We haven’t seen the teams and the community aligned and pulling in the same direction for the reasons I’ve shared in the above post and this one. The result is that we’re not growing the protocol or growing the community.
The Accountability Aspect
This is one of the biggest issues, and I may be misreading your comment, but I don’t see any acknowledgement on this aspect of my post. Do you think the council and the teams within the council have done a good job holding each other accountable since the council launched in Fall 2022?
Opinion on Outcome of Votes
If Poolers vote to deny an on-chain proposal, teams can always revise their proposals and work with the community to define an agreed upon plan and understand what OKRs justify the requested funding. The core principle up until now the PT Inc and GS have emphasized is that if the community disagrees with a proposal, they can vote no to signal their disapproval. During many early council meetings, voting down a proposal was also highlighted as the way to hold teams accountable if the community wasn’t satisfied with a team’s results or performance.
Again, I understand teams need funding to operate, but all of the current teams need to give themselves time to post their funding requests, provide visibility and engage with the community about these proposals, incorporate feedback, move to a PTBR without moving it to an on-chain vote immediately, and then transition to an on-chain vote after a reasonable review period.