changing systems

Is there a word for acceptance without approval? intimacy without attachment? embracing without preserving?

To change a software system I need to become part of it, I need to understand how the bits fit together. For example: When we spin up a new AWS instance, we use code in one repository, which activates a system controlled by another repository, which includes a script that shells into another machine where it makes an HTTP call to localhost to a service in a third repository, which digs around in its history and links to artifacts created by code in a fourth repository to package up a fifth repository. ¬†Do I approve of this flow? It doesn’t matter. I need to accept its existence, without accepting its inevitability. I need to love it enough to understand it, and only then can I confidently change it.

In social systems too, I am part of the system already. I need to understand its workings; I am part of them. It is from here I can exert force for changing them. Resentment, denial, judgement: these hurt me, and they change nothing. I will face my fear, and my pain, and let it pass through me. I will be not surprised, I will be not approving, I will not expect that because it is this way now, that it must always be. I am part of the system but I do not help it self-preserve, in ways that I am able to see because I no longer punish myself with resentment and terror for being able to see them.

Participation is not endorsement.

To understand a complex system, whether society of software, means immersing myself in it, while retaining perspective. It means observing each interaction without surprise, it means intimacy without losing my self. To understand deeply is to love – to love without needing it to stay the same. There’s a concept our culture doesn’t have: love, intimacy, familiarity while encouraging change. Even with children we are like “I wish they didn’t grow up so fast!” No. Let them grow, it is the changing that holds their greatest beauty.

When I can hold in my head both the way the system works now and the way I wish it to work soon, then I can find the stepping stones and the pressure points to move it from here to there.

Areas of responsibility

“And the Delivery team is in charge of puppet….” said our new manager.

“Wait we’re in charge of WHAT?” – me

“Well I thought that it fits in with your other responsibilities.”

“That’s true. But we’re not working on it, we’re working on these other things. You can put whatever you want in our yellow circle, but that’s it.”

“The yellow circle?”

See, I model our team’s areas of responsibility as three circles. The yellow system is everything we’re responsible for — all the legacy systems and infrastructure have to belong to some team, and these are carved out for us. Some we know little about.
Inside the yellow circle is an orange circle: the systems we plan to improve. These appear on our backlog in JIRA epics. We talk about them sometimes.
Inside the orange circle, a red circle: active work. These systems are currently under development by our team. We talk about them every day, we add features and tests, we garden them.

That yellow circle holds a lot of risks: when something there breaks we’ll stop our active work and learn until we can stand it back up. Management may add items here, as they recognize the schedule risk. We sometimes spend bits of time researching these, to reduce our fear of pager duty.

The orange circle holds a lot of hope, our ambitions for the year and the quarter. We choose these in negotiation with management.

The red circle is ours. We decide what to work on each day, based on plans, problems, and pain. Pushing anything directly into active work is super rude and disruptive.

“OK, it’s in the yellow circle, cool. I’ll work on hiring more people, so we can expand the orange and red circles too.”