Ecosystem Growth Fund - retrospective

[Discussion] EGF review

Note: you can find the original EGF proposal that passed here. We learned a lot from the deployment of the first round and would like to share details and lessons learned before proposing future work in a separate proposal.

Proposal champions

@nassar | nas#9634

Background

Purpose

The Radicle Ecosystem Growth Fund (EGF) was setup to fund initiatives that drive awareness, engagement, and adoption of the Radicle stack.

The EGF was also an experiment in DAO community contribution models. The aim being to explore ways to attract proposals from those wanting to contribute to the growth of Radicle and supporting them to productively contribute.

Approach

We worked together as a committee to develop an initial strategy to deliver on the intended objectives. The full strategy can be found here.

A brief summary of the strategy was that code collab and funding products would be supported in their launch by funding initiatives in the following categories:

  1. Growth contributors
  2. Hackathon/event sponsorships
  3. Content/media channel sponsorships
  4. Educational content sponsorships
  5. Product driven growth development
  6. Gas reimbursements

Success would be measured by number of active developers, active integrations, and TVL in drips protocol.

Contributors were educated on the project, its needs, and supported in developing a proposal and as they worked through delivery. This required a different model to top down management based orgs to ensure productive contribution. We share these lessons learned on this below.

Funded breakdown

Total: $159,892.63

Initiative lens Deliverables Total funding
Conference sponsorships Contributors attended conference, which helped them build a deeper understanding of the space and relationships that enable us to drive partnerships. A direct return is hard to assign to such activities, but it should be seen as top of funnel for partnerships. Devconnect Amsterdam and ETH permissionless. $2,629
Launcher contributors Launchers were focused on diving into specific segments of the market that they already had a depth of experience with. Their deliverables were to dive into our solution and then test the market vertical through a few rounds of conversations with leading project teams. This allowed us to speed up the process of testing positions that we believed may be interesting to a vertical. e.g. We had someone that has worked in web3 gaming firms propose a project to explore the use of Drips by different players in the stack. $15,526
Early user token rewards This proposal focused rewarding DAO teams for the work involved in being an early user and providing feedback. The aim was to onboard 50 Contributors. Build a solid list of contacts, projects, and document every interaction from discovery calls, to feedback sessions all in one place. 9 participants onboarded and completed the feedback session to be awarded RAD. The programme was cut short as the core team felt they had sufficient feedback and didn’t want to burn early adopters. $6,960
Community DAO sponsorship We funded womenbuildweb3 as a developer education and diversity focused DAO. They invested this in the onboarding and education of developers into the web3 ecosystem and incorporated Radicle tooling into their syllabus. a) Curriculum/content around building on Radicle prior the start of#30daysofweb3 to make sure people have a guide for each of the tools in our stack. b) At least 1 blog post about Radicle on the WBW3 blog shared on ourTwitter + D_D Twitter from one of the WBW3 members in the dev rel guild. c) We can organize at least 1 workshop with you and post it on WBW3 Youtube channel which we’ll also use to orient & onboard new members in the future. d) Tweet/retweet dev content for a month - Community and social media stats (engagement numbers, etc) $20,000
Marketing contributors We had product marketing and podcast contributors join to develop these initiatives. a) Launched Bear is for builders podcast series. b) Started product marketing pipeline with process for getting updates from product teams to market. c) Grow social and content marketing efforts. d) Developed messaging kits to guide marketing efforts $24,000
Developer education contributors We funded the development of a developer relations strategy. This was followed by 3 contributors that would begin educating developers on radicle and growing awareness of Radicle amongst developers with developer marketing. a) 3 pieces of content were released on hashnode. b) 2 educational videos were also developed for our YouTube channel. c) Tweets and threads were shared to grow awareness amongst developers. This initiative had the most challenges. We decided not to publish or promote the content as it wasn’t meeting the bar we felt is important at this stage of development where there isn’t much educational content. $50,700
Cohort programme contributors A group of contributors with experience in entrepreneur ecosystem building came together to develop a programme for onboarding and educating community members with peer learning. a) Design structure and infra for delivering cohort-based programme. b) Gather/Create cohort teaching material – texts and video (topics TBD). c) Begin promotion of programme to collect list of applicants prior to start of programme $27,447
  • Proposals can be found here.
  • Transactions with descriptions can be found here
  • RAD transactions can be found here

How we performed

  1. Market feedback - The early user token rewards, launcher contributors, and conference sponsorships can be categorised as initiatives that aimed to help the growth and product teams build relationships across verticals to get feedback. The feedback helped speed up the learning of teams as they worked to build and decide on verticals to focus on.
  2. Adoption KPIs - Number of active developers, active integrations, and TVL in drips protocol were the key metrics we wanted to impact. The product and protocol teams were not quite ready to meet the needs of developer users or platforms wanting to use protocols. Limited progress was made on moving these numbers in this initial round.
  3. Awareness - Community sponsorships allowed Radicle to position ourselves as being a key partner for communities that had high engagement and positive sentiment in the market. We also had contributors make proposals for developing a podcast and a product marketing function, which are now up and running and we should see the impact of these efforts moving forward.
  4. Education - A developer education strategy was developed and a team of contributors setup to deliver on it. These initiatives were the most challenging as it became clear that a higher level of technical experience was required to understand and communicate the concepts to developers. Effective developer educators are in high demand in the space and so we have been exploring different ways to approach this critical component in our proposal for next steps.
  5. Onboarding builders - We funded the development of a cohort programme with the aim of building a more supportive path for builders who want to build in our ecosystem. The strategy around this took longer to develop than expected due to changes in the strategy of core team, but we now believe it’s well focused and will be a key pillar of how we move forward in our ecosystem growth efforts.

Lessons learned and improvements

  1. Attracting contributors/proposals - During this initial phase there was a fair bit of direct outreach to those that seemed relevant and likely to be interested in taking on an initiative. As our contributor pool grows and processes get more clear we anticipate greater inbound interest in contributing to growth initiatives at Radicle. It is likely that the best contributors and initiatives would be attracted to more focused teams with clear contribution guides and so we are keen to encourage growth teams to make it easier to contribute over rely on a single fund.
  2. Vetting - Contributors had a higher failure rate than core team hires due to the desire to allow community members to make a proposal for work they want to do over hiring for a narrow role with proven experience. We believe that teams focused on one growth area would be better at vetting contributors and initiatives as well.
  3. Onboarding - Contributors need a fair bit of support as they onboard to the project. We learned that it was very important for them to understand the mission and strategy being taken by each team to serve this mission. They also need guidance from someone with enough knowledge of the project and teams in order to connect with the right people as their initiatives have dependencies on others.
  4. Accountability - Contributors need to be held accountable on a regular basis the same way core teams need to share updates on a monthly basis. We started by trying to minimise the reporting requirement for contributors, but decided that it was important for each initiative lead to contribute to a monthly community update.
  5. Off-boarding - ****Contributors that were funded didn’t always meet expectations. Initially we tried to give them time to try find their feet, but learned that we needed to minimise impact on other contributors. Again, we think by moving contributors to more focused teams would help with speeding up feedback loops when something isn’t working.
  6. Strategy alignment - It’s been hard work keeping the initiatives connected and aligned with the core development teams as changes to core strategy were implemented. If an initiative needs a high degree of strategic alignment then they should be coordinating closely within a single org. If an initiative is able to progress the ecosystem mission without needing a high degree of strategy alignment it can be funded and operate as an independent org.
  7. Committee structure - The committee contributed to our initial strategy and was very valuable to have such experienced heads as we developed this new fund. We did find that on an ongoing basis it was the other initiative leads that had stronger opinions and enough context to have help make decisions on the initiatives that we would be funding. We believe that contributors should govern the EGF moving forward and committee members should act as advisors.
  8. Confusing team lead overlap - Working as head of growth in Radicle core development team and leading the EGF was challenging and confusing. It’s best to have leads focus on delivering and reporting on one strategy.

Next steps

The EGF has been a great tool to allow us to run experiments in DAO open contribution strategies and ecosystem growth infrastructure. We learned a lot running this first round of EGF and have explored a few options for path forward.

We explored transitioning EGF to an org in the DAO where core marketing, partnerships, education, and community teams sit and coordinate. We decided that this wasn’t the best approach for two reasons. Firstly, it would significantly increase the coordination work by EGF core team and could even hamper the coordination between engineering contributors and growth focused teams. Secondly, we felt a fund across partnership, marketing, community, and education is less effective than having clear funded contribution guides for each team to attract and fund initiatives in their domain.

The areas that we found to be most interesting, challenging, and impactful in the EGF were the education focused initiatives. The core team members of EGF are also most experienced and interested in education. It became clear to us that there is a lot of opportunity and work to do and we would want to approach this in the most focused way possible. Radicle is working on hard problems, which require a collective effort greater than what we fund and develop to solve them. We need the web3 ecosystem to work collectively on shifting culture and for tooling/infra to progress to achieve our mission. So focusing on research and education allows us to build a developer and researcher community that brings mindshare into the ecosystem and creates resources for the wider web3 ecosystem to benefit from.

Transitioning

  1. We are exploring two options for transitioning the treasury
    1. We return all funds to the treasury.
    2. We roll the funds over into the proposal for the next phase of our work on ecosystem growth focused on knowledge sharing and education. Current committee would be removed as signers and replaced with new core team.
  2. We also need to decide on a plan for transitioning marketing initiatives/contributors that are currently being funded/paid by the EGF to a new org. This is being discussed with the new Head of Marketing in the core dev org.
4 Likes

Thank you so much for sharing!!! So much detail and a lot useful learnings listed here. Really excited to see where the EGF goes next! :grin:

1 Like

Thanks for the write-up, Nassar! Good to see this all in one place.

1 Like

Great summary Nas!

1 Like

Hi Nassar,

Thanks for this helpful write-up. “The EGF has been a great tool to allow us to run experiments in DAO open contribution strategies and ecosystem growth infrastructure” — this is spot on. There has been a lot of experimenting, and, importantly, there are clear lessons learned that can be applied to future planning and strategy, especially when it comes to operating within a DAO framework.

To this point, I wanted to clarify some of the lessons learned and room for improvement that you covered:

  • “It is likely that the best contributors and initiatives would be attracted to more focused teams with clear contribution guides and so we are keen to encourage growth teams to make it easier to contribute over rely on a single fund.” I’m not sure what the second part of this sentence - with regards to growth teams and single fund - means exactly. What is the ideal structure (and onboarding) for attracting the best contributors?
  • “Contributors had a higher failure rate than core team hires due to the desire to allow community members to make a proposal for work they want to do over hiring for a narrow role with proven experience. We believe that teams focused on one growth area would be better at vetting contributors and initiatives as well.” What does it mean for a contributor to “fail”? Does “core team hires” refer to people hired as part of the Growth Core Team? Hiring is always hard, I can empathize. Did you have any takeaways around the best ways to vet people from the community - especially when they are new and unknown? Should we be bringing on unknown contributors for large grants?
  • “If an initiative needs a high degree of strategic alignment then they should be coordinating closely within a single org. If an initiative is able to progress the ecosystem mission without needing a high degree of strategy alignment it can be funded and operate as an independent org.” - This is a good point and an interesting observation. “Working as head of growth in Radicle core development team and leading the EGF was challenging and confusing. It’s best to have leads focus on delivering and reporting on one strategy.” Do you have general thoughts on how Orgs within the Radicle ecosystem should be scoped? And how can we clarify scope to avoid the confusion you felt in your role leading Growth (as part of a core development team) and EGF?
  • I saw several instances/mentions of the product and protocol teams not being ready for the insights gathered or work done by the EGF. Given where product and protocol teams are today, what kinds of work should be prioritized within “growth” initiatives (beyond the educational work you intend to push forward)?

It was hard from your overview to get a sense of which initiatives were most successful and which could have been done better - and the how/why. Specifically, I believe this insight is important as we transition more Radicle work to be funded by the DAO. So I’m curious to know:

  • How were initiatives reviewed by the EGF during and after the initiative’s funding period? How were the outcomes/impact measured against strategy and KPIs of the EGF?
  • What proposals (and/or contributors) were most likely to succeed?

Because “Developer education contributors” accounted for almost 1/3 the costs AND your intentions are to have developer education be a critical component in your proposal for next steps, I’d like to know a bit more about why your team “decided not to publish or promote the content as it wasn’t meeting the bar [you] felt is important at this stage of development where there isn’t much educational content.” Can you dig a bit deeper here? I feel like this was (quite literally) an inspirational effort, but there is little to show except a big price tag.

When it comes to your upcoming proposals for work in education, I’m not sure if it’s helpful but back in the Monadic days, I put together accessp2p. The participants were not technical, but I’m still happy to share outcomes from that effort.

Lastly, regarding what to do with the remaining funds, FWIW: I would be in support of transferring them back to the treasury. In the end, this return-of-funds-and-re-proposing-funds-for-another-purpose more clearly holds recipients of Treasury funds accountable to 1. the work they are supposed to do with the funds and 2. the process [temp check and beyond] for Radicle Treasury allocations.

Thanks for your patience in working through this long post :slight_smile: but I’m very much looking forward to hearing more.

1 Like

Thank you for sharing this retrospective @nas.

I will structure my feedback around the two goals that you mentioned above. Specifically:

  1. Awareness, Adoption and Engagement of the Radicle stack
  2. Grow community contributors for Radicle

Regarding the former, there were a lot of initiatives that you all tried and a fair amount of impact and learnings, especially given the change of product strategy as well as the delays in terms of product launches. On this part, I don’t have much to add except the fact that I wish that the EGF team:

a) had proposed some methodology on how to measure awareness and
b) use that methodology to reason about progress.

I specifically mention “awareness”, knowing the constraints you all had with regards to adoption and engagement, due to the state of the tech.

With regard to the second goal (growing contributors for Radicle), by reading this retrospective, I struggled to understand the strategy that was followed. For instance you write above:

Can you share more on:

  • What was the strategy to identify who is relevant and likely?
  • How were these candidates selected?
  • What was their onboarding process to the DAO and core teams?
  • What was the plan with regard to interacting with core teams?
  • What was the plan with regard to compensation?
  • Were there any feedback sessions done with folks where things didn’t work out? Any learnings that you can share?
  • In general, what was the envisioned path from “Radicle is cool!” to becoming an active contributor within the Radicle ecosystem?

It’s quite hard for me to formulate an opinion on how valid the learnings you share are, without having a better idea of what you all tried and what not, and how the pieces fit together.