Handshakes between teams are state machines
Operations should look more like a data factory if everything is working smoothly. Each process is state machine of agreemeents between teams. Read: "Everything Starts Out Looking Like a Toy" #233

Hi, I’m Greg 👋! I write weekly product essays, including system “handshakes”, the expectations for workflow, and the jobs to be done for data. What is Data Operations? was the first post in the series.
This week’s toy: making synth noises with this fun Ableton simulator. I have no idea how to make the noises I’d actually like to hear, but darn this is fun. (You might need to use headphones to avoid annoying the people around you if you’re in a public place.) Edition 233 of this newsletter is here - it’s January 13, 2024.
If you have a comment or are interested in sponsoring, hit reply.
The Big Idea
A short long-form essay about data things
⚙️ Handshakes between teams are state machines
“Can you create that report for me?”
“Is that data loaded yet?”
“Do you know what went wrong?”
These are all simple (or not so simple) examples of interactions between team members that can be modeled as state machines. A state machine is a way to describe a process that takes some inputs and results in a different state.
If the state machine is deterministic, no “in-between” state is possible - it is either this or that.
If the state machine is not deterministic, multiple outcomes can occur depending upon the system inputs (including no change at all).
Triggers cause the state machine to run, and rules govern whether one state is chosen or another.
This all sounds a lot like an operations team and the way individual processes happen.
Ops Teams are State Machines for State Machines
Whoa, that’s sort of meta to think that the Ops team itself is a state machine for state machines. But it makes sense when you consider that:
Individual teams (Sales, CS, Product) ask Ops to take on new work where the output of that work fits into the rules made by existing systems (think of these as Rules of Engagement.)
Each individual process is a state machine - a workflow triggered by known conditions in the business - that results in known outcomes for a record going through that process.
Take an example:
a lead enters the system through a form-fill from a website
based on the components of that form (name, email, phone number, website), you can enrich the data and determine if the lead is in your ideal customer profile
the end product is a qualified or unqualified lead, though it’s possible things might change as you learn more by engaging with the lead
If your state machine/process is intended to be deterministic, you need to be able to break your decisions down into true/false statements. Ambiguity is not your friend in operations, unless it’s an expected outcome where you have a process to remediate it or remove it from the data “factory”.
This does not mean you have a process for everything — it means your processes are easy to determine by someone with little previous knowledge about the process.
Make the state machine atomic for better results
Your state machine probably looks something like this when you first created it to handle something like a lead process. The problem? It’s too vague.
When you go down to the field level for a record, you can create qualifying or disqualifying statements, e.g. “when you resolve this domain do you get a 200 ok or a 404 - Not Found”, all the way to “does an image capture of this page have an 80% match in similarity structure to a composite image of the websites of our customers? The point is to get to a true/false bit that you can compute as part of your state; and if it’s falsey but undetermined, you can hand it off to another process that itself will result in a true/false answer.
State machines should be simple. They are not intended to do more than sort (very quickly) so that you can divide work and send it into known buckets where it will move along the way. I think of them as a slightly more sophisticated version of a Kanban but something that happens automatically.
What’s the takeaway? Your ops team will function more effectively by outputting answers to common questions and processes with simple state machines. These answers to “how do we do things” make it easier for someone without deep knowledge of a process to move the items of a process along effectively.
Links for Reading and Sharing
These are links that caught my 👀
1/ What to document when you document - I’m a fan of writing documentation - it’s one of the best ways to memorialize a decision, codify a procedure, or just plain explain how we do stuff. But what kind of document do you write for the intended skill needed? Read Fabrizio Benedetti’s Seven Action Model, which handily buckets docs into things users need to do.
2/ He’s on 🔥! - When an average of 42% of all shots in an NBA game are now 3-pointers, is it time to move back the 3 point line or change the scoring? It’s starting to remind me of playing NBA Jam. Maybe “from the logo” should be 4 points?
3/ What’s your commute speed? - A really nice graphic from the Washington State Department of Transportation on highway speeds tells us that when you’re going 50 on the highway in Seattle, you’re actually helping traffic given the volume.
It doesn’t feel that way when you’re in traffic, and it will be interesting to see if this changes based on return to office changes at Amazon and other Seattle-area companies.
What to do next
Hit reply if you’ve got links to share, data stories, or want to say hello.
The next big thing always starts out being dismissed as a “toy.” - Chris Dixon