The Buddy System is a great tactic for getting new contributors up-to-speed, identifying synergies, helping each other grow, bridging silos in the DAO, and identifying gaps in our individual and collective understanding. On the cultural side, the Buddy System cultivates conviviality and offers checks and balances to ensure ongoing cultural alignment to make sure we are building the right things in the right ways in the right order for the right reasons.
How might we gather ideas on how we can bake-in the prioritization of problems into our culture before jumping to solutions?
How might we move towards defining a clear peer review process while restraining to impose restrictive structure?
How might we make these learnings available for the wider DAO community to benefit from collectively?
How might resolutions arise organically as local emergence without requiring the full attention/distraction of the greater DAO?
How do we ensure culture fit and ideological alignment with new contributors?
How might we clarify the difference between onboarding to the DAOhaus community and contributing to Warcamp?
How might we help individuals understand how they can maximize impact, best apply their skillset, and play to their strengths?
Travii’s’s have had (and continue to enjoy) great success with our pairing. We simply want to extend the details of this experience so others might choose to adopt the practice or formalize these ideas into policy. Here is our minimally viable buddy system that we continue to employ to this day:
Daily calls, 4x per week. Instills repetition and personal reliability.
Allow each other to vent in a manner that doesn’t fit in other meeting spaces.
Ask each other for feedback and have reflexive conversations about DAO priorities.
Extend a direct line to ask questions about how the DAO and sub-DAOs work.
Collaborate in identifying gaps, and then working together to document them for the benefit of the whole DAO.
Share divergent experiences and cross-disciplinary training.
Challenge each other to get explicit about where we are personally trying to get to, in relation to where the organization is trying to go.
I really appreciate the buddy system and attribute my own degree of comfort and familiarity with DH to my connection with Adrienne, who has helped me understand things since before Day 1. I wouldn’t have felt comfortable trying to break into the space without that connection for several reasons, which I will try to briefly touch on. I also act as a buddy for Binary, and that has given me some perspective for challenges and opportunities on the flipside of the system.
I think having a buddy coming into DH gave me insight into multiple things that are very, very basic. These include:
cultural understandings (is this a scam? are people nice? What is the tone? Can I learn on the job? Is there room for mistakes? What is expected?)
how to find projects (design is a small project-oriented team where pieces can be shaved off for a new contributor, so Adrienne and Ven both helped me decide what to work on)
what meetings to attend and what is expected of me (this is much easier now because of the Events channel)
which of the myriad channels were essential to pay attention to for someone doing design, and which I could ignore until I had my footing
how the DH platform works and how all the functionality is connected
administrative, self-HR tasks like setting up an LLC & business bank account, and when to do these things
beginner’s crypto stuff like setting up metamask, bookmarking xdai bridge and honeyswap, and getting a coinbase account. How to get paid is actually a pretty complex topic
setting up coordinape for me
defining terms for things that sounded like dnd words and in reality referenced mind-bendingly complex functions (still, always, working on this one)
what forms to fill out and at what time
…This is not comprehensive. I hope it illustrates the breadth of responsibility someone in the buddy role may end up taking on in addition to their regular role, as well as some areas that perhaps can be better documented to create a collective resource that lessens the need for individual buddies to carry that burden.
I decided to take on the buddy role with Binary because we’re friends and she’s comfortable coming to me with her questions, and I think that comfort is the most essential aspect of the BS. If someone isn’t comfortable with their buddy, they lose their lifeline and may end up bouncing. My biggest challenge has been that I am not in the same work circle, since I hang out in Magesmiths and she intends to be more in the Rangers. This has meant that, in order to make sure she understands things in her circle, I have chosen to attend meetings for hers. That’s not ultimately a huge ask for me, and perhaps fits into the idea of cross-disciplinary training, but it does increase the amount of time I spend in meetings (and ones not directly related to my own work). There is also the fact that it is harder for me to help with actual tasks or task-vetting for a newbie because I do very different work. tl;dr from my own experiences – I think it’s probably good, when possible, for buddies to come from within a new contrib’s intended circle.
Thanks for putting this together @traviswyche - I for one am a big fan of having a flexible BS in place so we can ensure everyone who is a part of Warcamp has at least one person they can ask questions to and partially rely on.
I think a BS is crucial for supporting the interrelationships between members and cultural alignment for Warcamp contributors at large.
One thing that I want to be careful of though is diverting too much of our attention, time, and energy toward these conversations in the BS.
Ideally, the BS should provide a foundation for each pair of contributors, such that each buddy can have his or her needs met by their buddy.
While I recognize this reinforcement is important, I think the conversation of what, how, and why we are building what we are building should not be reduced down to conversations that we have in our BS, as that can possibly distract or detract from the actual building itself.
This relates to how individual contributors in WC reconcile their individual tasks and projects with the priorities of WC. Without clarity around what we as individuals want to prioritize or think is important to build, suddenly the amount of work turns into a mountain of things that we “could” be doing, instead of actually doing the thing. In my view, sometimes getting to the solution means failing fast in the “right” direction until a solution is identified and able to be implemented as intended.
This is a great one to hone in on, as we do not want to constrict the BS conversations, impose too rigid a structure making the BS no longer attractive, or push too much process on contributors who are doing something that is voluntary in the first place.
I think what we can do is encourage a process based off what we have seen be successful.
@helle made some really salient points directly related to how we are supporting new contributors as they find their way around compensation, DAO processes, communication/discord navigation, meeting structure & setting, LLC setup, Role identification, etc. Making some of these things into guides similar to what @kagami shipped could be a useful way to alleviate the amount of time spent on some of these things.
@UI369 & I have been buddies since late March and though it took a little bit to get used to, I have found that it is extremely helpful and helps me grease my bearings before the start of my day.
I have also supported UI in async conversations related to:
Each day in our standup, we produce a list of items that we did, we will do, and blockers:
Example of a Monday in April
April 11th, Monday
What I did?
Supported veDAO announcement creation
Sent out veDAO announcement post
Contacted allies who could support veDAO with veBAL
Finished herding delegates for UberHaus v1.5
What will I do today
HAUSparty Blog if it is ready
Queue up some HP tweets
Flesh out documentation updates
Ship processes to handbook if ready
Review CCO Retro Article
Uberhaus V1.5 policy improvement framework
Work on modifying DAOhaus onboarding to incorporate Collab.Land Points & ship changes to initial onboarding structure
With this minimum structure, we have been able to achieve staying on track in our daily standups while also providing space for emergent discussion / questions to surface.
If this structure were adopted DAO wide, it might create a feedback loop into WC where this information could be utilized to support a peer review process by the DAO itself. (Did Bau execute on everything he said he would, or was he talking out of his ass?)
This is a great start, but I know we could take this much further - @rangers could put together a series of articles highlighting our BS, how & why it works. Maybe we can dogfood the BS further with newer contributors, pairing veterans in DAOhaus with newer folks as they become interested in contributing to a specific project. This might be a good opportunity to plug the connector role as well, which is closer to a buddy at an arms length ;).
This is the beauty of working in a DAO, and I think there exists an organic BS in Warcamp even without the establishment of our formal buddies
I think we do this by being us and helping contributors into the pipeline to see if they are a cultural fit, and if they are not then that is okay too. Filtering mechanisms are good too, which DAOhaus I think has done a fairly good job with simply by nature of its name, structure, design, etc. We can ensure alignment by having integrity, teaching what we learn, sharing our experiences and building trust. If new contributors aren’t attuned to our efforts, then it is okay that they want to contribute their energy elsewhere.
This is another great question. We can do this by allowing individuals to self-select, helping them to see where their skills, passions, or interests would be best served within DAOhaus or WC. The difference for us as Warcampers is that anyone can join the DAOhaus community but not everyone can join WC, so being cognizant of our relationship to DAOhaus/WC is really important. This relates to a concept introduced by tracheoptryx Network Topography which I wanted to mention earlier in relation to prioritization but is also relevant here. Network Topography is being aware of the environment that you are operating within. Where do you fit into the bigger picture is sometimes a great question to be asking.
Teach what we learn, support contributors and community members with resources, introduce them to the right conversations based on their skills, show them some tasks or a project they can get involved in, have them talk with contributors!
Would love to be engaged in this, but I guess I would have to be one of your buddies.
This is a really awesome one and I feel it is incredibly important that we have this in our minds as we are navigating to our North Star.
This is a really badass endeavor you guys have undertaken - I love the structure and the output that you & @earth2travis have generated, I think it is brilliant.
Hopefully we can put our heads together to collectively come up with ways for formalizing and improving the BS (at least so people know they always have a buddy).
It’s challenging to describe how beneficial it’s been for me to have a buddy.
When I became a member of Raid Guild, Plor offered to meet with me every week. He helped me as I first learned how to offload crypto. He was also there to hear my excitement at using that first crypto to USD to throw my son a 13th birthday party. Thank you Plor!
Joining Warcamp is sweetness. It was an odyssey to get in, but that made the entrance even more valuable, like I really earned it. It’s still kind of an odyssey, understanding the nuances of a decentralized organization that feels fairly large for this structure.
Last week I started meeting with TravisWyche, four times a week. It’s pretty wild how much I’m getting out of these buddy chats. It’s also related to subtleties that are going to be difficult to describe, but I’ll try.
We’ve looked at projects that I’m contributing to and found ways that I’ve limited my involvement. It could be because I hadn’t communicated with someone else working on the project and didn’t have information on what tasks were already being completed. It could also be because I was being mousey, surprising I know, because I wanted to respect someone else’s seniority or even someone else’s preferences. It could also be because I was assuming that I needed to get a certain task completed by a certain date, even though that demand was never communicated with me.
These reasons why not stem from old patterns. TW is helping me create new neural pathways that increase my self agency. For someone so loud, it might be hard to see that I have weird submissive patterns, but I have plenty of past experiences that have reinforced those behaviors.
Having more self agency isn’t making me into an egomaniac, at least I hope not. What it’s doing is improving my vision to see where taking initiative is useful and the encouragement to go ahead and contribute as best I can.
TW and I were talking about it today. I said it’s increased responsibility and he improved upon that by separating the word to emphasize what I was trying to convey: response-ability.
I will do process, but can only get motivated if someone I trust asks me personally to help them out. But usually, with process, I’m so lost. Also, with process alone, how would my self-imposed limitations have been noticed? I would have opened a form, my type A would have kicked in and I would have made sure I got all the answers right, which means I would have failed the exercise. (That’s funny.)
I’m greatly in favor of the Buddy System all across the board. It’s difficult for me to unpack how much I’ve benefit from having consistent conversations with folks. I owe a massive debt of gratitude to Scott, among others, for taking time to have these conversations.
There’s so much value that this provides to folks who are first learning to navigate the ecosystem (broadly) and the DAOhaus contributor landscape. I completely agree about how these types of relationships create a sense of accountability that is rooted in personal connection and not pure mechanistic design (not that there is anything wrong with this, but I think that these two systems are highly complementary).
Buddy Systems (informal or formal) often make the difference of someone seeing a pathway for themselves to making transitions into becoming ongoing contributors or not. If this system is able to help even a few folks progress forward on their journey then it is immensely valuable already. However, I think that the potential for the accountability that comes from personal connection is highly meaningful and a great way for natural feedback patterns to emerge to help (ideally) both parties grow in skill.
I believe the Buddy System to be a critical element in our iterations around evaluation and am excited to see this move forward.
“How might we gather ideas on how we can bake-in the prioritization of problems into our culture before jumping to solutions?”
This is one of your first lines. Could you say what you mean by “bake-in prioritization of problems” in the context of the buddy system?
When I read that I imagine some kind of prioritized problem list and a nice toasty process all around it - baked in. And the wording also had me consider if you meant adding problems to our culture, but I imagine not. So would like to hear more what you mean there.
I can see the benefit of having one or more problem statements attached to any project plan. I like knowing when an initiative has solved a problem so that we don’t keep building it unnecessarily. That usually ends up creating new problems.
And what does it have to do with the buddy system? Do you suggest I discuss this one on one with another Warcamper or maybe these are the kind of ouputs you’re experiencing in your 1 on 1s? There’s a lot more I could say about on this topic, good convo.
Today we had a sync on the Buddy System with the Paladins to gather feedback. Here are our notes:
Buddy System Paladins Meeting Notes
This all started with the intention to onboard new contributors as fast and efficient as possible. There’s value to contribute to onboarding, but we want to discuss the larger impact.
This is a difficult time, a frustrating space, and these conversations have become crucial to our mental health, to add value to the DAO, to help each other continue to identify how we can add that value beyond measurement.
BS creates a safe space for contributors to share their raw thoughts. Especially important for more gentle spirits/softer voices, for woman seeking an inlet to the patriarchal structure, and generally to empower any/all to find their place in the org.
How do we systematize this structure? Some contributors feel that they want more structure. Where does this come from? Do they decide amongst themselves or is it agreed upon and imposed from without?
Travii’s’s began with an agile standup structure: what have you accomplished, what are you working on, where are you going. This allows us to identify blockages, breakdowns, pain points, etc, to activate the work as much possible.
Ventilation (blowing off steam) is an important part of the process and should not be overrated!
Every BS pairing might devise their own structure and adapt it to their needs (which will vary wildly across individual personalities, needs of the circles/initiatives, etc)
How to solicit feedback from our buddies so that the learnings can be applied to the wider DAO?
Propose we all begin with an agile standup?
How to encourage improvisation/adaptation?
How to keep the structure loose/malleable enough to make everyone comfortable while maintaining the visibility of the tasks, value, etc?
Key value add is exchanging experiences across the space, the DAO, and from our idiosyncratic skill sets.
Books, blogs, expanded research from unexpected sources
Professional experiences, social encounters, wildly divergent cultural ideas
Specific best practices and SOP tailored to the DAO space: DAO-specific experience
Not every contributor is a coach, has the skillset to coach, or wants to coach.
Should the BS remain voluntary?
How might we devise a system to display buddies that are available (volunteers) for contributors that need buddies to choose from?
How might we create a decentralized system for building trust while avoiding the entire DAO dedicating resources to keeping tabs on everyone and everything?
Is there a potential cultural attack vector?
Is there a weakness of the system being gamed?
How might we anticipate potential collusion or malicious behavior?
Do we want to impose limits on how many buddies any contributor should have? For reasons?
Mentorship is a huge value add. How do we amplify it?
How might we encourage each other to “pay it forward?” So the experiences and accountability can permeate through the larger DAO?
Coordinape is biased towards contributors providing highly visible work, biased against the less visible contributions. The BS might bring visibility to these more discrete initiatives and support their appropriate compensation with less need (and resulting friction, anxiety, pressure) for the individual to defend that work.
Is there a limit to this BS?
Is there an intended end point?
Does the pilot end or does the program last forever?
If there is no end point and each contributor continue to accumulate buddies, when is this perceived to be a breakdown or disadvantageous?
What is the point of diminishing returns? How do we identify the maximum value threshold and anticipate constraints after it is reached/surpassed?
Does this require a policy or a mechanism to determine? How is this weighed against self-sovereign buddy pairings and individuals?
Do buddies need to be selected from with the primary circle? How do we feel about cross-circle buddy pollination?
Does there need to be policy on this?
Reference: pair programming - especially for technical contributors
We might consider as many different styles of buddy pairings as their are unique personalities and skillsets within the DAO, ie: infinite possibilities
Higher priority is to keep the structure fluid and avoid prescription to maintain the freedom of the individual.
How long is the BS term? How might we encourage the freedom to define longer- and shorter-term pairings?
Sketch out templates for different buddy configurations.
How might we create a repository of fork-able and generative templates as invitation for other contributors to adapt to their own needs?