I run operations alongside the robots. Now I’m learning to build them.
I’m an operations manager at Amazon, inside a heavily automated fulfillment facility. Most people learning machine learning and robotics have never run a floor where those systems have to work at 2am. I have — and I’m working through the engineering behind them in public, one checked box at a time.
2007 · First floor
A production engineering internship put me on a floor full of industrial automation for the first time. It stuck, even after my career went elsewhere.
Today · The deployment seat
I'm an operations manager at Amazon, inside a heavily automated fulfillment facility — robotic arms, mobile robots, scan tunnels. The machines run around my team every shift, and I see exactly where they shine and where they stall.
Now · Crossing into the engineering
Linear algebra, probability, and optimization first; then the models, then the robotics stack — ROS 2, manipulation, perception. Two public checklists track all of it, and every box I check ships an explainer.
This site has one subject: what it takes for automation and robotics to earn their place on a live floor — and what it takes for me to get from watching that happen to building it.
Where I'm standing
Robotics likes to describe itself as an intersection, and the hardest problems tend to sit at the boundaries rather than inside any one discipline. The boundary I care about is the one between a capability that works in a lab and a system that survives a Tuesday night: 11pm, a crumpled mailer, a new hire, a jam upstream, and nobody from the vendor in the building.
Moving a capability across that boundary is its own engineering discipline, and it's where a lot of the current opportunity sits. I already live on the operations side of it. I'm learning the engineering side deliberately, in the open, and this site is the record.
The method
The floor is the lab notebook. The writing does two honest things at once: it explains how these machines actually work in plain English, and it reports what happens when they meet reality.
The learning log is the spine of it — two checklists covering the maths, the models, and the full robotics stack, written before I started so the denominator can't quietly shrink. A box only gets checked when something ships with it: an interactive explainer, a build, or a written teardown. What I haven't touched stays visible, which is nearly all of it. When I build something, the writeup includes a "What broke" section, because a site about demo-versus-deployment honesty has to model it.
What you'll find here
Operator's takes on robotics news. Plain-English teardowns of the cameras, grippers, and models behind a single pick decision. The case for why automation that wins the demo loses in production. And the learning log itself. The writing lives in The Log, the builds in The Build Log, and the curriculum in the learning log.
Where this goes, I'm finding out in public too.
- 01Industry-level only — never about a specific employer or workplace.
- 02Public sources only — every claim traces to something you can read.
- 03The insider test — if it could only be known from the inside, it doesn't get published.
- 04Views my own — this is me thinking in public, speaking for no one else and certainly not my employer.
- 05No checked box without an artifact — if I claim I learned it, there's something published you can read.