[Discussion]: PTBRs, Council, Direction, and Lack of Accountability

1

[Discussion]: PTBRs, Council, Direction, and Lack of Accountability

Given the current discussion on Discord and the general negative sentiment I’ve seen from many long-time Poolers, I wanted to move this discussion to the forum and share some of my thoughts on the promise of the council, its original intent, and the reality of its impact on contributor culture within PoolTogether since it was established in the fall of 2022.

Council Origins

Brendan shared his thoughts in the The New PoolTogether DAO: Part I–this is part of a series of three posts. In the Part 1 post, some important points are outlined:

This was a valid point then, and it still stands now. The entire post is worth reading to get a sense of the problems the council was intended to solve.

In the The New DAO section of the post, the role of PTBRs was noted:

Using this as the framework:

  1. The Team’s purpose. This is included in every current PTBR.
  2. Performance goals and performance indicators. The majority of PTBRs don’t include any metrics that Poolers can use to evaluate success. Over time PTBRs look more like a to-do list of deliverables that don’t tie back to higher level objectives. One of the core shortcoming identified earlier in the aforementioned forum post was the lack of accountability. It is impossible for Poolers to keep teams accountable if the only measure of success is “Did we do this thing?” and not “Did it have an impact? Did it provide value to the protocol and to the people who use the protocol?”.
  3. A budget breakdown. This used to be included in the first PTBRs but the council found this was cumbersome to include and instead there was a shift to deliverables over assessing actual value add. I thought then and still think now this was a mistake.

You can find the changes suggested in the Council Discussion: Changes to the Team Budget Request process post. Here are some highlights:

It’s normal and expected that the first attempt at something needs some adjustments. However, Poolers are not seeing the current teams living up to the standard set by the council, which is made up of these team members. PTBRs should be posted earlier, so people have more time to review. We should consider holidays and time when attention will be lacking. If this means changing from a quarterly to a every-four-months cadence, that is fine, imo.

We’re still suffering from a lack of communication with both the wider community and between teams. This has had a direct impact on the ability to grow the protocol and further adoption since V5 launched. The teams contributing to the development, growth, and adoption of the protocol are not working in the same direction. This was something I experienced when I contributed to the TWG, as I often felt PT Inc worked toward goals and objectives there were not shared with the rest of the community. This resulted in multiple team working on the same deliverable and overriding each other.

Council

I was present when the council was being discussed and all of the potential options were being evaluated. One of the key aspects that was reiterated multiple times in those discussions was accountability, and it’s also included in the aforementioned posts. However, the lack of performance indicators, lack of communication, and lack of organizational level objectives and key results has prevented the wider community of POOL holders from being able to hold teams accountable. Yes, this can be done when votes are put on chain, but what we see is team members voting for each others’ proposals. This leads to the next point.

Given the council is made up of members from the DAO funded teams, it has inadvertently created a culture of people who say Yes even if they disagree with the direction. Many people feel like the current problems and past problems are insurmountable and there’s a sense of apathy that’s apparent. When it comes to team members, my belief is that many people are concerned about being critical out of fear that their funding proposals would be voted down in retaliation. Often times, the reaction to criticism is met with a strong personal reaction.

To be clear: I don’t think anyone contributing to the DAO is acting in bad faith. I think we’ve strayed off the path, aren’t well organized, lack clear objectives and direction, and have created a culture where criticism is not welcome and, when it is given, is either discounted or ignored.

There’s no clear indication that any one is being held accountable for the lack of growth and adoption, all of which is the product of the above mentioned issues. The issues the council was created to solve have only gotten worse over time, imo.

Direction

We’re not moving in the right direction and there’s no clear sense of what that should be. I don’t think the direction should be or needs to be defined by Brendan all the time. However, I know many Poolers feel as though the development team has final say on direction, so people are hesitant to suggest changes or offer their opinions.

Both teams need to work in the same direction, but that’s not happening. There’s a lot of talk about growth, although PT v5 was developed for more than a year and yet no migration plan was discussed or was in place ahead of launch. While a migration from V4 to V5 has achieved concensus, no progress has been made here and when it occurs, it will be 6 months or so after v5 launched.

When I review the deliverables in the last two quarters of PTBRs, I do not see many deliverables that go back to growth initiatives. The action the teams are taking should match the public messaging that goes out.

If there’s any hope of growing V5, there needs to be a change in the way the DAO sets direction, assesses progress, and determine what deliverables contribute to those higher level objectives. See Lido’s GOOSE model, which is a great way to set short- and medium-term goals with POOL holders consent. There are plenty of working models out there. We don’t need to reinvent the wheel, but we do need to find one that rolls well for the PoolTogether community.

Lack of Accountability

As stated before, current PTBRs look like a to-do list with no metrics or KPIs for the community to assess success in the next quarter. Some examples from the recent GS PTBR:

Prize Compounding Interface

There’s been quite a lot of talk about this, but what is the actual volume that’s going through the existing ticket liquidity? How many people are swapping into vaults? Has there been product research done that supports this as something depositors want?

If this is a growth-focused deliverable, what amount of volume through this interface would define success?

Delegate to NFTs

This initiative has been pursued in the past with no traction. Two of the main problems that people managing NFT collections identified:

  • There wasn’t an ETH vault. We’ve solved for this, which is great
  • Their collection is on Ethereum mainnet, and they were less willing to move to an L2

If there’s been interest from NFT collections to do this now, that would be great to hear, but funding should be allocated for something on a lark.

There also has been any public analysis on the adoption of the delegation feature outside of team delegation. That information would be valuable and would likely help POOLers decide how viable this is as a growth option. If @tim could share information on that, it would make a world of difference on how valuable these type of campaigns can be.

Launch on Arbitrum

I do want to see PoolTogether deployed on other chains, but if we’re just going to deploy and use Aave as a yield source, I don’t think we can do the same thing and expect different results. I’m still supportive of refining V5 on Optimism and finding something that works to grow adoption before moving to another chain. Why would a deployment on a new chain be different this time?

If there are plans for other yield sources on Arbitrum, that would make a difference.

This isn’t isolated to GS, either. Crucial information on HOW these deliverables will achieve growth is missing. There’s still a lot of “we said we’d do this and we did” without any thoughtful analysis of impact and performance, as was originally intended when the PTBR process was created and updated.

I would have previously provided this feedback, but I was on holiday and my focus wasn’t on DAO governance. Going back to the original council creation post, PTBRs should be posted earlier so people like me and others can provide timely feedback before a vote is put on chain.

Conclusion

I’ll end by saying I know the existing teams and community can take steps to improve. We have problems we can solve, but there needs to be more communication and accountability within the process to make the current protocol successful.

Everyone here loves PoolTogether and believes in its promise: we wouldn’t be having these difficult discussions if there weren’t the case. I’m not writing this long post to be a thorn in anyone’s side. I took a break from PoolTogether in the past because I was frustrated with the direction, but in this new year, I want to share ways I believe the community can come together, improve our existing process and application of that process, and rally around the protocol.

10 Likes
2

Welcome back @BraveNewDeFi; thanks for the review of the process and your thoughts. The creation of the council feels like a million years ago!

Lots to unpack here, but with this and the discussion in Discord my takeaways are:

  • We should post RFCs earlier. This means there is more opportunity for feedback, so that consensus is reached before the on-chain vote starts.
  • We need more transparency with the weekly status of teams and whether there are updates to deliverables. This could come in the form of more frequent updates, but I just realized that we already track team updates during the weekly Council call. We write the updates in Notion, so it would be easy to make it public (if it isn’t already) or switch to a different medium.

Most importantly though, after seeing the amount of mis-alignment today I think that we need to establish a shared vision of what we are building. Deliverables serve an objective, and without knowing that objective we can’t determine whether the deliverable is valuable. The community needs a vision, and a roadmap to achieve it. The rationale behind the design of V5 needs to be communicated.

What other takeaways do you see? Or does anyone else see?

4 Likes
3

As always @BraveNewDeFi your wisdom is the breath of fresh air that keeps the pool floaties floating.

@Brendan and the other Team leads
The community needs more than a to-do list. Something KPI-adjacent. Yes KPIs are hard to set and harder to hit if you don’t have a methodology on developing them. But the community needs some way to measure success, measure impact. Even a vague; decrease time on “make deposit flow” in UI by 10%-20%, or launch 2-4 partnerships which include NFT usage and/or rewards usage. This is arms and legs more than we’re getting now and helps justify costs if the metrics are hit.

2 Likes
4

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.

3 Likes