# Managing Multiple Workstreams Do we want to promote a certain type of structure or support multiple different structures, even if we don't neccessarily use or support them. - managing multiple products/work streams - decentralized vs centralized - decentralized is the goal - flat org - bottom up - prove with v3 that building decentralized products is possible - building with teams with aligned visions - workstreams can have a 'leader' - product squads with team leads - needs at least one owner - open source vs closed - focus on open source projects - code license will ~~dictate~~ open source requirements - offering scaffolding to build openly - workflow models - have a place to collect ideas (simple doc/form) - start with high level user story - then start specing out and defining tasks - kanban board for task management - task tags for different product aspects, not skills - make internal team commitments - testing is built into the process as progression is made - regular code reviews - regularly scheduled demos - sharing work with greater team and community - celebrate as a team/community - creates accountability - regular retrospectives on work done - introspection, improving the process continually - make a commitment to building in public - helping us align ideologically - helps build trust with the community - gives insight to investors/supporters - creates opportunities - engage community and prevent silos - demo specifically for stakeholders - product dev organizational methods - kanban on github - different boards for different processes - more free flowing w/ a structure to guide - better for a DAO - task for creating tasks - can explore linear - self/team assessments - buddy system (1 on 1s) for feedback/accountability - daily standups to check-in - this is what I'm working on - this is what's blocking me - self assessment - creates discomfort - explore some balance/combination of self/team - coordinape works well for p2p contribution value assessment - meshes with compensation models - does it recognize behind the scenes work? - good for surfacing questions around assessment - how do we measure the work going on behind the scenes? - self organizing / bottom up design - making opportunities public and self select tasks - clear compensation - finding people with the right mentality (this is a DAO not a job) - Finding the right balance between openess and accountability - give space and support for people to create on their own - squads can pick it up if aligned - hierarchical design pros/cons - pros - ownership, ability to delegate - speed to get things done - people can focus easier - told what to do - cons - does it align with the motivations behind joining DAOs - opens up opportunity for middle managers, ultimately creating a downfall of the org - 'Leaders' start dictating, get power hungry - building one person's interpretation of the product - individual vision instead of community's vision - communication channels - discord - threads for focusing conversation - voice channels for syncs outside of text based comms - github - comments within code reviews - wiki - communicating general info - hackmd - documenting voice convos - curation of information - miro - sticky notes / excersizing - DAOhaus platform - via proposals / signals - discourse - forum discussion before moving to chain - what resources already exist that outline any of the above bullet points? (past experiments included) - form cross-function teams (sub-daos) - product squad - team with different roles - team can move from project to project - can work with other DAOs - guilds where everyone has the same role ## Resources - [DH github kanban](https://github.com/orgs/HausDAO/projects/3/views/3) - [v3 wiki](https://github.com/HausDAO/daohaus-monorepo/wiki)