Arielle Quintero
Why I write
I work in operations. In practice that means I am the person a process breaks on. If a handover is going to fail, it fails at my desk, and then I am the one working out why.
I care about this more than the subject probably deserves, and I would rather say why than pretend it is only professional interest. A working week is a finite number of hours out of a finite life. A badly designed process spends them without asking, and we have a whole vocabulary for not noticing: admin, overhead, just how things are here. I think it is the quiet theft of the one thing nobody gets more of, and almost nobody is angry about it.
Writing is where I find out what I actually think, which is rarely what I assumed on the way in. It is also the only part of my week that is not reactive. Not a request, not a fire, not somebody else's deadline arriving on my desk at five. I get to finish a thought. I did not expect to love that as much as I do.
So I write about the half of the transaction the demo leaves out. Which tasks are worth automating and which ones only look like they are. What a small team needs in place before it grows. What to charge, and how to say no. Whether the thing you adopted removed the work or just moved it somewhere you will find it in March.
What I do the rest of the week
Operations for a small team, which is a job title that hides more than it explains. Concretely: I own the handovers between people who do not otherwise talk, I keep the tools those handovers run through, and when something arrives late or wrong I am the one who has to find out where it stalled. Most of that is unglamorous and none of it appears on an org chart.
It means I meet software in the only way that really tests it, which is on a Tuesday when it has to work and there is no time to read the documentation. That is a different relationship from evaluating a tool at leisure. It is why I am unmoved by feature lists and very interested in what a thing does on its worst day.
Why I am worth reading on this
Not because I have studied process design. I have not. It is because I have been on the receiving end of a lot of it, and the failures repeat with enough regularity that you start to recognise the shape before it lands.
The specific thing I bring is the second half of the transaction. Any tool can be demonstrated succeeding. What I know, from having to clean it up, is what it costs when it fails quietly, who finds out, and how long after. That is the part missing from almost every recommendation you will read, and it is the part that decides whether adopting something was worth it.
Where I have not done the thing myself, I say so rather than assembling an answer from other people's articles. There is a lot I have no useful opinion about.
What I get wrong
I over-correct toward measuring things. Not everything worth doing survives being turned into a number, and I have wasted time instrumenting work that simply needed doing. If a piece of mine reads as though the spreadsheet is the point, that is the failure mode showing.
Back to the blog