I appreciate the System 2 framing, Alex, it clarifies that we need an operational backbone to let other units move faster, similar to the intent behind Arbitrum’s OpCo. However, I agree with @ZER8 that we should likely scope the primary Councils first so this squad doesn’t end up searching for work; Regarding terminology, while the “Weaver/Scribe” titles add culture, using standard terms for formal proposals might help us avoid the accessibility barriers .To move this forward and settle the redundancy debate, could we see a simple comparison table.
Hi there! 
Glad to see that this topic is gaining interest again. 
@404Gov, @Eren_DAOplomats Thank you all for the thoughtful comments and generous critique. 
I want to share a few reflections to clarify the intent behind the Support Squad proposal and offer a broader frame that could help us find alignment.
Should we integrate these support roles into each Council rather than having a dedicated team?
Let’s start with the idea that each Council could simply take care of its own documentation and comms. To explore more about this, I recently ran a Negation Game I invite you all to poke around.
While integration may reduce formal structure, it actually increases redundancy (every Council reinventing similar tools/processes) and makes it harder to maintain continuity across cycles.
But wait, there is more… 
There’s a lot of talk about “primary Councils,” but I want to flag a quiet risk: we don’t yet know what Councils are truly needed.
Starting by defining them (before clarifying support roles or workstreams) might lead to the real organizational bloat: councils invented for symmetry, then filled just to signal decentralization.
It’s worth asking if it’s more efficient to design for the minimum scaffolding necessary and build upward from recurring operational needs.
It is understandable to associate OpCo with a legal wrapper. But that’s not what we’re proposing. The “Support Squad” here isn’t a legal entity.
It’s a functional system for delivering cross-cutting support roles. It’s part of governance structure design (precisely to remain lean and agile). 
On the question of scale:
it’s a myth that support roles are only needed once you reach hundreds of contributors.
I have worked in a 5-person team where we applied similar principles: System 1 (ops), System 2 (support), and it made our collaboration far leaner.
These are roles, not fixed job titles. One person might hold multiple roles, but mapping them clearly leads to better accountability and less confusion.
In terms of overhead:
In fact, having a dedicated Support Squad might be more cost-efficient than splitting these tasks across Councils.
Why?
-
Council seats must be filled by delegate voting. The process (evaluating profiles, running votes, onboarding members) is resource-intensive.
-
Council members often command higher hourly rates due to reputation or experience, while support contributors tend to be operational grinders, not governance rockstars.
-
Having shared templates, standards, and rituals for documentation and transparency across the DAO saves everyone time; which translates directly into budget efficiency.
More deeply, this isn’t about forming another “team” but rather distinguishing between different kinds of work.
- System 1 (execution) = 3-month gigs,
- System 3 (auditing) = 6-month or yearly cycles
- System 2 (support) = 12-month continuity (to build institutional memory and shared context).
You can think of this as a time-based modes of commitment, not silos nor legal wrappers.
About naming:
There are no perfect “industry terms” for what we’re all building here. We’re on new ground. 
That said, I’m fully open to alternative names.
I personally like “Support Roles” because it captures the spirit: holding the organization so that others can shine.
But ok, let’s keep the door open to other framings as this evolves. 
Thanks again for the engagement.
I’m here to build something useful with you all. 
2 Likes