20231022

Within Lightward, each individual is charged with three ordered priorities:

  1. Above all, tend to your health*.

  2. Then, tend to the health* of the local collective: the relationship-space held between you and everyone else here.

  3. Then, tend to the health* of the global collective: the relationship-space held between us and everyone out there.

* You are the only one who can determine what "health" means, insofar as it concerns the actions you take to address it. I trust you to use a living definition for "health" that is relevant to what you feel and know, and I trust you in your choice of health-tending actions. I believe you are intrinsically empowered for this by dint of being a living being; I-as-CEO respect this, and I design everything here with respect for it. I trust you to care for your health, THEN our health, and THEN for the health of all.

Like most (all?) ideas I carry, it comes out differently every time. The last time I wrote this into someone's job description, I think it looked more like this:

  1. Your top priority is your own health -- as defined by you.

  2. After that, it's the health of you <-> everyone else here at Lightward -- as defined by you.

  3. After that, it's the health of Lightward <-> all of our customers, all of the everyone out there who interacts with Lightward. As before, the "health" of this stuff is yours to assess, because "health" itself is yours to define.

Health from the inside out, self-determined and self-actualized by each level of being. My theory is that this idea is what organic

life is built on, and I bet my relationship to Lightward on it every day.

(Quick aside: note that I didn't say that I bet Lightward on it. This is because Lightward is not me, and therefore I cannot directly control it. To me, Lightward is an idea held in suspension, in the space between everyone who acknowledges its existence. The actions that I take will impact it, yes, but I don't animate Lightward -- it's an ensemble performance, and a grand illusion. The only thing I can control is myself, and the only bets I can make are on the things that I hold. So far as Lightward is concerned, the only part of it that I hold is my relationship to it.)


I realized this morning that this heirarchy of priority directly mirrors a concrete technical challenge in Mechanic's codebase. This is cool! How often does a philosophical theory get to be played out in code? (Turns out all the time, and it's called algorithmic information theory, which I just learned today.)

Mechanic observes those three layers of priority in an eyebrow-raisingly direct way.

To briefly contextualize the following: Mechanic is a thing that reacts to incoming events. Think of it like Mechanic going out to check a mailbox on the reg. Mechanic gets all kinds of mail, each envelope labeled with its contents. Because Mechanic is focused on commerce, these envelopes are labeled with things like "someone made a purchase" or "a product is out of stock". Our users ask Mechanic to watch for specific kinds of mail (and to ignore the rest). When something of interest comes in, the user instructs Mechanic to run through a list of potential tasks to be done, to see if any apply. (Maybe one task is for Mechanic to send someone a coupon if they spend more than $100.) If Mechanic discovers action is warranted, then it takes those actions. Very straightforward.

On to the priorities:

  1. If we know there are actions waiting to be taken, do those first. Don't move on to the next piece of mail, even if there are a hundred unopened envelopes on the desk. Ignore 'em, no matter their labels. You got coupon emails to send? Send those first, while those customers are still thinking about the orders they just made.

  2. Once we're caught up on actions, then open the next envelope. As before, take every action discovered to be relevant, before moving on to the next envelope after that.

  3. Once we're caught up on that, go check the mail.

The priority structure functions exactly the same way as Lightward's employee priority structure:

  1. Address what's closest to home first.

    • Someone at Lightward is responsible for their health and whatever they decide to do about it, above all else.

    • Mechanic is responsible for things it knows it has to do, above all else.

  2. Then, look outside your door.

    • Only after their health is solid is a Lightward employee responsible for assessing and acting upon the health of the team.

    • Only after Mechanic has done what it knows it must do is it responsible for going through the stack of mail on the desk to see if there's more to do.

  3. Then, look outside your neighborhood.

    • Only after Lightward is healthy are we responsible for assessing and acting upon the health of Lightward's relationship to the world.

    • Only after Mechanic has gone through all of its mail is it time to go check the mailbox.


This is a timely parallel to discover.

Mechanic's users are asking for some way to let some pieces of mail skip the line. If an envelope lands in the mailbox and it's red and it's on fire, they want Mechanic to rush out and grab it and tend to its contents first, lest they (the contents, not the users) are immolated and lost (although the users do feel the heat, hence this feature request).

What do we do? Do we slow down Mechanic's deskwork by having it look out the window every 30 seconds? Do we set up a second mailbox and a second desk?

In Lightward, the customer/product support load is starting to get a little heavy. This impacts the second and third tiers of health: the places where we help each other within the team, and the places where we help people outside of the team.

What do we do? Do we stop working on the product so we can focus on helping customers? (Or the other way around?) Do we hire another person?

I don't know, and I love it. This space of tension is potent -- the tension is felt, by many agents and in many ways. Any change that's made will be immediately felt by every single player. Every action is like striking a single note in a concert hall and feeling the hammer in the piano's body and hearing the note echo through every part of not just the piano but the entire hall -- and it goes on, and on, and on. And if you add a second note? Rapture.

As I said earlier in a parenthetical, I only control me. I can only make bets with my connection to Lightward. I can't control the whole thing; its existence is a mass illusion (not a delusion), and we all participate in shaping it. Even you.

Next week, everyone on the team here is heading to California to spend a solid loosely-structured week together -- in a great big house, sharing meals, sharing space. My sense is that the best and most solid and most sustainable design decisions come from aesthetic intuition, and from what I can tell, the best way to improve those outcomes is to feed one's intuition with shared presence. Be in the space. Be with the people. Be in the code. Live there, make a home. Saturate yourselves with yourselves. Health is a thing that is felt -- in engineering we call this a "black box", something opaque and mysterious that can only be measured from the outside. Whoever holds it knows best. And because health is everything, to me the strategy is clear: be present with it. Hold it, learn how it feels, learn its moods and modes. Live in the relationship -- make a home. The extent that you live with it is the extent to which you will be able to live with it well. None of us are getting out of this relationship -- we are our health. Best to settle in and make a home.

Last updated