Robot Girl Gang

Category: Philosophy

  • Mythology In The Technical World

    Don’t worry, we’re not going to be carrying flower-strewn portraits of Steve Jobs around in the streets today. It’s a slow burn but it’s worth it.

    At Amazon Robotics, our products have many many stakeholders but the main everyday users boil down to three main categories: the onsite Technicians who maintain the physical portions of our products, the Workers who directly interact with our products to make customer orders happen, and the Operators who manage the overall super system of people and technology to get the right stuff out of the building on time.

    Back at the barn, we’ve got Support Engineers, Design Engineers, and Product Managers watching from afar. And every one of us has a story of when a Technician, a Worker, or an Operator has done something apparently insane in a good faith effort to get better behavior out of their system.

    In an AR Storage system, happy little drive units bring “pods” (those yellow shelves) over to a workstation on the fence line where a Worker can interact with them by stowing, picking, or counting items. Sometimes those pods just don’t show up for a while, leaving a Worker with nothing to do. At one site, an Operator observed that it seemed like the system was getting “stuck” and the best thing they could do was to log out of the workstation and log back in again, similar to how rebooting one’s computer solves most ills. It seemed to work, as that workstation would then have pods show up. And, as Operators talk and share tips and tricks just like anyone else, this behavior rapidly spread throughout the network.

    It drove us nuts because that’s not how the system works at all and it was actually hurting their overall system performance. When you don’t get pods at a workstation, it’s usually because they’re either stuck in traffic or traveling from far away and, just like driving to Grandma’s house, the Google Maps arrival time estimate gets a little fuzzy the further away you start. All that logging out does is tell everybody who’s already en route to stop and turn around. Logging back in just asks for new work that’s probably coming on totally different pods from different locations. Strobing through logout/login cycles just increases traffic inside of the system and slows down everyone else around you.

    But Operators don’t know any of that without doing a lot of homework to research it and figure it out. It’s not how any other kind of material handling system works, so they couldn’t infer it from experience, and the system provides no other hints that it might be the case. We provide training on how to manage our systems but don’t do a great job at the why it behaves the way it does.

    So, the Operators are doing what human beings do best: they experimented and built up an empirical model of how the world works with what information they had. It’s how we’ve worked out how to understand the world around us since we became human. It’s how we developed mythology in the first place[1].

    Bret Devereaux, a classicist who blogs prolifically at A Collection of Unmitigated Pedantry, makes this argument brilliantly in his series Practical Polytheism. Greco-Roman religious practices were a rational, functional system for understanding and attempting to influence a world that operated on complex, invisible mechanisms. If it seems like every time you see four red birds together that it rains the next day, the next time your fields are dry you’re going to try to collect four red birds to see if the rain shows up. Or, in a more modern perspective, if you need it to rain you wash your car.

    And so it is with our own infinitely complex and invisible systems. Devereaux’s framework applies directly to how we fill in those gaps to make sense of things and find the levers:

    1. We observe the system exhibiting a behavior. Could be good or bad or just weird.
    2. We try to figure out what preceded that behavior and try to replicate it to see if there’s a relationship.
    3. Neato, it appears to have worked!
    4. Even neater, it worked again! Even if it doesn’t always work, you still share it because hey, at least try it, right?
    5. The thing that sometimes works becomes received wisdom, handed off between people over and over.
    6. Suddenly, operationalization occurs. You always try the thing that sometimes works as part of your standard procedure.
      Congratulations, you’ve built a ritual. Two more generations and you’ll be interpreting robot entrails to foretell the future. (Usually, that future is “very soon you will need to mop”).

    Technical training doesn’t fully immunize against this, either. Our drive units have batteries, motors, some sensors, and a motherboard-like brain driving all of it. A backplane ties it all together. The backplane is dirt simple and has an insanely high reliability rate. When they do get returned to us as defective, we almost always turn them back around with no fault found. And yet, we see a large percentage of our Technician population advising each other to replace backplanes whenever they cannot immediately diagnose a problem on a drive unit[2].

    Our Technicians are generally smart, practical people keeping a whole lot of stuff working hard in a 24/7 environment. They’re not stupid; they’ve just found that when they replace a backplane, a whole lot of issues tend to clear up. But replacing the backplane also incurs a whole lot of “invisible” work such as resetting clocks, reseating connectors, or updating firmware. It’s that psychological reinforcement of the physicality of replacing the backplane that keeps the ritual alive.

    So, how do we break the wheel?

    Requiring everyone to sit in a sauna and doubt everything they believe to be true is impractical; only René Descartes really had the time and dedication to sit in a sauna[3] and redevelop literally everything from first principles. So we need to give people a more useful, more accessible, more legible framework for the world around them. Otherwise, as natural empiricists, we default to mythology.

    To be clear, I’m not trying to kill God over here. Empiricism still serves us well, and faith systems give us comfort and meaning and understanding beyond the edges of science. There’s still plenty we can’t explain with math and logic. Like, you can’t explain the 2026 White Sox without a Pope and the magic of friendship. We don’t know why it works, it just does… in mysterious ways.

    That ability to explain why is what gets us from Practical Polytheism to the Enlightenment. And to bring it back to our AR system, it really boils down to being able to answer four simple questions.

    1. How do I know it’s working?
    2. What can I do to affect the system?
    3. When can I not do anything to help?
    4. When I can’t help, what’s making the system behave the way it is?

    Let’s take them each in turn.

    1: How do I know it’s working?

    It’s all about believing that the system has got this, and will be able to tell you when it doesn’t. You need a system that can provide the positive confirmation of performance. In other words, your system must be capable of proving the hypothesis that it is, in fact, performant[4].

    And no, that’s not a dashboard[5]. Dashboards only provide the negative confirmation: “this particular piece isn’t broken”.

    Dashboards proliferate inversely to the level of trust one has in a system to Just Work. You don’t lie awake at night worried about sewer infrastructure because you’re very confident that your poo will be taken care of once it goes down the drain. If you drive an automatic, you’re not typically paying attention to what gear you’re in because it sounds right.

    Constant bombardment with solely negative confirmations doesn’t produce confidence in humans; it produces anxiety in a never-ending doom loop of trying to salve that anxiety with… more negative confirmations. This is why your program review full of otherwise rational people keeps going sideways, and this is why your Operators keep looking to empirical means besides the dashboard to gain certainty.

    2: What can I do to affect the system?

    A while back I had mapped out what factors actually impact an AR system’s performance. Of the 28 factors, the only ones actually controllable from the field were floor cleanliness[6] and having trained, disciplined staff available[7]. They’re victims of everything else, from customer whims to the weather.

    But neither floor cleanliness nor staff excellence have immediate levers to pull for immediate gain. You need to either be great at or suck at either one for weeks for them to have an impact, and there’s no magic wand that can turn those around overnight.

    In a world with only structural levers and no acute levers, good design makes or breaks you. Making the clear link between performance and those structural factors, and designing good incentives for consistency over heroics, gives your operators the real levers they need.

    Give them the visibility to accept the things they cannot change, the levers and incentives to change the things they can, and the system fluency to know the difference.

    Speaking of that…

    3: When can I not do anything to help?

    This question requires the most careful handling because it’s all about helplessness. You’re at the mercy of factors larger than you that do not care about your opinion, whether they be weather, Gauls, or the Ever Given wedged in the Suez Canal[8]. How do you help your operators get through these situations without them sending an intern to look for four red birds?

    First, acknowledge that there’s nothing that your user can actually do to affect the situation. Explain the situation in plain language so that they can understand not just that they cannot do anything to help, but why they cannot action it. And finally, give some sort of estimate as to when the situation will be over or when they’ll be able to take an action to help.

    Anything else, including silence, puts you directly into that anxiety doom loop of “I need to be doing something.” Because…

    4: When I can’t help, what’s making the system behave the way it is?

    Which is the other accelerator in the doom loop. Shit’s bad, you don’t know why, it’s not your fault, but you better believe you’re going to catch hell for it anyway.

    Our Operators deal with this constantly. A thunderstorm shuts down the yard of a sort center 500 miles away, which means we’re not going to send trucks to them. Since we’re not going to send trucks to them, we’re not going to pick any of the customer orders destined to them because we don’t have anywhere to put them. An Operator running the picking operation has no idea that there’s a thunderstorm, they just know that they aren’t getting work to do but they have a volume forecast they’re expected to meet and won’t.

    In 2012, Italian seismologists were convicted of multiple manslaughter for failing to predict the 2009 L’Aquila earthquake after attempting to assess a cluster of swarm tremors that had been affecting the town in the months prior[9]. The Italian Supreme Court eventually overturned the convictions, but not before the damage of accountability without agency had been done. Getting yelled at for a thunderstorm 500mi away is the milder end of that same spectrum.

    The fix here is both organizational and technical in nature. First, you have to give your Operators visibility into what’s actually affecting their system, even to two or three degrees removed. They have to know why they’re getting hosed. And then, leadership has to dispel their own mythology about how their systems are supposed to work and believe their operators that they’ve entrusted with that system. Not doing so leads to Potemkin villages: ritualistic performative orchestrations designed to provide cover rather than value.

    So now we’ve come full circle: from understanding how mythology works, to why it worked then, and how we still develop it every day even (or perhaps especially) in deeply technical disciplines. Human beings are about as smart today as we were three thousand years ago, doing the best we can to understand stuff way more complex than we can easily perceive.

    The difference here in the technical world is that all of our systems were designed by human beings. That means that we can change them to be more legible and more intuitive. Because it’s 2026 and an underslept Operator on Back Half Nights should never be in the position of having to search out four red birds.

    And they say that the classics are merely decorative in the modern age.

    [1] – SURPRISE, IT’S A LIBERAL ARTS POST!

    [2] – I am in the Slack channels and I can see you. You cannot hide.

    [3] – Yeah, I know it was technically a poêle, not a sauna. Descartes can find me and fight me should his dead ass wish to pursue it.

    [4] – You cannot prove a negative, and you cannot disprove a hypothesis. Further surprise, you’re also getting statistics today!

    [5] – And it’s DEFINITELY not freakin’ Page 0 Metrics.

    [6] – Told you, mopping is in your future and the future is now.

    [7] – Dear Operators: I am absolutely serious when I say that motivating people to maintain bin etiquette will be your biggest performance differentiator.

    [8] – Which was directly responsible for Supply Chain draining my desk rum.


    [9] – For those of you who missed it, yes really.

  • Why They’re Gross

    Likely my second-most career-limiting belief, right behind refusing to make the tools of war. This is the spicy one where I’m planting my flag because it goes to the very heart of how we treat and regard each other as human beings[1]. And while I’m not gonna die on this hill, somebody is.

    Let’s first define a humanoid robot. A robot has its functional safety system, the physical hardware, the controls software that commands its motions, and the decision-making software that chooses what functions it performs when. Placing these components in an anthropoid form factor with a head, torso, arms, and legs, makes it a humanoid robot[2].

    We’re surrounded by robots in our daily lives[3]. So what makes humanoids so icky?

    I’ve been loudly anti-humanoid and anti-pedalist[4] for over a decade, but it’s been from a functionality-first Technical Product perspective. Sure, backflips are cool! But, unless you’re a Savannah Banana, they don’t really accomplish much. I never got the “so what?”, and didn’t see them driving much in foundational technology progress such as energy management, servo development, or motion planning. They’re cool primarily because they’re built in the form of their maker, and we can imagine them as generalists because we are generalists ourselves. But that’s a technical answer which doesn’t address that ick factor underneath.

    Humanoids are a white-hot market full of solutions in search of problems. And yet, we’ve had an explosion of humanoid robots soaking up VC money and sometimes even hitting the market despite the absence of a specific problem to solve. They’ve been developed as technology-first initiatives with the hopes that a killer use case will reveal itself somewhere down the line. There’s no purpose, no vision, and no obvious path for how they’ll improve our lives.

    In the absence of that vision of improvement, the least imaginative amoral profiteers among us have happily stepped in to fill the gap. These wanna-be neo-feudalists[5] have no desire to improve processes or reimagine how work can be done better, faster, and with a lighter footprint. They just want cheaper labor doing exactly the same thing as before, just without all of that pesky complaining or lunch breaks.

    When you drive labor costs and labor rights to zero, you get chattel slavery.

    It’s the next song on the same album with such bangers as “Chatbot All The Things”, “A Spreadsheet Wrote This Article”, and “Literally All The Russian Psyop Videos”. Quarterly results-driven decision-makers have accepted the tradeoff of lower quality to reduce the number of human beings they employ without thinking through how these tools could instead truly transform their work. A quality product no longer enters the conversation, only the fastest path to your wallet. And both we and they are worse for it.

    The profiteers, the chattel slavers, and the neo-feudalists all assume a zero-sum game, and thus are racing to the bottom. Zero-sum games end in industrial commoditization and social dystopia because the players cannot imagine creating something larger than what they’re currently fighting over.

    THAT is why properly educated[6] citizens of free societies get the ickies from humanoid robots: unlike other robots, we sense that they have no other purpose than to devalue and commodify us. And our industry’s incredibly thoughtful and nuanced response to this existential threat is to “make it look less creepy”. This form factor, without function, is an insult.

    Great automation augments human labor rather than replacing it. We’re social animals by nature and will pack-bond with anything— anything[7]. We like making friends with stuff that joins the team alongside us and doesn’t supplant us.

    Humanoid robots can’t earn their place as part of our team until we figure out what they’re uniquely good at compared to a human being. It’s why you should immediately look upon any tele-operation training initiative with great suspicion: they’re not offering us anything new.

    So what are they good for? Humanoid robots are my bet for when we need somewhat bespoke behavior in somewhat bespoke tasks performing human-shaped work in situations that we shouldn’t be sending our fellow human beings. Let’s take that apart:

    • Somewhat bespoke behavior: a well-defined task that requires variation, but not innovation, within some well-defined boundaries. Picking up an object they’ve never seen before is a great example.
    • Somewhat bespoke tasks: Actions you won’t be performing frequently. If it’s the same rote task over and over again, you need an industrial engineer rather than a humanoid robot.
    • Human-shaped work: Here’s the dangerous one because it’s so easy to be lazy about it. Specifically human-shaped work requires a human to interface with it and it can’t be redesigned in time to accommodate other form factors. Emergency responses in legacy industrial plants with valves designed for human hands, for example. Packing warehouse orders, on the other hand, ain’t it, chief.
    • Situations that we shouldn’t be sending our fellow human beings into: If you need a specially trained human being to suit up to go in, there’s your answer. Burning buildings, confined spaces, extreme environments, nuke/bio/chem hazards, you’ve got the idea. It’s not a permission slip to design dangerous workplaces, it’s to address scenarios where you cannot design out the hazardous exposure.

    By analogy in the non-humanoid world, bomb defusers were some of the first robots to gain wide workplace acceptance and affection because they could fulfill most of these criteria. Exactly zero EOD specialists felt dehumanized by them.

    So if you truly want to make humanoid robots, do it right and start with your intention explicitly. “I want VCs to pay me to make humanoid robots do, um, stuff” invites the least principled in among us to take advantage of your work to profit from your fellow human beings in whatever way they can get away with.

    Be a human enabler, not a slaver.

    [1] – Look, this post is tagged as “Philosophy” for a reason. Buckle up, buttercup.
    [2] – No, Brad, that’s not a humanoid. You’ve overshot clickbait straight into cringe.
    [3] – See A Dishwasher Is A Robot.
    [4] – I’ve got a whole rant about the utility of the human foot and it is 100% not a weird Quentin Tarantino-type thing.
    [5] – If this characterization offends you, kindly go fuck yourself. You are, in fact, the baddies.
    [6] – Ignore the parchments on the wall; auto-didacts are welcome in this home. Classically speaking, a person who has cultivated the cognitive skills and tools to participate in a liberal democracy. Curiously, liberal arts are the disciplines most denigrated by neo-feudalists who deem them dangerous to their objectives.
    [7] – Once again, see the ever-growing body of work on “Captain Stabby”.

  • A Dishwasher Is A Robot

    One of my favorite ways to troll roboticists is to claim, very loudly, that “a dishwasher is a robot”. It’s a great litmus test for how a given person will see the industry because it uncovers an uncomfortable taxonomic void that we haven’t yet resolved as a people.

    Let me start by explaining how a dishwasher is, by many definitions, a robot. ISO 8373 tells us that a robot is generally a “programmed actuated mechanism with a degree of autonomy to perform locomotion, manipulation, or positioning”. Well, looking at my dishwasher at home, we’ve got:

    • Programmed – I can select various modes that I’d like the dishwasher to run in. I have cats and a husband, so my dishwasher generally stays in “heavy / extra hot”. My dad’s has a cycle gentle enough to run Grandma Mae’s gilded china in.
    • Actuated mechanism(s) – Water pumps, heating elements, fans, sprayers, there’s lots of actuated components here.
    • Degree of autonomy – I can set it and forget it. My dishwasher can operate without me and make decisions to heat water, to what temperature, when to release soap, when the dishes are sufficiently rinsed, and so on.
    • Performs manipulation – The systems out there these days are amazing. Complex multi-jet arms, spinning discs, adaptive sprayers, smart soap release mechanisms… it’s a whole thing.

    Add on the subclass of a service robot, defined as performing useful tasks for humans or equipment in personal or professional use (eg, “cleaning”), and we’ve nailed it.

    So why don’t we think of our dishwashers this way? Or our refrigerators, laundry machines, or an entire building?

    Because they became so familiar that we only notice them when they’re missing. Dishwashers ceased being seen as robots the moment people stopped calling over their neighbors to marvel at the new technological doodad they purchased and started getting annoyed when their apartments didn’t include them. It’s the best destiny of any technology: to become invisible, reliable infrastructure. Robots become appliances the moment they achieve ubiquity.

    And here’s how you know that a technology has achieved ubiquity: we build around it. Kitchen designs accommodate fridges, stoves, dishwashers, and now microwaves with dedicated spaces and utilities. Your home has heating and cooling infrastructure threaded throughout in the forms of sensors, ducts, compressors, humidifiers, and heaters. And we’ve flattened neighborhoods, carved tunnels, and created elaborate fueling networks for the automobile. By our own definition our homes, neighborhoods, and cities are robots we’ve never bothered to name.

    Which extends the original definition into meaninglessness, if we were to rely solely on a technical definition. By pushing the assumed boundary to the extreme, we’ve uncovered the real divide that angers roboticists worldwide: conflating the technical work of the word “robot” with the cultural work it’s doing. Technically, a dishwasher is indeed a robot. But culturally, it’s an appliance.

    A technical definition provides a model of what a thing could be classified as for the purposes of figuring out which rules ought to apply to it. Straightforward, simple, and entirely useless for the cultural work that a word needs to do. As human beings, we use the word robot colloquially as an othering term for new technologies. These othered technologies are new, strange, scary, and threatening, here to take your place in society and knock you down a few rungs economically and socially. Once the othered technologies become familiar, and we see that they’re net benefits and not the destroyers that we thought they were[1], they earn names of their own.

    So take a look at what we still call robots: they’re strange new worlds of technology, early in their journeys within our societies. Roombas are mid-journey: familiar and approachable enough that they’ve begun to be anthropomorphized with names, attributed personalities, and even microfic[2]. Dishwashers have completed their journey to ubiquity as appliances.

    All great robots eventually take their place as a named appliance. Dishwashers just got there first.

    [1] – Of course, excluding when such “others” are used as socioeconomic weapons, but that’s a discussion for another time.
    [2] – See the ever-growing body of work on “Captain Stabby”.

  • Tina’s Maxims

    Tina’s Maxims

    This post was adapted and updated from my original posted on Medium.com in 2022.

    I’d like to share the maxims I have developed over the years to guide my professional approach. (I’m not sure my colleagues would dare label any of my approaches as “professional”, but I digress.) These probably each deserve their own essay at some point but I figure you could at least use a little taste, as some sort of perverse corporate treat.

    I use a simplified bullet journal at work. It’s my external brain for notes, to-do’s, and information I want to keep at my fingertips. Among those are a set of maxims I’ve developed. While some pages in my notebook have been cut and reinserted into successive books over the years, the Maxims page is one I always rewrite by hand. It’s a great opportunity for wordsmithing and measuring whether the maxim is still valuable.

    Maxims describe fundamental principles of behavior. They’re different from tenets, which, when used correctly, provide a fulcrum for decision-making. Both are difficult to write, and both must be continuously revisited, revised, and maintained.

    There’s no ordinality here beyond order of initial development. A couple are similar in nature. All are irreverent and not intended for shiny, slick slide decks about How To Product.

    Tina’s Maxims (as of mid-2026)

    1. Averages of averages are Satan’s butthole.
    2. Achievable != sustainable.
      • Possible != feasible.
    3. All band-aids immediately operationalize.
    4. Does it scale? Up and down?
    5. People will misuse your products in ways you cannot possibly imagine.
    6. Design like your users are drunk.
    7. Document like you’ll get hit by a bus.
    8. Slow is smooth. Smooth is fast.
    9. Killing a bad feature is at least as valuable as launching a good one.
    10. WRITE. SHIT. DOWN.
    11. Don’t leave money on the table.
    12. All models are wrong. Some are useful.
    13. In optimization models, only Sith deal in absolutes.
    14. Fear is the mindkiller. Anxiety is its kissing cousin.
    15. Perfect is the enemy of good.
    16. ALWAYS FIGHT BULLIES.
    17. “Not looking stupid” is a feature.
    18. Assholes are rarely assholes in only one dimension.
    19. You cannot optimize a system you do not understand.
    20. Do not confuse motion for progress.
    21. With enough money, anything is retrofittable.