Relationship Design: choose your own adventure

[Note: I am less pleased with this writeup than with others, and I struggled more. Maybe it is the topic, maybe it is me.]

On Monday, the 1st of February, we held a Cookbook about Relationship Design. I already posted some of my considerations on the whole idea of process design, here are my notes from the event.

First of all, what is a cookbook?

At the moment, I call it “an experiment in participatory wisdom“, and the current incarnation of something I started 8 years ago to collect practical advice and experiences about how to make relationships (and life in general) work. Or sharing how hard it is, and how often we fail, then try again.
It is semi-structured, but open in content. Consider it a bit like an unconference in a 90 minutes box. The whole point is to share “how do we do this thing called life” the way we would share recipes: “I tried this, here is what worked, what didn’t”, and other people can decide if it would fit them.
Not big philosophical questions, no preaching, no telling other people they are wrong or what they do is wrong (no matter how hard you want to say it). At most “I tried that, and it didn’t work, and I have never seen it working: could you help me understand how you do it?”.

This time, the topic emerged from the previous cookbook, in addition to conversation with friends and fellow explorers of “how to make this thing called relationship work”. People trying to use the processes from project management in relationships, people trying to bring relationship ideas to project management, and some serious (OK, possibly not so serious) geeking out about “what would it mean to have a PoC in a relationship? What about a MVP? Who are the stakeholders?”.
In addition to this, many, many conversations and soul searching on what is the point of having a process? A process won’t save you or your relationship! You cannot enforce it on someone else. What are you trying to achieve? Prove?

Please note: if you want to join next events, please follow the Cookbook on Facebook[I]join the group, and/or sign up for the newsletter (that at the moment is non-existent, sorry)

This was the introduction on the event page:

How to we apply tools from process and project management, agile, and design thinking, to relationships?
What would a PoC be? A MVP?
Who are the stakeholders? Do we do sprints? Retrospectives? Standups?
Do we do iterations?
Do we track success? What IS success in a relationship?
Does it make any sense?
Does it work, or is it just a game we play to give us a false sense of security and control?
We will of course answer all of this, and more, and solve all problems of humanity.
(I may be overselling this)

Again, I think I oversold it a bit, but it was a wonderful ride, we got some clarity, we clarified some confusions, had some fun with the lingo, and shared some interesting practical tools. It’s a start.

Speaking of which, a note about terminology:
part of the point of this event was to make fun of the lingo. The corporate world in general, and the start-up tech world in particular, is chock full of unnecessary terms, acronyms, techniques, and a constant cycle of hype about them.
Shout out to using the BRB and UAG…(Big Red Button, and Unnecessary Acronym Galore, of course)
Still: some concepts can be useful, at least to play with. And some techniques are useful. Up to a point. Until they stop being useful.

About this

I am still experimenting with having a write up after each cookbook. This means the content is not really what I think about the topic: it is my personal, biased report about what we ended up discussing, covering what I understood and what clicked for me.
Let me know if this is helpful, and if I should continue.

If you have never been to a Cookbook: we propose the topics during the event, then, after some warming up, we present them, and we vote to decide together which ones to actually cover. I would generally want to discuss them all, but we tend to have time for three to four topics.

The topics ended up being:

As a warm up, we started with
As an intro round: What practices, rituals, and processes from the business life we brought to our relationships?
and
Patterns, anti-patterns, successes, and failure modes of using processes.
The most voted proposed topics where:
How do you introduce routine check-ins or rituals if they do not come naturally? Or do you then let it go? 
What would a MVR be (minimum viable relationship)?
Chaos management
Do you re-use material from a relation in another (like same kind of date, play, messages…)? Which material? How did it work?

Some general notes and a disclaimer

The whole idea of “designing a process for a relationship” seems to trigger lots of people, even some friends I know are using lots of processes in their relationships.
And for some reason, everyone that told me “I will come to be against processes”, ended up not coming. I promise I did encouraged them to come.

I realized after the fact that the term does not fit fully: there is a mismatch between what I mean when I say it, and what I hear when someone else uses it.

What I meant, and what we ended up actually talking about, is establishing a process to find out together what sort of relationship we want, we keep on wanting, we do not want anymore. It is not about sitting down and planning a relationship in details (good luck with that), and it is not even about forcing other people to join our processes. It is a shared process (again) of discovery.
Some techniques help, and can be tried.

Again: I am not sure I have been very good in opening the space to the people that were either against processes, or skeptical, or doubtful. A few people expressed their doubts in the beginning, but did not really talk again.

So… what would be a good process to allow people to express contrarian opinions?
What is the process to say “I do not like this process”? [I]I guess I am doing it again

I have a few ideas, and a few techniques I have seen working. I will have to remember using them. Please share if you have some suggestions.

What practices, rituals, and processes from the business life we brought to our relationships?

This was an introduction round, useful to bring up lots of possible material, so that we can decide what to follow up on. For this reason we didn’t go in depth for any topic during this time box.

  • trying the “release early, release often” strategy in relationships
  • taking tools from relationships and using them in project management, not the other way round
  • taking ideas from SCRUM, having monthly check ins
  • using kanban boards
  • no process, just “chaos management”, something pops up and we deal with it
  • GTD[II]Getting Things Done in relationships
  • considering using agile in relationships: just reading about it had a calming and soothing effect
  • having a fix date evening a week, from the beginning, for years
  • being a relationship process geek, dating other geeks (or making dates into geeks)
  • someone complained about the letter soup, all the acronyms they had never heard before. Lucky them
  • someone never ever used any process, “maybe it is the reason I am single” (we did not get to answering that, I am sorry)
  • we try something, we use it for a while, but not consistently

Patterns, anti-patterns, successes, and failure modes of using processes.

This is when we started having an actual dialogue. As usual during a Cookbook, we can be a bit all over the place, since what someone will say next is not always an elaboration of what came first, but it could be their own position on the topic. I made my best to put together something coherent, but do not expect an essay.

Let’s start from my position: processes are important for discovery and development, but will not save you and your relationship. If there are underlying issues, they can help discover them, but they won’t keep you safe from them: hoping to do that is what I call “bargaining with the Devil”. No process will save you from a partner not wanting anymore the relationship, from lack of understanding, from lack of good will. Maybe, and just maybe, some processes can help the people involve realize they are drifting, realize there is a problem before it explodes/implodes terminally.
Maybe. I hope. A fire alarm, being told “this is a fire hazard”, maybe some ideas on how to fix the hazard, and hopefully an evacuation plan for when everything is on fire.

The lockdowns and lack of distraction prompted someone to go for a “release early, release often” strategy for their relationship: they declared very early they were in a relationship (after a couple of weeks), and kept on iterating, “is this still working?”.
It worked really well for them.
Could it work outside of a lockdown? Could we ignore the other shiny distractions?

Someone else noted that the processes they tried did not help bring up important topics: their partner was reluctant about sharing how they felt.
Or, as someone else noted, had no idea about it: “if you ask me how I am feeling, I have no idea, and I will feel pressured to give an answer, and like you less“.
(I would imagine this would be a good thing to know, “my partner has no idea how they feel and will resent being asked”, but how do you find out?
I can see myself getting resentful without realizing it, because, well, I have no idea how I am feeling. Chicken, meet egg)

Relationships should be about feelings, not processes” was brought up, duly noted, then we all felt like ignoring it.
(I may be joking here)

How do we handle context changes with different processes?
As a freelancer, I have different projects, with different tasks, timelines, people involved.
How do we do it with different relationships? Someone proposed kanban boards
Did I mention this was a seriously geeky Cookbook?

How do we introduce processes in a relationship? How do we propose having check-ins and other “rituals”?

Do we have any process to manage expectations? The expectation to have a process? Not to have one? The expectation that the process should bring something?
Don’t think about the pink elephant. No, not that pink elephant: the other one, bigger and pinker.
Still not thinking about that pink elephant? Would you mind telling me the process of not thinking about, I repeat, that pink elephant?
Easy.

We ended asking what relationships and relationship processes need design? Romantic ones? With lovers? With friends? With family?
We did not answer it, and it is left as an exercise for the reader.

How do you introduce routine check-ins or rituals if they do not come naturally? Or do you then let it go? 

Do check-ins and other “process activities” take time off romantic activities?
What would you prefer, a 2 hour retrospective and sprint session, or a massage and a candlelit dinner?
(My own personal solution is to mix and match, making the check-ins into the romantic time, making the romantic… and of course pairing up with weird process and relationship geeks like me. The second part is the important one)

A nice ritual is asking every evening “what was the best part of your day?”.
Or choosing a question from a collection to connect with each other more.

How to reassure someone that feels checking how it is going will lead to drama? How to deal with conflict/drama avoidance? [III]I know conflict and drama are different things. Let’s not make a drama about it
Someone proposed to ask them what are they afraid it would bring, what they want to avoid, asking them to explain “why not” instead of having to convince them of “why yes”.
I feel it is vaguely manipulative, but I am not really sure.

Someone complained about lack of continuity, “we tried for a while, then gave up”.
Someone else pointed out it is possible, just possible, that doing the dishes every day is better than letting them pile up for weeks.
I guess I’ve been doing it wrong so far, and the strategy of “buy new dishes when the old ones are dirty” could do with some refining. [IV]I may be not totally serious

We touched the issue of “who keeps track of the check-ins?”, since it can add stress, possible conflicts of “this time it was your turn”, “you don’t care”, and all that fun.
One possibility is proposing to take the initiative: “if you are interested but do not want to keep track of it, I can be the one doing it“.
Of course this does not solve the conflict avoidant “I will say yes to please you”, but what does?

A possibility is always “let’s try regular check-ins for a month”.
Then… let’s check-in about how it is going? Default to stopping unless we all go “hell yeah?”. Or mumble mumble it stopped happening. Or mumble mumble we now have a process to have a process. Or a committee.

Someone pointed out that they do not like being asked how things are going, because they do not know.
And someone else pointed out that they actually enjoyed the occasional conflict and/or drama, because it cleans the air. I guess it is a different attitude to doing the dishes.

What would a MVR be (minimum viable relationship)?

In the startup lingo, a MVP is a Minimum Viable Product: the smallest set of features we can offer, and see how it works. It is a concept aiming at stopping the feature creep, trying to create something perfect before we even know it makes sense, something about the “perfect is the enemy of good enough“.

In a way, the MVR is the minimum amount of features [V]what are the features of a relationships? Do we all agree? How do we find out? Do we need a process for that? we could need to say “yeah, this is a relationship“.
Again, we touched to the idea of going the “release early, release often” route: “OK, we like each other and we like spending time with each other, this is a relationship, let’s find out what it means“.
Good luck doing it in the “I do not want to commit and I want to keep my option opens” world of dating in Berlin outside of a lockdown, though.

We explored what would minimum set would be. “A commitment to a certain amount of time and depth” was proposed, will less emphasis on “what do we call each other”, or being public about it.
If it looks like a relationship and feels like a relationship, it is a relationship.

Of course, the minimum set can be different for different people, and we end up in the wonderful world of “this is not a relationship for me” or “if it was a relationship, you would…”.
Repeat after me: people are different. Relationships are different. Relationships with people are different.

A MVR would come together with the idea of a PoC [VI]proof of concept: could this work? How do we test it somehow?
Someone proposed the idea of having a different proof of concept for different core features of a relationship, scoping them first.
As expected, this got seriously geeky:
we can do PoC for different features, maybe if names are important and we want to try different ones.
We can explore the scope of what is important for us, for the people involved. As an example: commitment, prioritizing, aligning on values, and whatever else is needed.
Can we meet each other needs? Wants? Let’s explore. What do we do if we cannot?

Of course, saying “this is a relationship” should be reciprocal.
“She is my girlfriend but she doesn’t know it” did not work great in the teenager years, it still doesn’t work great. “I am polyamorous but my partner does not know it” neither, that’s called cheating and it is done differently.

As always during every single cookbook, someone pointed to the Five Love Languages. Here. It’s done.

Given the geekiness of the conversation, we explored the possibility of having user stories for what we want in a partner or a relationship.
As they say in the startup world, you do not want a feature, you want to narrate it. In the same way we do not want a drill, we want holes, we do not really want sex, we want some sort of connection with someone else, or something.
This maps nicely to the ideation phase.
How could an online dating service integrate this?

Chaos management

The topic was introduced as a joke, “in my last relationship, we didn’t really have a process, we mostly did chaos management when something exploded“, and we decided as a group to double down, take it seriously, and discuss it.
Geeky, I repeat.

In engineering, Chaos Engineering is actually a thing: it is the process of introducing controller perturbations in a systems, to make it more resilient, or build confidence in it.
Think about a more structure way of going “what happens if I poke this?“.
We could have a process to do this in relationships, of introducing somewhat controlled problems and challenges, with a way to stop and check how it’s going.
It is not chaos engineering if the result of your test is “ops, the house is on fire, I guess it wasn’t as fire proof as we thought”, it is something else.

Relationships and human interactions come with lots of unsaid expectations, “we are going to be exclusive/monogamous/follow the relationship escalator“: how do we find out about them? How do we clarify expectations? How do we discover where we differ, and what to do about it?

Doing post mortems about problems and conflicts and things tried is a possibility, maybe with a different name, depending on taste.

My favorite process is: when trying something new that at least one person in the relationship consider potentially risky or problematic, it is important to have a simple way to say “I think there is a problem”, or an agreed upon time after which we stop and reconsider.
In general, if someone in a relationship feels there is a problem, there is a problem, even if the problem is just that someone feels there is a problem.
If another person decides to ignore it, we have a bigger problem.
And that makes at least two.

Someone pointed out that if we need a process, that is already a problem. When hiring, they want people with whom they won’t need a process to work together.
Having as little process as possible is the best process.
I personally agree, but I will stick to the “things should be made as simple as possible, but not simpler than that“.
The end point of a relationship process should be not needing a process: but we have to get there somehow. It can happen by magic, divine grace, luck, emergent behaviors, but I personally prefer to nudge my luck.
Illusion of control and all that.

What I am trying to say is that we can try to have a process to arrive to not having a process. I guess it is very Zen, in a way.
From using check-ins to trusting we won’t need them.

Back to chaos management: how big can the perturbations be? What if at least one participant uses a sledgehammer to test the relationship, and keeps on doing it?
(I still think that is not chaos engineering. See house on fire above)

That is to say: no process will save you if there is no goodwill. If someone does not care about the relationship, no process will make them care. If someone does not want to follow a process to problem-solve together, no process will make them, because, say it with me: they will not follow it.
(Or will follow it to the letter but not in the spirit, “I have done everything right, you cannot blame me if the house is on fire!”, and they won’t get a bucket of water or a fire extinguisher)

Do you re-use material from a relation in another (like same kind of date, play, messages…)? Which material? How did it work?

This topic is about a lot of questions: there is no right or wrong, each person has to decide themselves, possibly in a dialogue with their partner(s).

Do we reuse processes and content from other relationships? When is that appropriate?

Do we find out the perfect thing for the specific person, and keep it for them? Or do we discover something that just works, and we keep on using it with everyone else?
Is there a middle ground?

What can we reuse, and not?
Is “having sex” something we should never reuse? A specific position? A specific soundtrack? Maybe we do not reuse it while we are with a partner, but we can use it again in the future when we are not together anymore?
Are we bringing the ghost of a love past to a new one, or just what works?

When reusing something, how do we avoid the expectation that it will work like with someone else? How do we keep an open mind?

My personal guideline is that it is fine to reuse a structure/process to find out what we want to do, but not the content/thing itself.
Also, I think it is fine to reuse what I discovered on my own (or, maybe, I don’t know, during a Cookbook), but not what we discovered and ideated together, at least while I am with that partner.
I mean: if I would never reuse anything, given 9 years of cookbook, I would be in a bit of a problem when dating. It could be an interesting improv exercise, “do something you never did before”, but I would not have high hopes of finding something enjoyable.

This clearly brings the problem of “what should be exclusive to a specific relationship“, what is sacred, what is special. Each person will have to answer by themselves.

Someone went all Heraclitus on the issue, pointing out that “nothing can ever be the same twice, so we never really repeat the same thing“.
Fair enough. I would consider it a cop out, if I asked a partner to keep something sacred between the two of us, but, as said: there is no right or wrong here.

Someone else noted that their bad memory makes it hard for them to remember what is specific to a certain person or situation, and they end up mixing up things with different people.
To address this, we talked about the possibility of “keeping track of the things I could lose track of”, on lists and so on.
I guess it is turtles all the way down.

Final notes

This was fun, geeky, with lots of ideas, ideas about ideas, ideas about how to have process to have ideas about ideas, and so on until we run out of turtles.
(We never run out of turtles)

For some people it, was an introduction to a whole new world of geeky terminology.

Someone commented that “it will take me a while to try everything”, and I wish them good luck, since the Cookbook hive mind gives on average 3 contradictory advices for every possible issue.

Have fun playing with relationship processes, designing processes, abandoning processes, and having processes to do the above.
And if it’s not fun: don’t do it.

Lots of thanks to everyone that participated and shared.
See you all next time.

Footnotes[+]

One comment

Leave a Reply

Your email address will not be published. Required fields are marked *