Do we have a culture of bureacracy in Genesis?

There have been murmurs about a sense of ‘bureaucracy’ in Genesis, perhaps better described as carefulness. The majority of proposals we are seeing right now are about communications/reports or concepts and plans for things that might be built in the future, rep requests, token exchanges, and functional things like ‘slash this rep’ etc. As of writing we have 67 ETH in the balance of Genesis and a lack of proposals that will use this building concrete things for Genesis. Are we missing an opportunity here?

There are definitely layers to this (so-called) problem;

  • we want to sensibly spend our funds and try to produce value
  • we seem to have had a focus on building according to lean principles (i.e test, prove value, iterate)
  • there has been a limited ability to build features and integrations for alchemy due to lack of documentation and road map (this is a top priority of the DAOstack team now)
  • we know Genesis Beta is coming
  • we want proposers to show they will be accountable

One thought from @liviade was that the lack of accountability at the protocol level is contributing to a need to try and ensure that proposers will deliver value by creating more loopholes up front. ie. ensure proposals are split into distinct parts rather than lumping them together, show how the proposer will deliver short term value and so on

An escrow function (so that with bigger proposals we have the ability to pay some funds up front and the rest when proof of work can be shown) is being prioritised and will be built.

Another thought is that the time for non boosted proposals (29 days) adds to a feeling of slowness, i.e. if you’re burning to start something - it’s annoying to know you will have to wait so long. Please chime in with any other product/protocol factors you think are playing a role here - and if you disagree with this analysis feel free to say so.

I am interested also in hearing thoughts on what is and could be happening outside the protocol or product. Especially around norms and principles we might be inadvertently introducing.

The three original principles of Genesis Alpha are:

  1. Decentralize
  2. Have an experimental mindset (know this is a sandbox)
  3. Build for scale

Are we also seeding a principle of ‘thinking little’ by down voting unless proposals fit the format of previously passed proposals and other factors mentioned above? If this is a principle and has become part of the Genesis Alpha culture one side effect is that we signal don’t ‘join/do/act/propose you’ll probably be downvoted’: there are already many entrepreneurs and interested people that join and never write a proposal and some that do spend their valuable time proposing things that don’t meet our offchain norms.

What proposals/ideas/adventures could we be missing out on?

What are your thoughts?

6 Likes

Greetings from Koalaland! :koala::fast_forward::rainbow:
Great post @Kate, you’ve touched on some of the most important aspects of how should we collectively collaborate to promote and scale a culture of innovation.

Some thoughts that come to mind:

Lean Approach
Taking the lean approach in itself is a very healthy thing that we shouldn’t change and the good thing is we’ve set a natural limit having a reasonably small total funding resources on the DAO at any given moment. We couldn’t “splurge” even if we were less careful.
It makes sense to have a progressive ‘trust’ that correlates to funding size given allocated to an individual or team, starting off with a small project can demonstrate the capabilities of the proposing party to deliver value. This can ensure alignment of values with the community and give time to gain sufficient experience for both the community and the proposing party to build a relationship. This way the community can evaluate the real impact of funded proposals a party has received thus far instead of taking a blind leap of faith.

Impact
A question that we should ask ourselves is what kind of impact do we want to encourage, IMO, we don’t need to restrict the scope and area of activities, but, we should evaluate the projects that we see through GenDAO on impact basis more than on optics basis: To encourage meritocratic culture and foster innovation, we should prioritise proposals that show clear action bias. If track record shows the party is likely to deliver meaningful impact we should ‘give points’ to that too. What we shouldn’t do is fall into the trap of preferring proposals who are most well written, polished and leave little gaps in their logic, but, present questionable impact. These things accumulate over time as signals particularly after people have worked on few funded project through the DAO, the beauty of DAOs is that you can easily view the unintended signals by browsing historical proposals and it will tell us about the nature of the project a party is involved in and thus we can evaluate them objectively over time.
Making the proposal stage as short as possible is crucial if we want to encourage entrepreneurship because investing too long on drafting proposals means that an entrepreneur allocated time to that proposal admin cosmetics rather than being in the field, experimenting, developing, onboarding etc.

Inclusion and signals
The DAO is a fertile ground for experimentation, it’s awesome to see how people bring initiatives that blaze the trails of what the future of work and distributed organizations look like, CuraDAO, PragueDAO, the #Blockathon DAO are interesting and important initiatives. It’s crucial that we continue letting things emerge organically, yet, be critical enough to judge things over time and adjust, sometimes a promising proposal can be abandoned because the proposers have other life matter to attend to, other times a small weird proposal can grow into an impactful initiative. Our role is to allow as many flowers to blossom and by that be inclusive, yet, to also call out when the DAO is abused, no matter how much reputation or otherDAO politics weight a proposer may carry. This is a tough challenge to have the delicate balance between inclusion to a culture of ambition and excellence which we should foster.

I recall seeing somewhere the “DAO Police” sort of thing that aims to evaluate and encourage accountability, I’d like to introduce a difference approach: “DAO Disruptors” instead of policing, push the limits, poke the community where bureaucracy is taking over.

I have to thank @eric.arsenault, @patdaostack, @AdrienDLT and @alexz for poking holes in a proposal I drafted that got downvoted and failed recently LOL. This encourages me to prepare a more robust planning for that project with the same original vision and I take the proposal failure as a learning for me to improve for the next iteration. At the same time, we should also be careful not to fall into voting pattern reasoning that will result in what @Kate called ‘thinking little’ and discourage innovators to interact and spend time on writing any proposals and encourage admin-y proposals only that are more predictable but also don’t encompass the same impact potential.

Final comment: We’ve got a lot of reading resources and that’s great, but we should not expect that all a condition to getting involved would be that people take a course in GenDAO before starting to act, rather as a community collectively make the process simpler through the realms we each operate :purple_heart:

5 Likes

Admin note: moved to Genesis subforum.

I’d interpret this bureaucratic aspect (carefulness) as: the fact that those who submit proposals spend a lot of their time communicating via many channels before the proposal is submitted & while the proposal is being voted on.

On one hand I think it’s totally normal for someone new to the community to do that for her/his first 2 or 3 proposals. Each contributor has to educate her/himself, what I mean is one must learn the current standard set by the community & the most efficient way to do that is to communicate via the 3rd party tools currently used (Telegram & Discord).
On another hand, it’s been frustrating for me to have to learn that way. The price to pay for being part of an Alpha Community combined with a Beta Alchemy built on Beta (Alpha?) backend.

Maybe we have to lower our expectations & simply be more patient?

As Alchemy evolves, I think that a lot of the communication will move to the platform as it’ll be a lot more efficient & some more advanced features such as reviewing/versioning will be built in.
And as Genesis evolves, I would see standards emerge, contributors mature & the “proposal lifecycle” come to something everyone is very happy about.

Regarding the standard set in the community, we’re having discussion on how much people should get rewarded, I believe this will help us all understand each other more, come to consensus more easily & allow newcomers know what they can get for helping build GenDAO & DAOstack.

Regarding the proposal lifecycle, this may evolve and we may see things such as the preproposal process (“grace period”) added to Alchemy: community standards affecting the product! Pre-proposal effort is probably a very big topic, think of it as your campaign before people rush to the polls: it kinda makes sense. Whether one wants to leverage this phase to convince people, or to let others influence her/his proposal is up to that person.

Agreed. If we want more builders, coders I suppose, then we probably need to get the word out & have documentation that helps Devs.

That’s awesome

The proposal lifecycle is complex, which would be ok if there was more guidance for the user within the app. That’s how other collaborating tools do it. It makes the tool less intimidating & gives a sense of control to the user.
The challenge I see here is that we’re still in Beta so if we add that sort of in-app guide, it will be one more thing to update every time DAOstack is updated. I guess the team will have to decide whether it’s worth the trade off.

I’m considering working with Devs who don’t have time or interest to learn the tool or/and have very low interest in being very active in the GenDAO (i.e. they are introverts or/and too busy). My role would be to identify the potential tasks to work on, draft proposal, write specs, create mockups, come up with an estimation, submit proposal, etc.

I’ve seen such tiny teams of 2-3 people do an amazing job in other decentralized organizations. So I’m excited to experiment this model in the GenDAO.

Totally agree. That’s where I always come back to:

  • tools built into Alchemy; unless we have them, we have no choice but use 3rd party tools (such as Telegram) and check on proposal status manually. This obviously does not scale.
  • standards set by the community; unless we have them, it’s difficult for anyone to know what’s acceptable or not, even more so for newcomers

Agreed. Being downvoted on is very frustrating & will put people off if for instance one gets several proposals failing in a row.

Maybe the right question is: How lose should one be with her/his opinion? As in, maybe it’s a factor we should discuss as part of our community’s standards. One may think that someone’s proposal is very poorly written but if one is told to only downvote a proposal if it crosses specific lines, then she/he will follow that guideline.

I think the proposals are a reflection of the people who are willing to join and go through the process. Most of the people who joined, are not devs, so there isn’t much building of things for Genesis. There also may be a bias because Genesis is built by DAOstack, so people don’t want to tread on that territory.
I’m curious about the “carefulness.” What are we being careful ABOUT? There isn’t much money at stake. There isn’t much community at stake. We aren’t touching the code. What are we being careful about exactly? The system was designed for playing and breaking, so how did we end up with something so “careful”.
My personal experience was of unnecessary bureaucracy of over 6 months before being asked in June to do the exact same thing I was asked to do in January. I didn’t have an experience of carefulness – but the experience seemed more to be in consideration of collaboration. However, the collaboration time was not compensated, so a lot of people put in a lot of time to something without any reward.

I think, in answering this question, we first need to understand to what extent our own actions have contributed to any bureaucracy, per say, and to what extent the protocol’s and application limitations have biased ourselves into a certain direction. And I think @liviade hits the nail on the head with the idea that the lack of accountability features has most impacted our decision-making. My general opinion, all things considered, is that the counterfactual GenDAO we can try to imagine without this sense of “bureaucracy” could not exist given the immanent protocological and application biases.

It’s important to emphasize this isn’t a bad thing. It is, like all elements of this project, a process of discovery. And I think it’s a smart concern: while accountability isn’t currently a huge issue, given the low budget as @Grace for instance has pointed out, it will be an issue in the future when DAOs begin to manage larger budgets. I don’t see being cautious here as a bad thing, if anything, it’s lead to best practices and insights that have been important to discover for the future, such as the need to prioritize a streamlined escrow function.

I’m not so quick to dismiss the value of off-chain norms; I don’t think, for instance, expecting proposals to be organized or proposers to be accountable is bad (or even norms exclusive to GenDAO, really; this is fairly standard to any grant-writing process). The main issue is anyone saying not to submit a proposal in the first place: this is ultimately defeatist and irrational as there is no cost to the proposer, save gas fees, for a proposal to fail. So if anybody is saying, “don’t bother submitting a proposal,” this is fundamentally an issue.

There’s a general misconception that feedback is received by asked for it. The easiest way to get feedback is to submit a proposal. Given that there’s essentially no penalty for a failed proposal, if anything, it increases the likelihood of passing a resubmitted version that incorporates voter concerns that are due to be expressed in the vote.

This deserves to be emphasized, not because it’s true, but because it’s the basis of any salaried or recurring proposal. If somebody in your business is doing well, you don’t ask them for a weekly action plan: you pay them with the tacit understanding that will continue to do well (unless, of course, they stop performing). I’d like to see more reoccuring proposals distributing funds to individuals who have proven themselves with one or two solid deliveries who we can implicitly trust in the same manner.

This is fundamentally a feature issue similar to the lack of escrow mechanism: ideally, the only official channels for proposal communication would be within Alchemy itself. Right now Discord/TG is seen as a semi-officialish channel, which isn’t at all the long term goal. The vision in the long term is for there to be one hundred different “Genesis” channels (note that a community like Bitfwd, which has its own chat, effectively is managing a “Genesis” channel as they are a significant part of the DAO, even if it’s not explicitly articulated), covering many applications and communities. The channels provided by the DAOstack team (or more specifically, the comms team, which I manage) are a service, but they are not meant to be a local monopoly in the long-term, as this is inherently unsustainable. As GenDAO maturates I’ll be taking special care to emphasize this point. Coincidentally, I have no desire to moderate a ten-thousand active person community.

Please do, and loop in @Shiv to help!

I’d like to emphasize something here: there is no need to ask permission, or try to actively collaborate with members of the GenDAO on the same initiative. If people are wasting time, especially in bureaucratic fashion, it’s extremely important to understand that one can and should move forward absent their collaboration, and GenDAO should aspire to reward this keen entrepreneurial behavior :slight_smile:

2 Likes

Bruh, you’ve really captured whats essentials in this thread. I’d say your response could be packed into a worthy talk on DAO in practice for that Devcon session Laine was calling for or the DAOfes :slight_smile:

1 Like

Great discussion

In service of action I’m pulling out some key points which may help us going forward. Let’s discuss in the weekly call… Perhaps some of these are extensions of our Principles which to be built into the tool somehow?

  • Have a progressive ‘trust’ that correlates to funding size given allocated to an individual or team, starting off with a small project can demonstrate the capabilities of the proposing party to deliver value. (@exponent /Daniel)

  • To encourage meritocratic culture and foster innovation, we should prioritise proposals that show clear action bias (Daniel)

  • The proposal lifecycle is complex… more guidance for the user within the app [needed]. That’s how other collaborating tools do it. It makes the tool less intimidating & gives a sense of control to the user. (@AdrienDLT

  • Making the proposal stage as short as possible is crucial if we want to encourage entrepreneurship because investing too long on drafting proposals means that an entrepreneur allocated time to that proposal admin cosmetics rather than being in the field, experimenting, developing, onboarding etc. (Daniel)

  • The easiest way to get feedback is to submit a proposal.** Given that there’s essentially no penalty for a failed proposal, if anything, it increases the likelihood of passing a resubmitted version that incorporates voter concerns that are due to be expressed in the vote. (@patdaostack

  • The channels provided by the DAOstack team (or more specifically, the comms team, which I manage) are a service, but they are not meant to be a local monopoly in the long-term, as this is inherently unsustainable. (Pat)

  • There is no need to ask permission, or try to actively collaborate with members of the GenDAO on the same initiative. (Pat)

*The system was designed for playing and breaking, so how did we end up with something so “careful” (@Grace)

Some thoughts from @matan on this also:
"This is a subtle point, on one hand we’re trying to push quality proposals and have voters not approving every proposal; and on the other hand we’re trying to not create too much bureaucracy. It doesn’t mean proposal should not be screened in advance and get people’s feedbacks and backing but;

Bureaucracy is a very subtle and elusive thing. What is it? there’s a thin line between bureaucracy and responsibility and we need to nail it. Rather than explaining what it is, it’s easier to explain what it has or what it smells like, and bureaucracy has, as a bi-product, power unproportionally concentrated by few people, and it smells unfair and frustrating."

Better late than never. I agree with 99% of the above, below are two things which stand out that i don’t necessarily agree with:

  1. I’m not sure I agree with "Making the proposal stage as short as possible is crucial to encourage entrepreneurship’. I agree it plays a role, but I do not think shorter is always better. For one, it requires a lot more attention from DAO members, and there are higher risks of passing proposals which are not representation of the group.
  2. I would also caution from claiming that bureaucracy smells “…unfair and frustrating.” any more than responsibility does. I would argue that that both bureaucracy and responsibility feel this way to the proposer. The main difference between the two is likely around the support, transparent communication, and general interest in having the proposer succeed.
1 Like