Hi @C0_G1
For reference we already downsized the OpCo team by 2 earlier this year. My opinion is that if we were to downsize any further we’d impact our ability to build out what’s needed, when it’s needed, as the protocol evolves. As for hiring a team on “eastern EU rates”, my experience so far has shown that to find good remote devs who can communicate well in a fully remote team is challenging, and when you do find them, they know their worth. So for devs like these, rates are not very localized. Something else to consider is that built up dev context on the front-end/infrastructure side of things is valuable when the underlying protocol tech is changing so quickly. Our team now has years in combined experience working with the Balancer contracts, subgraphs, data, etc.
The ‘tentative’ KPIs in the proposal are not tentative in that we won’t have KPIs, just that we need to find the correct ones to accurately represent our teams work. I agree we should have done this for Y1, but our transition into the new structure has been a busy process on top of all the dev work we’ve done.
I also want to point out that ‘front-end’ is a restrictive term for the work that the OpCo team is responsible for. We are essentially building and maintaining a full-stack web2 product. We build and run infrastructure, we are responsible for the whole design flow, including assets and copywriting, and then we also build out the front-end.
Regarding, moving away from a pure DEX front-end to having infrastructure, we’ve outlined the challenges we’ve faced in doing this in our Y1 Retrospective and discussed our thoughts on that there. We believe that to provide the best possible UI/UX for LPs we need to move away from the ideal of a pure decentralized front-end for the canonical app.
I think setting up a session to strategize on the shape and requirements of a ‘Product’ team would be helpful.