Clarifying full decision process from tension through review

Driver about clarifying full tension-through-review process

Our agreed decision process currently starts at making proposals. Although sometimes jumping right to proposals is okay, we ran into tensions and confusion doing that even just for updating the process document itself. We can decide how flexible to be, but it will help us get on the same page and make the best decisions if we specify how we start with tensions and driver statements before (or at least alongside) making proposals, as described in S3’s navigate-via-tension.

Notes

This tension I’m bringing up is related to https://gitlab.com/snowdrift/governance/-/issues/69 which captures a mess where many tensions arose but were lumped together too much without consent on the drivers individually.

Right now, I’m asking @team and anyone else ( @photm notably has been involved in this topic) for feedback and then consent on the driver above. After we are clear on the driver, we’ll do proposal forming (which I expect to look like just spelling out how we intend specifically do our version of the S3 process asynchronously; i.e. adding the missing steps from S3 to the decision process we have currently).

This is the first of many tensions to address in tweaking our process to make it thorough and yet flexible and practical.

1 Like

Hmm, this sounds as if the current decision process would encourage jumping to a new proposal when reviewing an agreement. However, the process says to simply make a consent decision on the review date, on whether to keep the agreement or to update it – you then update the document bit by bit for each objection you encounter (or rewrite it, but only based on a clear objection that is to be fixed by the rewrite). I think the tensions and confusion we ran into were because we didn’t follow that process, so we would like it to be more clear. Thinking this way leads to clarifying the review process mainly – not adding driver statements.

However, your framing makes a lot of sense to me because it is somehow a generalization of the above (i.e. of motivating rewrites via objections), simply because both objections and drivers are reasons for doing something. (Objection: A reason why something might lead to unintended consequences, i.e. a reason for changing that something. Driver: A reason for doing something in the first place. If you take changing an agreement to be something that can be motivated by a driver, then an objection is not much different from a driver for doing just that.) The “Driver about clarifying full tension-through-review process” would then be about always starting with the reason.

To summarize: I think the driver statement should also mention objections as well, e.g. append “; and start with objections when rewriting proposals.”

1 Like

Updated driver

Our agreed decision process currently starts at making proposals. That led to tensions where we didn’t have agreement about the drivers or objections that a proposal was addressing. If, as described in S3’s navigate-via-tension, we specify starting with tensions and driver statements (or objections) before (or at least alongside) making proposals, we will do more efficient and clear decision-making.

Notes

I imagine that if we have consensus about this driver, the proposals could include simply starting fresh with a simpler process where we decided on each element one-at-a-time. We may want to capture clarity about synch vs asynch decisions as in Why asynchronous consent decisions in the first place?

My story is that we keep causing extra drama and challenge by engaging on proposals before having clarity on drivers/objections. I imagine if we really build the habit of always getting drivers clear first, everything will go better.

I noted consensus on this driver as the first step forward. This whole topic is captured in one starting point at GitLab: https://gitlab.com/snowdrift/governance/-/issues/69

4 Likes

On reflection, I think I am unclear at an earlier level: what is the scope/purpose of this process?

For the old (err, current) process, I was under the impression that it was more-or-less exclusively for governance decisions. I believe that’s because, while we’ve moved away from Holacracy, we haven’t scrapped roles.[1] So, it seemed like operational decisions would still be made unilaterally by whoever owns a relevant domain, and the new consent process would replace Holacracy’s governance process.

Meta: I'm going to merge a different thread and then continue below.

I’m doing this because I feel it’s currently creating clutter being a thread of its own; I want to reference it here; and I think with the questions I did/will ask it’ll fit solidly within this thread’s topic.


  1. Or at least, we haven't overhauled roles yet; we never did get them to the point where they fully match our actual operation. ↩︎

@smichel17’s note: I merged this from a different thread, so it’s meant generally, not in this specific context.

This describes a nice clear continuum from individual-action to complete unanimous alignment. The suggestion is to consider on a per-decision basis whether the value of added buy-in (and [my addition] decision quality) is worth a longer and more costly process.

2 Likes

This post clarified for me that Holacracy is, at some basic level, a framework for deciding how decisions are made. Therefore, we need more than just a consent decision process to replace it. We also need to decide when to use it.

For example, I’ve talked over the css changes I’ve been making recently with @iko and @mray, but not the whole team, which would be excessive. I could frame this whole process like:

  • I had a tension about how the prototype css was organized, and sought consent on the tension from relevant parties.
  • I proposed a solution and sought varying degrees of buy-in to its different parts.

The key point is that at each step, I unilaterally decided what level of buy-in to seek (and, in the article’s words, which decision right to use). That worked well in this case, but it runs the risk of me not including someone who would like to be. At the same time, I think it would be excessive to bring every tension to the entire team, even if it’s only to ask how much buy-in they want.

Last time, we drafted a consent decision process. But, not all decisions are consent decisions. If the next version is also a consent decision process, then it’s only part of our full decision process. Regardless of formality, that process needs to answer this question:


For tensions and proposals each, how do I decide how much buy in I need and from whom?


I do not consent to the current driver because I think it fails to capture this fully, which I think is necessary to avoid another situation where we spend lots of time ironing out the details of a policy without a clear idea of where it starts and ends.

2 Likes

I appreciate everything you’re saying here.

I want to emphasize the acceptability of making mistakes. We can step on toes accidentally and leave someone out who should be included. It might be fuzzy one-off situation that merely gets fixed later when some tension arises because of it. Or it might lead to adding clarity about domains or process. Maybe other cases we seek excessive buy-in that takes too much time from people who didn’t need to be involved. As long as we have feedback mechanisms so that we learn and adapt, then it’s fine enough.

We really need to finish overhauling/updating our roles and domains (that’s a big epic bunch of work that I think is reasonably high priority). But besides that and both before and after, we should expect some messiness and only formalize ways to avoid it if we are really sure the benefits of such formality is worth it.

We need a culture where people bring up tensions instead of suppressing them. We need not treat every tension as necessarily needing a formal proposal and resolution. As the article describes, some issues don’t need a decision and can just be things we discuss and then leave alone.

I support the pattern you described where you did work and used your own best judgment about how much buy in you needed from whom. I think we’ll refine our judgments on these things the more practice we get. I don’t want to prematurely optimize any structure that would turn this over to rules and remove the human judgment.

1 Like