Authors
This article covers important topics at Index, and so for those who we have yet to spend time with, here is more information on the authors:
Co-Author: Edward Previously built engineering organizations from the ground up as CTO/VP Engineering for Web 2.0 startups. Spent the past couple months helping @dylan think through the path to engineering autonomy for Index Coop.
Co-Author: Cavalier Recently quit web2 for Index full time, now shadowing Punia to build out the PWG we need and want. Previously founded and scaled product startups to 150 people as Product Lead and Chief of Staff.
Summary
With limited engineering capacity, deciding between products is crucial to improve the quality and velocity of our product output. Weâd like to discuss how to better coordinate between EWG, PWG and the wider coop, so that we can unlock our potential to launch the worldâs best crypto indices before our competition.
This post is not meant to be a direct discussion of Engineering autonomy, although it does have some implications on that front.
Engineering @ Index: A brief history
Itâs worth highlighting that the large majority of engineering undertaken to create Index products was done by Set directly, or Set employees seconded to Index. This is important to recognize for several reasons:
- The technology required for our products is extremely complex, and sits at the forefront of software and financial engineering.
- The small but growing team we have is only capable of so much work at any one time.
- Until we have sufficient expertise within Index Coop, every new smart contract must have its code reviewed by Set Labs. This is prudent for safety, and is a significant joint effort often requiring multiple rounds of code changes.
- Every product that is launched requires rebalancing and maintenance, much of which is being performed by Set Labs. For the FLI products the burden is larger, and shared amongst Set Labs and Index through the Leveraged Indices Pod.
With the hiring of @ncitron and @0xModene the Index Coop now has its own small, but fully functional core engineering team. This a radical change from just a month ago, when there was effectively zero in-house capability to build new products. In addition, @dylan and @edwardk will continue to marshall engineering resources from Set Labs. Now that there are two distinguishable engineering teams, synergy is the name of the game.
A simple diagram showing where engineering capacity comes from. Not meant to be precise.
Engineering Growing Pains
Right now the internal engineering team has a number of organisational challenges:
-
We have little visibility into what we should be working on next. Often workloads come up suddenly because communication is scattered. Right now the team is busy getting ready for a successful DATA launch (
w00t!), but what about after that? Knowing roughly whatâs in the pipeline will make it easier to allocate the right people to the right projects. It will help us know who we need to recruit. It will also go a long way in preventing burnout by making it easier to communicate around expectations. -
Engineers are being asked to do significant research and communication around products that have yet to be prioritized. There are already several new product proposals that will likely be put up for DG1 voting. If they pass (and most do), even more precious engineering time will be spent in feasibility conversations.
-
There is a strong reliance on Set for complex R&D, technical oversight and final code review
-
Engineering requests by IIP mean that ânice to havesâ are being assigned priority by INDEX holders.
This means that the Engineers are being pulled in different directions and not being allowed the time to focus on deep work. Ultimately this means that overall progress is slower.
Product Pipeline (Unordered)
At the time of writing there are five product ideas that have passed DG1 and are being readied for a final DG2 vote:
In our current process, whichever one of the products in the pipeline makes it through DG2 first and has the most vocal support is probably going to be the product that gets built first. All other products will be blocked, regardless of subsequent voting outcomes.
In addition there are numerous other features or products that we would like to build but donât currently have the contracts available:
- Fully formed products on Polygon
- Leveraged products on Polygon
- Productive indices (PAY / LDI / YHI)
- NFT indices
- Issue and redeem fees on simple indices
- Management fees on simple / productive indices
Itâs amazing to see these high quality product ideas coming from within and outside the community. Within a year of inception Index has become the leading crypto index organization, and a formidable community has formed. Each week we attract new talent, new ideas, and more enthusiasm for what is possible.
The dose of realism is that we simply canât build all of the products in our pipeline simultaneously. Aside from the large number of products, features like mint and redeem fees require significant engineering development.
How to Get Better
Like other Product organizations, Index Coop would benefit greatly from an agreed roadmap and priority for smart contract R&D and product launches.
The roadmap/ prioritization should consider:
- What we can launch with little effort / zero R&D (see product feasibility)
- Technical feasibility for new contract types
- Return on investment for the work required
- Business opportunity
This obviously needs input from both EWG and Set Labs, but also the wider Index Coop community to ensure weâre as aligned as possible on priorities. To reduce communication overhead and give engineers more time to focus on building, weâd like to suggest that EWG interface mostly with PWG and Set engineering. The communication flow would then look like:
Set Engineering ââ EWG ââ PWG ââ Index Coop Community/Stakeholders
The question remains, how should PWG coordinate with the community to prioritize work?
The DAO organization structure is unique in some ways, but is not immune from the need for effective decision making, clear prioritisation and considered tradeoffs. We can learn and borrow from the extensive best practice of product management from web2. In traditional tech companies, product managers have influence without authority.
We believe that PWG should be empowered to bring together stakeholders and produce a near-term roadmap. Perhaps this could be in conjunction with the Simple and Leveraged Indices pods. Importantly, the new structure should help prioritize between products and work to be done, not just decide in isolation if that product or task is something the community wants to do.
Any approach to deciding how we prioritize products needs community buy-in. Please answer this poll question, and comment with your thoughts!
- Yes
- No
0 voters
