#DappCon22 : Day 3 - What Governance Can (And Should) Learn From Software Development, Juan

Transcript

thank you thank you Jim I've always wanted to speak to a room full of people so thanks for being here it's not that.com all right so let's start my name is Juan I'm the I'm a core unit facilitator at maker that's me before I lost my my racer um and yeah according facilitator is the kind of the contact between governance and uh and each team at maker so yeah my community is a sustainable ecosystem scaling and we try to make sure that the ecosystem scales and maker doesn't burn on the way there so some of the of the

learnings um hopefully I can share with you today my journey to the Dao or to web3 started in in the corporate world then I moved to startups and scale-ups some of them here in Berlin so happy to be back and finally I I discovered defy and maker so now I'm doing a little bit of advice for for other Dallas uh trying to spread the learnings but that's a bit about me so some disclaimers My Views are my own I do not represent all of maker no one does when you're working for Dao nothing of this should be taken as Financial

advice legal advice or even romantic advice um so how do we build the Dow it's actually quite easy step zero find the real problem to solve here I'm quoting Vitali for some clout uh apparently your tug will rank higher but uh no I mean tribal dowels are cool um but I think that long-term success and when we get real penetration will be when when we start addressing real issues and problems so hopefully we'll see a lot of these Styles moving forward step one you need the mission the vision of the strategy um this is quite important the vision is the why like why are you doing this why

do you want to address this problem then the mission is the how so how how do you get there and the strategy is the actual plan and that's the most important part where we are seeing a lot of failures lately step two create value so how you do how do you do this you need to focus on on the core of your community it's very easy to actually lose track or lose focus so ideally you start at the very very core for anything that's looking outward so the community is like who's paying whose problem are you really addressing and then you can start moving outwards and it's the same thing for the for the internal communities when you're managing them there will be a lot of noise because it's so open so you need to be sure that

you're actually managing the the community in a good way starting with the core developers and people building the product uh and again moving outwards by the way if anyone wants to discuss any of these Frameworks later we can we can do that too step 3 build solid pillars so any dial will need to focus a lot on leadership Communications monetization resilience and and the solution these three pillars are super important and they need to be clear and defined and once you have this hopefully you can you can move forward and scale step four set up coordination so any organization decentralized or not

will have work which is what needs to be done the workforce which is the people doing the work and then the the capital is a bit the incentives usually it is some kind of money uh for the human race but it could be something else so you need to coordinate this so again it's all about coordination but uh you need to make sure that these are are moving uh in in rhythm and the last step is to code it right so you write your Constitution your values you actually build a protocol tokenomics any type of process you make it very very clear and explicit dashboard templates documentation on this something forgotten but very very important and that's pretty much it you

have your dial so as I promise it's very easy these are some examples of these Frameworks or or codifications out there python has done it for several years ethereum as well maker but there are several in the industry some better than than others and basically it includes all the rules for governance to to actually operate um so yeah once you have that you profit and you scale hopefully without any problem right so this is when you start to see some of the scaling problems Improvement proposals at scale gets quite complicated

so for someone trying to get involved if the documentation or the or the process are not very clear it will be extremely hard to start to know where to go and to actually produce value the token holders want people to produce value and the the ideally these processes are set up for for this contributor to find a very easy access to to producing value and to get it rewarded for that and same thing for the for the internal people so how do we manage this thing uh what are the processes what do we need to follow uh even people that are working full-time for for these styles are having a hard time following all the

processes so um having a good proposals framework it's it's very important for for the internal people as well this leads to the rise of the bureaucrats so the contributors actually become middle managers instead of creating value they're just running operations after some months or years you start arguing that the Dow is not moving fast enough or it's not as lean this happens a lot at scale it becomes quite hard to prioritize uh it's very easy for for you can call them political parties to actually rise and stall any any type of

innovation with a lot of really good uh arguments it's like oh but we should be focusing on other things so the whole prioritization thing becomes quite messy if you don't have a good Frameworks in place before beforehand and uh and yeah the bureaucrats if they're getting their their compensation they will they will try to keep their their job instead of producing work so instead of creating value it's more about maintaining the status quo and making sure that they are the ones that know all the intricacies of the the processes and that they actually know how to run the the governance and the bureaucracy um so how do we challenge this so yeah that the idea is

to go back to software so coders Unite um if we go back to the basics I'm not a coder I I did some python in the past but this is a bit of an oversimplification but basically you have the different layers you have the kernel which barely changes if at all um or with any major upgrade then you have the OS layer that's where all the the communications happened in terms of plugins I guess then you have all the applications or these are a bit like the processes or the back end then you have the UI that's the interaction and finally have the users which are interacting with the with the whole stack so that's a bit the layers of the of the software

um and yeah this is the slide I want to spend the most time on uh because actually we can map governance to this uh to these processes or to these layers so on the current we have the Constitution we can have amendments to the Constitution some people argue that you should have a very uh immutable Constitution that will never change the way that protocol will be actually uh immutable and and yeah infinite then on top of that you have the OS layer which is the protocol and the tokenomics you can actually add features to this um and you you might want to change things from time to time and I'll discuss this a little bit later on top of that you

have any type of processes so how do teams come and interact Partners how do you make it compostable and how do you actually produce value towards these processes the UI part is a bit forgotten from time to time you have the different templates that you should build dashboards are super important and the documentation is also crucial in this part and finally have the users which might be the product users or Partners you have the token holders which are the owners of the actual protocol and then you have the contributors which are people that will be bring value to this on the very left I put the state which is a bit like how is the how is the system working right now what's the

what's the status and and how like how do you interact with the system in a very easy way so that will hopefully bring in more people to to participate in the community and to bring value and to to make it scale um so how do you propose the change uh and yeah it's all about dependencies so in in this example in the OS layer someone comes with this great idea of we should well in my example it's change the voting contract so we should do something different with the in the way we vote right so someone could propose that and bring the changes but then you will be forgetting anything any dependency that actually has an impact on so maybe you need to change some

processes you need to re-adapt some dashboards uh contributors need to know so anything that has to do with change management and the token holders also need to be aware of these changes so if this gets approved by the token holders hopefully they know what they're voting on and and the change gets approved if you if you're not thinking about all the dependencies what you're getting it's it's a mess because you'll have outdated dashboards the process won't work anymore you have a orphan code meaning that that some of the processes will break at some point people are not sure if you're using the the old version of the new version so it's it's quite important to to go through through the whole dependencies when you when you commit this change and

to force contributors to think about uh about them all uh so yeah a change can only be enabled when all dependencies have been solved um and ideally you commit them all at the same time you could have some kind of uh as long as everyone's a worried it could there could be some time differences but uh but you need to make sure that that any change is holistic enough to to be able to change the whole thing uh so yeah as I was mentioning this avoids orphan code and clear rules uh so it's much more approachable for people in the outside to join or for people in the inside to know what's happening next uh lack of uis right now they're not many dials that have uh all the uis

needed for for normal uses or non-technical users to operate the lack of documentation is also quite important and then you have frustrated users both from the community and from the the outside that that might have an issue with that so yeah these are these are why dependencies are are quite important how do you do this this is the governance life cycle um well it's not it's not product but it's a cycle of governance a bit so you start with the either identifying the challenges ideally you have a backlog with this and you have smart people that are managing it um shout out to any Forum managers that out there and they are the unsung heroes

of a well-run governance but then you move to the opportunity evaluation so you go through this backlog you say okay we think that it's really important that we focus on this uh opportunity right now uh these were or these were the most risk is so we should address it or this is where we can grow the most uh so evaluate these opportunities and you move to the solution and discussion stage where you say this is the the problem how we're going to solve it so you you move a little bit more towards towards that finally you go to the Frameworks or use of MVPs what does this mean it means that if you create a new I don't know a new standard or a new reporting uh you can start trying it with the really uh basic tools like like a spreadsheet and

you can move forward once that it's working and you actually know that all the dependencies are being covered um you can move it to towards making it more software and making it more accessible for contributors users Etc uh so once you have these use of MVPs that are actually being used you can make them stronger you can do an improvement proposal I would argue that this should be almost at the very very end when you have all the defenses covered and then you finally move to the software development stage where you actually make it easier and and harder to to to move uh but that yeah going through the MVP is quite important at this it's a quite important stage as well so the main takeaways software

development over managers and operators this means that teams should actually work to make themselves obsolete or to ship software instead of just running the the show right so any team that's uh I don't know giving giving an update every month or every week or every quarter about anything it you should push them to actually make this dashboard that updates on Real Time and that it's super clear for anyone to read so that we don't need you anymore and then you can set up the incentives so that they don't they have more job security or an incentive to actually move to solving a harder challenge the the Frameworks is quite important it's very easy to start attacking people

when you are some cartoon or a pet on the internet so the the four moderators or anyone in governance should try to discuss the governance compared to or discuss the framework instead of of uh of discussing the people that's why the it's very important that these proposals uh are very abstract and repeatable instead of okay we want to build these towers on you should say like okay every time we want to build towers we're going to use this recipe and then people will start thinking how how do you build these things in general and then you can apply to this instance but the important thing is that it will create equality

for everyone because anyone can come and build towers based on based on that framework instead of being like Oh the other team did it how why can't we do it um so that's that's what creates equality it's to discuss the framework and not the the people there will be less politics and and less gossip and as I was mentioning the dependencies need to be considered that that's harder than it looks but uh an improvement proposal can only be applied when all dependencies are are set so I think that's it for me today I don't know if there are any questions I'll be happy to take them but yeah if you want to reach me on telegram or by email these are these are my contacts

and thank you for listening thank you thank you Juan yeah we have about five minutes for a q a be nice please hi everyone uh sorry you mentioned at some point that um daps would uh um lack your eyes and documentation leading to frustrated users is that the only unavailable nature of the house or because because contributors are too self-centric or is

there hope for the users um is it just a question of maturation Maybe of the apps over time yeah I mean this is not uh this is not exclusive to Dallas I think that we've seen that a lot of companies go for a really long time with the undocumented software and it's harder for new joiners after a couple years to actually join this startup or scale up so I think that the documentation part is is crucial what you could do as a token holder or when you're setting up the framework is to say your product is not considered shipped or done until the documentation is there or until the UI is there and this will vary from dial to down like you could have a super small Dao of really geeky people that use the console

or The Terminal to access uh the blockchain and that's fine too but if you wanted to make it more accessible and more and open it up for for the next million people then documentation on uis are going to be crucial but but you are right that uh that it's not easy most people tend to not care about documentation but as a as a token holder you can a little bit force it it's like the work is done um so that the project that you propose includes this documentation part and the work is done whenever the documentation or the uis are done otherwise it's not it's a it's you have partially implemented it not all dependencies are covered so so sorry but it's not done yet

no one else thank you Arlene you've been great [Applause]