Release Rhythms Explainer


I noticed that we’ve been having a cross-community struggle lately around the self-harm behaviors we learned from capitalism combining with the undefined nature of our new economic/social paradigm created by SC. Basically, we’re traumatized birds who had the top of our cages removed and I see a collective reeling at the overwhelmingly undefined options in our new work environment. Maybe that’s a bit dramatic, but you get my point and you’ve probably heard me talk about this a lot lately in calls and 1:1s. It’s hard to figure out the most conducive and healthy ways to pursue working together in coordinated manner.

So I’ve come up with one potential way to create a “base rhythm” which participants can rely on as they explore their own relationship to healthier work environments and getting work done with others. I’m calling them “Release Rhythms” which are intended to create a sense of togetherness, clarity of direction/expectation, and explicitly values our personal need for rest.

These Release Rhythms will be tested on the Cultivation Trunk first and refined before they’re potentially brought to the rest of SourceCred’s Trunks.


Props to my other topic “How to Start a New Project in SourceCred” for the Problem, Mission, Success, Strategy, Tactics formula in the next section. If you want to know more about what those mean, check out that topic for in-depth descriptions.

Release Rhythms:

1. The Problem

  • Hold over behaviors/trauma from capitalism make us feel as though we still aren’t allowed to have needs, or let those needs to be more important than squeezing productivity/concrete results out of ourselves.
    • Example: We may not notice that we need time off because that was an unsafe need to have before coming to SC.
  • Lack of structure in a very unique/undefined environment can make it hard to be coordinated or balanced in our work together.
    • Example: We don’t have “vacation time” or “PTO” but there’s also no explicit invitation/protocol to take time off when you need it.
  • Finding a life/work balance takes time and energy to develop after working in (often traumatic) capitalistic environments.
    • Example: We may realize we need time off and that we’re allowed to take it, but not how to choose for ourselves when to take time off and how to balance our needs as individuals with our work goals in a way that feels healthy and satisfying.
  • It can be hard for our participants, teams, branches, etc to feel like they’re working in concert with each other or have a sense of over-arching direction for their work. We’re losing the chance to do better quality work that doesn’t waste time via lack of communication/expectation.

2. The Mission

  • Create a Trunk-wide structure/rhythm around doing work together. It should provide clear expectations which helps us get work done as a team, while also having explicit space to be a human and need rest. Ideally this structure is not mandatory and has space for participants to find different ways of approaching the Trunk-wide rhythm that work well for them as individuals.

3. The Success

  • Our Branch is able to work together in a coordinated and aligned way that regularly creates quality content (concrete or abstract). While also serving our needs as humans to have a balance of; freedom and clear expectation, personal focus and work focus, rest and accomplishment.

4. The Strategy

  • To create a Trunk-wide system of release cycles that take into account and balance both our goals around content creation and needs of participants as people. I’m calling these “Release Rhythms” or “RRs”.
  • RRs will act as a base rhythm with certain expectations which everyone can anchor on and work with during their own exploration of how they best get things done. Building on top of the base rhythm, each contributor can explore with themselves and their teams how they can best engage with the group’s goals.
    • Example: if you don’t want to take the same week off as everyone else because you really like the peace of getting things done alone, go for it.

5. The Tactics

  • The proposed parts that make up a single Release Rhythm:

    1. Creation Phase (1:1s as needed)
      • Trunk-wide meeting: discuss theme for this RR and the work each Branch is focused on.
      • Planning: Branches & Project Teams plan and prepare for creating their content.
      • Creation of Content: Branches/PTs work on a basic and functional version of their content.
      • Trunk-wide meeting: See what content evolved and whether it’s aligned/useful/well crafted enough to move forward with.
    2. Break 1
    3. Review Phase (1:1s as needed)
      • Implement/Beta Release: release new content to a small audience or the whole community and provide support as they learn your new content. Test and take note of what works and what doesn’t.
      • Review and Polish: make any necessary changes and polish up content based on feedback from implementing. (may or may not be switched or simultaneous with Implement).
      • Trunk-wide meeting: discuss what content has made the mark and is ready for use in our community.
      • Community-wide Release: release final version of polished content to the community at large.
    4. Retrospect Phase
      • Trunk-wide meeting: reflect on how the RR went as a whole, what we learned, what we’d change for next time, etc.
    5. Break 2
  • Timeline/duration of a RR and it’s phases have not yet been decided on.

  • It’s our intention for the first trial run of RRs to have soft deadlines with a focus on completing and understanding each phase before moving on to the next. This will also give us some context on how long the phases and RRs as a whole generally take.

  • It’s expected that this is just an untested theory/suggestion and the phases of RRs may end up changing to better meet our needs as time goes on and we better understand our needs. Or that we may find a better and completely different way of meeting our needs around life/work balance and explicit but not mandatory structure. Meeting the Success condition is our main priority, not making this proposed structure happen.


So this sounds like a SourceCred version of an Agile sprint.

Is it fair to say that Release Rhythms is an attempt to induce team cohesion by breaking projects up into portions punctuated by mini-vacations? Is that what “break 1” and “break 2” refer to?


I really like your wording “see what content evolved.” IMO, this intentional phrasing is a large part of creating a work culture around quality not quantity, and really supports the values of your Release Rhythms.

One thing I’d love to see added at some point is a clear statement of what we at SourceCred find valuable. Perhaps this could be a doc that supports your RR’s, @LB . Personally, I would find it super helpful to see it written and reinforced that:

a) Soft skills are useful, effective to the team’s missions, and take a lot of time and energy. It is not expected that you do a certain amount of work not related to soft skills in order to prove your “worth” to the team.

b) Starting something, in and of itself, is a task. Even if you don’t think you’re the #1 best person for the job, getting something off the ground, setting up that first meeting, and getting together a team is a large part of what gets a project moving.

c) Action opportunities for how to address feelings of insecurity or worry around how much you’re working, taking off time, not feeling like you understand the project enough to contribute “effectively,” and feelings of pressure that come from growing up in a capitalistic society.

d) Suggestions/examples of how to navigate and find structure within an unstructured system

e) Find a way to understand long-term expectations from contributors, esp those in leadership positions (your post definitely goes over this, but I just want to be clear about the need for it).


Something that’s been raised in synchronous conversations is the question of how is Cred earning and Grain payouts impacted by taking time off? (As is suggested with Release Rhythms).

It seems reasonable to say that if you have a lot of Cred/Grain, that taking time off won’t significantly impact your monetary flow and your ability to pay rent, etc. But is that true for other “participant profiles” like the a new participant who doesn’t have a lot of Cred/Grain yet? Or the participant who has been inactive for a while?

A real answer to this question requires a deeper understanding of the technology than I have but it’s an important to consider regardless.

1 Like

That’s what I mentioned to LB the other day as well. I think it may be worthwhile for us to adopt the Agile framework + language, and augment it with @LB’s great additions to it (and we can use our own language for those), to make it our own but also keep it accessible. Doing this would dramatically help onboard new people who have already worked in any environment that uses Agile or something based on it, which is a huge portion of SC’s initial target audience. Less so the audience for the Cultivation branches, but to my knowledge there isn’t a widely-used framework for those kinds of operations and work cycles anyway, so they would be learning something new either way.

I think when new participants start out and take time off very shortly after, they shouldn’t expect to make much Grain yet. If you’re new and work real hard for, say, 3 months and earn enough Cred to pay rent with your Grain payouts, and then take time off, it’s still reasonable to see your Grain income go down as you’re away while other people continue contributing, since you haven’t accumulated much long-term Cred yet. If you’re a long-time contributor but go inactive for a while, you’d probably know that your Grain distributions will diminish and are not relying on them.

So I think this is something that our existing Cred/Grain distribution system accommodates sufficiently well, but the messaging around it could definitely improve.

That said, this touches upon the discussion from our SC Weekly Update today (11/5), on the subject of stable salary-like payouts versus the volatility of a purely SC-driven system that, especially when you combine that with the possible scenario of you taking time off for a few weeks, shortly after a big influx of new participants in the project, and your Grain income drops somewhat more precipitously because not only are you getting 0 payouts from the weekly policy, but your balanced-policy payouts may suddenly drop more as the recent new participants are starting to have an impact on the balanced payouts.

It makes me think about @decentralion’s SC-powered sponsorships thoughts, and if we could combine that with some sort of “4 weeks paid vacation time / year” model that ought to be the worldwide standard.


For what it’s worth, I have long found the “sprint” terminology distasteful. The distinguishing property of sprinting, in the normal sense of the word, is that it’s unsustainable: you run at top speed for a short time, and then you’re exhausted. Yet in “agile” workflows, it’s sprint after sprint after sprint. No rest, no variety. You know what happens if you sprint continuously for a year? You die.

Both the imagery and the practice seem counter to what this post is trying to address, so I would prefer to refrain from introducing them to our community.



This is why I’m introducing extensive sauna and ice baths into my workflow + at least one off day a week.

It seems like understanding Cred flow, and thus Grain payouts, is something not many team members have fully grasped yet (especially non-devs, who have less access to understanding and working with the algorithm). I have also found that this creates barriers in efficiently allocating tasks (at least for me), due to not fully understanding how to most fairly allocate tasks that earn Cred vs not. This may all change with the Creditor, but I’m not fully in the loop with how exactly earning Cred will be changed with the Creditor. Perhaps this is a topic the community would benefit from having a series of lessons on, led by team members who fully understand the algorithm, the future Creditor, and how Cred flows, intimately.


For what it’s worth, I have long found the “sprint” terminology distasteful. The distinguishing property of sprinting, in the normal sense of the word, is that it’s unsustainable: you run at top speed for a short time, and then you’re exhausted. Yet in “agile” workflows, it’s sprint after sprint after sprint. No rest, no variety. You know what happens if you sprint continuously for a year? You die.

Well put, I’d note that Sprints are a product of Googles culture which is centralised, in person, top down and consensus oriented (rather than consent based organisation). What happens in such scenarios is that extroverted thinkers dominate the space by thinking out loud and the introverted thinkers suffer greatly and leave, which is a shame because complex thinking is by definition non-linear, and thus can’t be articulated in a linear fashion… IMHO sprints are violent, don’t do them.


I agree that “sprint” as a term has this connotation of endless running, but I feel that making breaks an explicit part of the sprint/creation cycle dispels that notion, and in fact highlights exactly your (and my) dislike of it—and augments it with the solution.

That’s not to argue that we should use the term sprint; my encouragement to adopt some elements of Agile isn’t to match it 1:1, but as closely as possible where we’re doing the exact same thing.

That is not at all my experience with sprints; when we did them at my last company, it specifically helped the less-extroverted have their voices heard, their ideas taken at equally important face value, and their contributions given the merit they deserved. I don’t know how “linear” factors into it for you, but other than following the structure (much like the structure of release rhythms above), there wasn’t anything linear about it.

I think this all comes down to how you implement it, not what “it” is.

I don’t know how “linear” factors into it for you, but other than following the structure (much like the structure of release rhythms above), there wasn’t anything linear about it.

I was suggesting that thinking out loud is linear, not sprints. I’m with you on “How” vs “What” just like the rest of agile (vs fr-agile/psudo-agile) but I’d encourage SourceCred to be creative and build their own culture to be something better. Iterate!

Words Of Wisdom: Do not go where the path may lead. Go where there is no path, and leave a trail. — Ralph Waldo Emerson

1 Like

@JoshAFairhead Well fine, if you’re gonna throw my literal life quote back at me I’m not gonna argue with you :wink:

Thinking out loud is not how we would do our sprints; I’ve always done sprints with sticky notes where everyone just writes their ideas down and puts them on the wall. That’s a little harder to do online, but @META_DREAMER posted this link to doing remote sprints so it’s not impossible: