We will be working with Working Group Leads to create a Simple Indices Pod to drive the roadmap for indices that do not take complex positions with the underlying tokens [DPI, MVI, BED, etc.]. The Simple Indices Pod will complement the Leverage Indices Pod and give Index Coop coverage over all of our financial products.
The Pod will be a cross-functional team across different domains that can prioritize and execute autonomously over specific initiatives - thus increasing the overall output of the Coop.
Index Coop has developed robust and highly capable Working Groups. These Working Groups have a remit in specific domains to the overall goals of the DAO.
However, to accomplish their goals, Working Groups often need to operate in a cross-functional way, drawing resources and support from across different Working Groups within Index Coop.
A few examples:
- Product needs Growth to help push out informational blog posts.
- BD needs Engineering to implement Polygon integrations.
- Engineering needs design to polish up FLI calculators.
Such cross-functional collaboration is incredibly important for the success of any company. However, currently, Index Coop does not have structures or processes in place to effectively manage cross-functional collaboration.
Our current process essentially entails members of different working groups, and sometimes different members of the same working group, messaging other working groups requesting support or input on specific tasks that they need to be completed.
To help manage this flood of requests, key working groups like Design and Engineering use project management tools like Notion and Trello boards. This presents a challenge for these Working Groups as they have to make decisions with little context on what activity to prioritize. All of this adds significant pressure to already strained resources and impacts our Working Groups ability to plan.
By accident, we ended up modeling an alpha version of this cross-functional team for our suite of Leverage Products and, though we are still ramping up, it has been incredibly effective.
The Leveraged Indices Pod is defining the roadmap and prioritization for our suite of Leverage Products. Not only in terms of which new products we launch [@emault], but also how we grow them [@afromac], maintain them [@allan.g], and build resources to support them [@emault and @tgreco].
As a cross-functional team, we can make decisions quickly, act autonomously to get things done, and drive towards a longer-term vision on how we can make our products 10x better.
Here is an example of the things the Leverage Indices Pod is doing:
As you can see, the activities span Engineering, Operations, Content Marketing, and Product disciplines. Instead of having to lob over to Growth the articles we think are important to publish or Engineering the bots we want to develop, we can prioritize and execute those decisions within a small and agile team.
This Pod is still in the Alpha stage and needs to bring in stakeholders from Design and BD to likely be complete, but it is the first example of a highly effective and autonomous decision-making body.
Our immediate priorities are around maintaining and growing our financial products. Therefore, as a next step, we propose the implementation of a Simple Indices Pod to complement the Leverage Indices Pod and effectively implement this execution structure across all of our Financial Products.
Simple Indices is a term we use to describe indices that do not have complex positions with other protocols. They typically follow a simple, predictable rebalance schedule and sometimes may have some extra elements such as meta-governance or intrinsic productivity. Such products today include DPI and MVI; some products to come in the future include: SMI and BED.
The Simple Indices Pod will initially be composed of individuals from:
I will be leading this Pod, to begin with. We will be reaching out to the Working Group Leaders here to get a representative for the Pod. Working Group leads will be accountable for the performance and support of their representative. The representative will leverage the resources in the Working Group as a whole to execute successfully.
The Simple Indices Pod will be responsible for:
New product launches.
a. Governance process, stakeholder management, full-stack engineering efforts, GTM content, etc.
a. Making sure the monthly rebalance happens.
b. Maintaining the liquidity mining rewards.
Growth content marketing.
a. Managing a content marketing pipeline.
- Product integrations.
- Facilitating product sales.
Things the Simple Indices Pod will not be responsible for:
- Managing the product sales process.
- Ads spend and strategy.
- Executing rebalances
- Improving underlying infrastructure.
- Metagovernance for DPI.
Any initial parameters and operating norms are a test and it is important to not let perfect be the enemy of good. At the very least, the immediate problems that such a pod would solve include:
- Build context within the Coop to launch and maintain Simple Indices.
- Tackle LM strategy early with all relevant stakeholders.
- Helping Punia and Lemonade gain leverage on product launches.
a. Ex. looping in Design way earlier.
- Provide clarity on Uniswap v3 integration to community members.
- Provide clarity on L2/Sidechain expansion to community members.
Each of these things presents a large pain point to the community and creating a structure that solves them would be a huge win in and of itself. From there we can continuously iterate to find the structure that works best for us.
Upon a successful cycle of trying this structure, we will try it again with a few more Pods before rolling it out to the rest of the Coop.
Meanwhile, Engineering will continue to build itself out and requests on Engineering resources that are outside of the Pod structure will not be worked on until there is a relevant Pod there.
Some things we will be keeping our eyes on as we implement such a structure include:
- Alignment and onboarding to the same project management tool for all WG and pods.
a. Important for Pod to Pod interactions.
b. Important for Functional Group Leaders to manage and defend what their contributors are working on.
- Intra-pod coordination.
a. 2 week sprints vs. Basecamp model
- How do pods communicate what they are working on to the wider community?
a. Do they need to?
This post is a trimmed post from a more complete doc that describes how we are currently hypothesizing Pods and Working Groups may develop within the coop in the future. Click here to check out the doc.