[Discussion] A hypothesis: Thin workstreams lead to better outcomes

[kyle]

We have hit a point where we have five workstreams. I could probably put a qualifier on the front like, “main” or “core” workstreams as these workstreams have now come to include, at times, several smaller sub-workstreams from within them. I have a hypothesis that multi-sub-workstream structure is actually bad for governance, outcomes and accountability across the DAO as a whole. I would love to open the discussion on how others feels and if they have relevant experience from other DAOs (or opinions from those DAOs) on if my hypothesis is true or false.

Here is a quick breakdown for those less familiar. Within the five workstreams, there are potential “sub-workstreams” from my perspective:

1. DAO Ops has two potential sub-workstreams: community experience and operations
2. FDD has three potential sub-workstreams: sybil, ground control, Grants Investigation Agency
3. dGitcoin has two named sub-workstreams: dCompass and dGrants
4. MSC has two (likely more) sub-workstreams: prototypes and products
5. MMM has potentially four sub-workstreams: marketing, in-person events, Merch, Design/Memes

Here are some of the problems of this:

• Workstreams have very large budgets that are hard to disambiguate which part of a workstream is being effective and which isn’t. For example, if the Operations crew in the DAO Ops workstream is not doing well, as a steward I can advocate to change that budget, but while we debate another sub-workstream is left in limbo with their fate tied to whole proposal.
• Paying for areas of duplication is wasteful and often leads to a lack of shared learning and context
• Workstreams may feel like defecting is cheaper and easier (ie, I don’t have to really work with the marketing group already in MMM or their design guidelines, I will just hire my own people and do my own thing and fragment the Gitcoin brand!)
• Teams in workstreams become so large and exclusionary, they are difficult to enter as a new comer and even more difficult to work with as their norms and culture has become their own.

I see a natural solution to this is to try and maintain smaller workstreams such that their tasks and goals are straight forward, their funding is not tied to outcomes of others and that we focus on creating a culture of coordination and shared vision and shared reliance, with peer to peer accountability.

Right now, the Gitcoin DAO sometimes feels like Microsoft in this analogy (h/t @owocki for sharing this)

I see Future Gitcoin as being the better model here, with a mesh network and deep coordination. With smaller workstreams, each workstream is forced to coordinate, they are forced to ensure their peers are delivering and offer feedback when they are not (ie, if one group doesn’t deliver, we stop funding them and replace them instead of just creating a duplicative one to serve that need).

Smaller workstreams offer more clarity into funding and the outcomes being delivered without tying incentives together. As a steward, smaller workstreams will make budget reviews easier to go into and digest. Asking questions and digging in wont stop funding from flowing to other workstreams that are delivering.

Smaller workstreams create a culture of sharing and collaboration instead of silo`d information or empire building. They also bring about accountability through peer reviews. they are often more approachable (joining a large group as an outside is often smaller than joining a small group)

Workstreams become experts in specific areas and are relied on by many who need that service/support.

I would love thoughts from others. How do large/thick versus small/thin workstreams sound to you?

[owocki]

@kyle

How do large/thick versus small/thin workstreams sound to you?

One thing I think would be useful to untangle is how cross-workstream communications could scale in both a fat vs skinny workstream model. Here are the areas where there would need to be more muscle in a skinny workstream (more workstream) model:

1. CSDO
2. inter-workstream comms
3. there might be more?

[clasikman]

In my work experience, I witnessed that ERP (Enterprise Resource Planning) systems are quite useful for medium and large companies.

Since we are talking about GITCOIN, obviously a much broader and decentralized perspective, I can propose that perhaps the information flow of the ERP be adapted to a DAO, creating a new tentative name of “decentralized ERP” without the need for a head, which allow to integrate information from all sources, finance and production, with the ideas you raised, aiming more at large / thick workflows.

[owocki]

just saw this thread from MKR today. its interesting to see they have 20 “core units”.

Each Core Unit is responsible for a specific vertical within the functionality of the Maker Protocol, and is managed by one or more Facilitators that coordinate and pay to its contributors working to achieve its long-term goal.

[Fishbiscuit]

I think Conway’s law has been mentioned a few times in our community calls etc but what can we do about it?

Came across this article the other day and it gave an interesting example of how an organisation’s individual units can interact.

It might be interesting to see how to keep the cohesiveness of these functions yet the flexibility of smaller units. Also I can’t imagine having to vote on 20 budget proposals each round. Perhaps what we could start discussing is how each workstream interacts. Some workstreams are highly specialised and act as a ‘service center’ kind of model where other workstreams request for help (that has its own issues too because help can be somewhat ad hoc), others are more experimental and are practically stand alone (that nimbleness is great for prototyping quickly).

Following the analogy of a ‘flotilla’ of ships that are our workstreams, each ship has its own specialisations and might sometimes even break away from the overall flotilla to carry out specialised activities before returning too.

[lthrift]

@kyle

Right now, the Gitcoin DAO sometimes feels like Microsoft in this analogy

I wonder if the dynamic between workstreams is a symptom of thick workstreams or something else. In our retreat sessions that were focused on cross-stream coordination, there was a theme that we collectively lacked a shared vision, understanding of workstream charters/domains, and a mutual operating system. My hypothesis would be that this contributes greatly to the challenge felt between/across workstreams, more so than the size of the workstreams themselves.

How do large/thick versus small/thin workstreams sound to you?

Principally, I think thinner workstreams are great! In fact, my prior career experiences in software development supports the concept that more people ≠ better or faster development, it actually = greater complexity to manage.

Related to the article @fishbiscuit linked above, Gitcoin Product Group has been using the concepts of Domain Driven Design to not only breakdown the monolithic, centralized codebase we have today, but also to organize into teams who can work autonomously in smaller numbers of people.

I do wonder how many thinner workstreams scale. At the inner-workings of each workstream, I’m very supportive as it reduces the cognitive and relational overhead of the team which keeps the path to decision making fairly frictionless. At the DAO governance and cross-stream operational level, I wonder about how we maintain alignment and cohesiveness. Maybe once we have an explicit DAO operating system we can more easily identify a tipping point for the effectiveness of thin workstreams and choose to revisit should we reach that point? A reference I find useful when thinking about tipping points like this is this mathematical equation for the scaling of interactions required to make a decision as # of people in a group scales up.

[DisruptionJoe]

@lthrift

I wonder if the dynamic between workstreams is a symptom of thick workstreams or something else. In our retreat sessions that were focused on cross-stream coordination, there was a theme that we collectively lacked a shared vision, understanding of workstream charters/domains, and a mutual operating system. My hypothesis would be that this contributes greatly to the challenge felt between/across workstreams, more so than the size of the workstreams themselves.

I think this hits the core of it. I’ve had a few conversations with @samspurlin about structure and he keeps pushing me back to the work that needs to be done. The structure will always produces second and third order effects we don’t want unless it is in service to the mission. Because we are in a complex environment, that means org structure is probably less important than our heirarchy of values, priorities, problems, or other.

I really like the domain driven design blog you shared. It seems to be saying something similar to what we identified in the workshop at the retreat… that for our situation, it seems that a heirarchy of the problems we want to solve should be at the core of how we understand our mission. The structure should follow the problems, not the other way around.

I’d love to participate in some facilitated sessions with our leadership across DAO and holdings to directly address this.

@Fishbiscuit

Following the analogy of a ‘flotilla’ of ships that are our workstreams, each ship has its own specialisations and might sometimes even break away from the overall flotilla to carry out specialised activities before returning too.

This is great because it recognizes the need for different sized ships and how some keep in closer contact than with others.

@kyle

Workstreams have very large budgets that are hard to disambiguate which part of a workstream is being effective and which isn’t. For example, if the Operations crew in the DAO Ops workstream is not doing well, as a steward I can advocate to change that budget, but while we debate another sub-workstream is left in limbo with their fate tied to whole proposal.

This depends on if the leadership is trusted to execute on the task. How much failure is acceptable? By offering leadership group, for example in DAOops, to excel in a few areas and try new things, they develop contextual learning over time. Yes, one substream might fail for a quarter, but the best outcome would be that those people learn and adapt to find a successful strategy. If they don’t, we should be clear about why we wouldn’t vote for an entire budget beforehand. The CSDO should probably discuss this and develop a strategy to split a workstream which is then recommended to stewards. (And the workstream in question should never be blind-sided on the forum. Let’s be humans first.)

@kyle

Workstreams may feel like defecting is cheaper and easier (ie, I don’t have to really work with the marketing group already in MMM or their design guidelines, I will just hire my own people and do my own thing and fragment the Gitcoin brand!)

This sounds like you are thinking “How can we force them not to defect?” rather than “How can we convince them that they don’t want to defect?”. To me, this is the role of DAOops which can take guidance from CSDO on the services they provide.

For example, instead of DAOops telling FDD that we can’t have discord permissions that would make life easier for us and that be that, they could offer a set of services to “structured” workstreams so we willingly accept the constraints in exchange for these services.

Services offered to structured workstreams could include: service discounts from other workstreams such as mmm marketing, participation in group SaaS deals, access to events, and explicit support shown from CSDO as a strong signal to stewards.

Basically, can we think of how we create mutual consent rather than asymmetry of options?

[DisruptionJoe]

One more thing on defection: WE WILL LOSE TALENT if we take the mobster approach of “Give them an offer they can’t refuse” with a subtext of “I’ll break your legs” rather than a subtext of “This is the best place to be”

[annika]

I’m supportive of the idea of thin workstreams, and my articulation of ‘the why’ is largely in line with what @lthrift shared:

In fact, my prior career experiences in software development supports the concept that more people ≠ better or faster development, it actually = greater complexity to manage.

With that said, I don’t think the approach of just thinning out our existing workstreams – e.g., breaking the five examples into the sub-workstreams you articulated – will work in our current construct/norms. A couple tangible examples that would become nightmares:

• Getting things done in CSDO forums (if we have 20 workstreams x 2 reps / workstream, consensus-based decision-making will be near-impossible)
• Getting stewards to review 20 quarterly budgets

We would need to change the way we work on a number of dimensions. Perhaps CSDO involvement is limited to workstreams of a certain size, ‘reputation score’, or tenure. Perhaps budget preparation guidelines could be bucketed based on amount requested that quarter, and required steward voting/involvement could scale depending on the workstream’s size, scope, or even past performance with allocated budget.

In summary, I’m supportive of the idea, but on the pre-requisite that we re-think the way we work for these types of considerations in advance.

[kyle]

@DisruptionJoe

WE WILL LOSE TALENT if we take the mobster approach of “Give them an offer they can’t refuse”

Can you say more here? I am not following this.

[tigress]

It’s tempting to outline solutions and give answers immediately. What I would like to offer is a new perspective and I encourage everyone reading this to be in the questions. If you are feeling pressure to come up with answers, deeply welcome this need and come back to the questions.

So, what if we expanded our space and adopted a more integral mindset? **)

Yeah, that sounds intersting, Tigress. But what do you mean by that?

Small, thin and maybe even lean workstreams sound like an appealing solution to the problem or challenge which might be:

@kyle

… that we focus on creating a culture of coordination and shared vision and shared reliance, with peer to peer accountability.

However, proposing changes to organizational structures and practices are always a popular point of trying to intervene in a system**). To make and facilitate the change from a Microsoft-ish organization towards a more “mesh-network styled” organization that fosters deep coordination, I feel we need to evolve our thinking and cover a few more perspectives.

Especially as it seems that there is no clarity in terms of the mission/vision.

@lthrift

there was a theme that we collectively lacked a shared vision

@DisruptionJoe

it seems that a heirarchy of the problems we want to solve should be at the core of how we understand our mission

Here are some ideas to zoom out and widen our perspective. Just be in the questions for now.

The “I” or “ME” Perspective - that is my thinking and leadership

• How can I create more self-awareness about the things I project onto the organization? Where am I right here and now? (Video)
• How do I and my peers experience my leadership? (Interesting tool)
• How can I evolve my thinking and feel less like “I make life happen” or “Life happens to me” and more like “Life is happening through me” or “I co-create with life happening”. (Worksheet / PDF by CLG )

The “IT” Perspective - that is our practises and behaviours

• How can we better integrate feedback loops in our system and make the process of how we are making decisions more conscious and fluid? (e.g. consent- vs. consens-based decision making)
• How can we better pick up on signals of what is emerging?
• How can we fairly compensate and take the issue of money off the table?

The “WE” Perspective - that is our culture and relationships

• How does the culture feel like we intend to co-create here?
• What contributes to aligning ourselves towards a shared(!) vision/mission?
• What does “success”, “scaling” and “growth” mean for us?

The “IT’S” Perspective - that is our environment and structures

• How can we, as stewards and servant leaders, get clear a shared vision/mission and co-create ways of working which, in a transparent and likely consent-based manner, allow for getting things done according to priorities and also open up the space for emerging ideas as well as support growth of the DAO and the human beings(!) who work with it?

Moving forward: What is the next “holistic” / integral baby step towards a “meshwork” covering all the 4 perspectives? And what do I personally need to let go of to support this?

Thanks for your consideration I hope this write-up was inspiring and is serving the way forward.

If I can support in any way, pls let me know.

Footnotes & Appendix:

**) Evolving our mindset and consciousness is seen as one of the most effective leverage points to intervene in a (complex) system *
As Einstein said: No problem can be solved from the same level of consciousness that created it.
More on Integral & Organizational Development in this whitepaper

Places to intervene in a system
(in increasing order of effectiveness)

9 Constants, parameters, numbers (subsidies, taxes, standards).
8 Regulating negative feedback loops.
7 Driving positive feedback loops.
6 Material flows and nodes of material intersection.
5 Information flows.
4 The rules of the system (incentives, punishments, constraints).
3 The distribution of power over the rules of the system.
2 The goals of the system.
1 The mindset or paradigm out of which the system — its goals, power structure, rules, its culture — arises.

[DisruptionJoe]

The tendency we have had thus far is to create “guidelines” for workstreams in the CSDO and then expect them to be followed. As we build out CSDO into a “strong signal” for stewards to know what work is aligned with a GitcoinDAO roadmap and which are independent ventures, we need to be sure that participants willingly accept constraints because of the benefits they receive from participating.

It’s like a relationship. If one partner stays because the other pays the bills, then there is a power asymmetry that doesn’t truly create autonomy. But this doesn’t mean that the partner is staying only for that reason.

I think we should be explicit about the power dynamics we create. Additionally, we should look at the relationship between workstreams and CSDO to be sure there is mutual consent driving the relationship rather than coercion.

[owocki]

in order to support collective sensemaking, id be interested in having a live conversation in which the DAO workshops the tradeoffs in this design space. i find the convo on discourse to be hard to follow, + therefore its hard to build collective understanding.

[muratgozel]

It really looks like we are creating departments and eventually a hierarchical org with people who is excited about DAOs and web3.

I like how we do science. If someone comes up with a theory, they crush it first with various kind of objections in their forums/environment. Eventually, time decides if that is a true/false theory. In science, nature is the ruler and it coordinates us the way we don’t even feel like being coordinated.

Considering Gitcoin as a sub-nature aligned with nature. What is the Gitcoin’s physic of laws? We have a nice mission statement like “build & fund public goods” but what is/should be inside of it? What the world would look like after public goods are funded and built? If we answer these questions clearly then anyone can propose something to build for Gitcoin without the need for rigid workstream/substream structures. If we don’t, workstreams and roles get stronger and evil.

We try to use the raid system in MMM where anyone can come up with a project idea and then team up + start to work if it gets approved by MMM leads. The Raid system is beneficial in terms of decentralized structures because the roles you have stays in the scope of the raid. After the raid, you have no role. If a raid is perpetual, rotate the roles.

In my opinion, anyone in any workstream should be able to propose something that is in the field of another workstream. They can team up with any people they want. The important part here is the evaluation of the proposal. What if they missed something that another workstream wouldn’t miss? That something could be related to the expertise in a field or could be related to the physics of law of Gitcoin. In conclusion, I would recommend a unified environment for proposals/projects, not workstream specific. This would also be part of domain driven design.

This is how I envision the structural ideas:

I know thinner workstreams or raid-like approaches create more chaotic environments but that’s mostly a tooling problem. These approaches can provide a more open, inclusive community eventually.

[krrisis]

Great thoughts, thanks for sharing Kyle.

Some comments/thoughts while reading, without reading other comments first (on purpose):

@kyle

Workstreams have very large budgets that are hard to disambiguate which part of a workstream is being effective and which isn’t.

Splitting it up into more workstreams also means more budgets to check, so not sure this solves a lot. I’m not sure that initiatives within workstreams have suffered a lot from delayed budget approval. On the contrary, I think that - while we have not recruited more leaders - have benefited from having to deal less with the overhead of budget requests & reporting by themselves.

@kyle

Workstreams may feel like defecting is cheaper and easier (ie, I don’t have to really work with the marketing group already in MMM or their design guidelines, I will just hire my own people and do my own thing and fragment the Gitcoin brand!)

This is a crucial argument to me. However, I don’t think the size of the workstream is the issue here (more below).

@kyle

I see a natural solution to this is to try and maintain smaller workstreams such that their tasks and goals are straight forward, their funding is not tied to outcomes of others and that we focus on creating a culture of coordination and shared vision and shared reliance, with peer to peer accountability.

I agree to some extent. I think the workstreams doing really well here are PGF and MMM, who actively seek more cross-team collaboration, for DAOops it’s even at the core of its existence.
I think FDD especially could benefit from being a thinner workstream because there is a lot of duplication in tasks happening here. (esp. on the coordination level) and I don’t think we need this, not at this point in our existence.

MC & DCompass have to some levels already defected, in the sense that they do not follow some of the basic shared infrastructure (namely the gitcoindao discord), which is the opposite of what we want to achieve (namely a mesh network with deep coordination).

However, to me (my hypothesis), what we are seeing in a number of workstreams is not linked to the size of the workstreams, it is a people thing. DCompass and MC are not really large workstreams (they are even very small in comparison to FDD in terms of headcount).
To me the breakdowns and opaqueness we are seeing is because we have not focused enough on hiring (skilled) enough project managers and people with deep communication skills, who actually see the benefit of collaboration over competition.

People with soft skills naturally gravitate towards ‘softer’ Workstreams such as PGF, where @ceresstation has very much created a vibes & people culture, with the public library but also eg the partnerships initiatives as straightforward examples. MMM is 100% about (external) communication and DAOops mission is literally operations of the DAO.

Next to communication skills of people I think the second element of breakdown is linked to not having defined our mission & vision enough. If the objectives of the workstreams are more linked to the objectives of the DAO as a whole, it becomes easier for stewards to evaluate if the setup of a workstream makes sense overall.

These two points seem to be of a higher priority than making Workstreams ‘thinner’, although I deeply agree with the overall sentiment. I hope in the future we will become a mesh network, but I do believe in progressive decentralization, until we have hired the right people and have better defined our overall mission.

And now I’m going to read all the other comments

[krrisis]

Agree, although it’s interesting to dive deeper into people’s logic and deep knowledge on some of these topics. (Just wish there was more time to read it all.) @Jodi will be proposing strategic work sessions that do exactly this (I think during the next csdo call) after @annika bringing this up last week (sync happening on proposed initial format).

[krrisis]

@muratgozel

In my opinion, anyone in any workstream should be able to propose something that is in the field of another workstream.

I agree this is where we should end up. But I think we could/should get there over a timeline of eg two years, once we have all the checks & balances in place. At this stage of our existence I think we still need to fix/build a lot of the basics.

[ceresstation]

In general I’m for the idea of more, smaller workstreams but I think one thing I would caution us on is adding too many new workstreams before we get the existing ones “right” in some sense (and I think perhaps what that sense is could be considered at the heart of the conversation).

The one thing I’ll say up front though is that I really think the point about making sure workstreams have clear outcomes with aligned incentives is an obvious win and I do worry that we’re falling into some of the classic traps of bureaucracy as things stand right now (not that progress isn’t being made).

Onto the proposed reasons for thin workstreams (which, again, I’m not actually that against):

• Workstreams have very large budgets that are hard to disambiguate which part of a workstream is being effective and which isn’t. For example, if the Operations crew in the DAO Ops workstream is not doing well, as a steward I can advocate to change that budget, but while we debate another sub-workstream is left in limbo with their fate tied to whole proposal.

I personally believe this has less to do with the size of budget and more to do around the specificity of outcomes relative to intended goals in each stream as above.

For example, MSC (which I mean, I love personally) is often discussed as the place for builders to come and create various types of coordination tools, but I think we’ve recognized this is a very broad scope that in some cases hits the bullseye in terms of making meaningful progress towards DAO impact, but in other cases results in many tools being built that are showcased then put on the shelf.

If workstreams were to build the muscle of being precise about how the work they do drives outcomes for the DAO at large I don’t think anyone would have issue giving them larger budgets.

• Paying for areas of duplication is wasteful and often leads to a lack of shared learning and context

I generally agree with this one, right now I can think of a few areas where this is true and one is actually between PGF and MMM, which are actively working together on how to create cross-stream flows to avoid duplication. I think it’s likely more important that we get really really good at this with a small number of workstreams before we add more. That said, it’s important that folks are genuinely open to this and feel comfortable enough to extend support to each other. To me this is all about building up a culture focused on a) pushing forward outcomes b) vibing together with an understanding that we all want the same thing (public goods go up).

• Workstreams may feel like defecting is cheaper and easier (ie, I don’t have to really work with the marketing group already in MMM or their design guidelines, I will just hire my own people and do my own thing and fragment the Gitcoin brand!)

I think in general I’m of the view here that if we streamline existing workstreams this problem will partly resolve itself. For example, we could go out and build all the brand assets we want for PGF, but if MMM is already doing this well (scaling to meet demand and get things done quickly, listening to feedback) I think most workstreams will find it obvious that just partnering with them is much better than duplicating efforts.

In the case of PGF, I fully expect people to hold us accountable in the same way (e.g. are we scaling rounds and the funding for them as we said we would).

• Teams in workstreams become so large and exclusionary, they are difficult to enter as a new comer and even more difficult to work with as their norms and culture has become their own.

This I actually suspect is more a problem of our documentation (which I would love to see us level up in Notion) and our general onboarding flows (which I know folks are already making tons of progress on).

There’s probably more I could add here but these are some of my initial thoughts, in general I like the exercise and I’d definitely recommend we take some time to think about, in all workstreams and projects we’re taking on, how it really furthers the mission in a clear way.

[puncar]

I generally like the “two pizzas” rule for creating a team. As it was mentioned above, more people in development create rather a complexity and it makes progress slower.

But I would argue that we already have small teams, but sometimes it’s just part of the larger umbrella. For example, FDD has ~20 different initiatives run by small teams, but they are part of the larger structure to coordinate towards the same goal.

So I don’t think we need to create smaller teams; we need to build a culture of cooperation, which starts with the right incentives in place. This means to answer one important question, what is the benefit of collaboration?

Those benefits are sometimes very hard to see, especially when you grow the organization fast and everyone focuses on their work and doesn’t want to be disturbed because they want to prove themselves.

And it’s very natural; everyone wants to create a good impression and defend their position.
I think that the best way from a competitive/uncooperative environment is to start making solid connections not between teams but between individuals. It can be a buddy system, mentoring, or counseling, but you need to ensure that those connections are balanced and cross-teams.

A bad example would be having 20 mentees and creating a Puncar group.

A good example is that those 21 people are connected, but no one has more than two mentees, and those people are at least from 2 workstreams. Then you are creating cross-workstream connections on a personal level, which will eventually support cross-workstream collaboration on projects as well.

To sum it up, DAO is about people and we need to make sure that People work together and share the same mission.

[DisruptionJoe]

@krrisis

I think FDD especially could benefit from being a thinner workstream because there is a lot of duplication in tasks happening here. (esp. on the coordination level) and I don’t think we need this, not at this point in our existence.

Can you say what exactly is being duplicated?