GM! 
Thanks @SEEDgov for sharing your thoughtful reflection. I really appreciate the grounding reminder that we’re still early in Scroll DAO’s evolution, and that we should move intentionally when designing new structures.
Given the EOC’s mandate as a cross-council operational and accountability body, I agree it’s essential that any new working group or role be aligned and not duplicative.
I’d like to zoom in the emerging question: should the Support Squad be folded into the Execution Oversight Council (EOC)? Or does it make sense to keep these roles distinct — while maintaining close operational coordination?
What do you think?
- The Support Squad should be folded into the Execution Oversight Council (EOC)
- It make sense to keep these roles distinct, while maintaining close operational coordination
Here is a short “Negation Game” exercise that outlines pros and cons of the different approaches. I hope it’s a good start.
(anyway, it helped me continue exploring the tool. More feedback to come @connormcmk).
After all this, tbh, I believe the Support Squad Pilot still makes sense as a lightweight experiment, as long as it’s designed to interface directly with the EOC rather than operate in isolation.
Why keep the Support Squad distinct?
Rather than folding the Weaver and Scribe roles into the EOC or discarding the pilot entirely, I’d suggest seeing the Support Squad as a complementary operational layer.
A support function that:
- Attends and documents council meetings,
- Helps share context between councils,
- Surfaces operational frictions early,
- Reduces overhead for council leads,
- And feeds into the EOC’s reporting cycles and dashboards.
This setup helps the EOC stay lean and strategic (High-level monitoring & reporting), while the Squad handles more granular connective work (On-the-ground coordination & process). The Squad’s outputs directly enrich the EOC’s reports, improving their fidelity and insight.
The EOC asks questions, enforces expectations, and intervenes when necessary.
The Support Squad builds context, stitches conversations, and smooths operations.
Blending both into one unit risks muddling the power dynamics, making support feel like surveillance, and diluting the EOC’s authority by pulling it into day-to-day logistics.
A Viable System Model framing
From a cybernetics systems perspective (which IMO helps organizations understand how to balance control, learning, and adaptability), we could say:
- The councils represents System 1 role (by delivering specific mandates)
- The Support Squad aligns with System 2 (operational stability and information flow).
- The EOC plays a System 3 role (oversight and coordination).
- Together, they can enable System 4 (organizational learning and strategic adaptation).
That is to say, rather than building everything into a single body, having distinct but interdependent systems can increase clarity, reduce overload, and create healthier interfaces.
By the way, this idea has some kind of precedent in DAOs. In Optimism, there are (support) roles like GrantNERDs, GovNERDs, SupportNERDs, NumbaNERDs, etc. who act as “civil servants” offering public service outside of councils (representative structures), while still being accountable to them.
On learning and adaptation
To make this actionable, the pilot could be framed as part of the EOC’s broader learning architecture, testing whether a shared coordination layer between councils improves effectiveness and reduces fragmentation.
We can also design this with built-in evaluation and handoff mechanisms, so that it doesn’t create overdependence nor permanence.
If the pilot is not useful, the tools or templates created by the Support Squad can be offered to councils to manage independently or be integrated into EOC monitoring tools.
The spirit here is to test something small and useful, not to impose a new structure. If this pilot helps reduce friction, improve documentation, and strengthen cross-council learning, that’s a win.
If not, we can stop or redesign it, together.
