Robot Girl Gang

Category: Product Management

  • 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.

  • Commodification: The Race To Zero

    Steve Crowe of The Robot Report has been following Teradyne’s adventures in IP protection this year, most recently noting their second foray into court against the Chinese cobot manufacturer JAKA. Our bickering over parking and their absolute domination of my colleagues in the neighborhood basketball tournament aside, I’ve got mad respect for them. Teradyne has been a force in the automation industry: they make some of the best automated electronics test products in the world, and their Universal Robots line appears regularly in our own workcells. So naturally, when I see Steve covering Teradyne, I lean over the fence for the neighborhood gossip. But when he asks, “is this simply what happens when an industry matures?” it finally knocked loose some observations that have been rolling around in my own head for some time.

    In a word: yes. This is a sign of industry maturity but for a more dreadful reason: it’s a warning sign of commoditization.

    Let me step us back for a moment and talk about some finance bro stuff. You may have heard finance bros and VCs talking almost fetishistically about “alpha”, without ever mentioning “beta”. Here’s some quick definitions:

    • Beta: Your commodity baseline, what any competent manufacturer can produce. A 6-axis cobot is as a 6-axis cobot does. Baseball terms would put this as your replacement-level player: one who can be called up that performs at the minimum standard for minimum cost.
    • Alpha: Your excess value above baseline, the stuff that makes your product stand out and seem more attractive than that Beta baseline. Could be the integration, the ecosystem, the system design, the deployment experience, the support quality… anything that justifies your charging a premium for your product over the functionally equivalent alternative. This is a baseball player with a positive WAR[1].

    Alpha constantly erodes due to technology and manufacturing advances, greater knowledge in the market about how to solve problems, rising customer expectations, and other pressures. Last year’s alpha becomes this year’s beta. Bluetooth was once a premium feature, high alpha; now it’s table stakes, strongly beta. This natural erosion is called “alpha compression”, and it’s a race to zero as the alpha continually dissolves away towards nothing.

    To bring it back, commoditization occurs when your alpha evaporates. That unique thing that you brought to the market isn’t so special any more.

    Now, commoditization is not a universal evil. We need commodities, both virtual and physical. The entire Open Source Software movement is a response to the need for commoditized software. If I needed to find a “special” machine screw for every application I would lose my mind.

    But commoditization requires a radical shift in your operating model: driving towards massive scale, absolutely relentless cost efficiency, and volume is your only lever. You can do that in high tech: Kingston’s our reigning champion of massive scale and reliability in the memory module market. However, when you lose your alpha before you can transition to your commoditized operating model you’ll get ground under by competitors who can race to the bottom faster than you, just like the photovoltaic industry did[2].

    So how do we diagnose commoditization, and how do we grade it?

    First off, we need to recognize that companies all use market barriers to protect themselves. Some barriers, such as intellectual property instruments like patents and copyrights, can be virtuous: governments recognize that reasonably-sized paths towards extended alpha stimulate investments in creativity that benefit society as a whole. The problems happen when companies use these barriers to the exclusion of other alpha-creating activities such as R&D investment[3].

    Commoditization has three major stages.

    • Early stage: Ecosystem lock-ins as substitutes for genuine product improvement. John Deere’s war against Right-To-Repair provides a perfect example of weaponizing the pain of switching to a new vendor to guarantee market exclusivity. John Deere still has plenty of alpha to exploit but they’ve instead chosen the lazy path that doesn’t require creativity or risk.
    • Mid stage: Regulatory capture, standards manipulation, all that devious stuff that effectively writes out anyone else from being allowed to compete in the first place. AT&T has committed many sins, but the best example of mid-stage commoditization was AT&T’s history of abusing their monopoly position to prevent third party devices from being attached to their phone lines. That meant no answering machines, fax machines, dial-up modems, or assistive devices not produced and sold by AT&T themselves. Once the FCC finally lifted this restriction in 1968, telecommunications devices exploded and AT&T sold more phone lines than ever per capita, going from 414 lines per 1,000 people in 1960 to 796 lines per 1,000 people in 1980[4]. AT&T played themselves by trying to control alpha when they should have focused on their beta.
    • Late stage: The final argument of every petty asshole with nothing else left to offer: “I’ll sue you!” It’s ugly, it’s expensive, it’s messily public. Sometimes you have to go there; for example, trademarks require aggressive protective measures in order to maintain them, such as Patagonia’s uncomfortable infringement lawsuit against Pattie Gonia[5]. On the other end of the spectrum you find patent trolls like SCO, who never had alpha and honestly have no beta left either. Perhaps they only have rho. Most IP protection lawsuits land somewhere in between, like Teradyne’s, where there’s legitimate beef on patent infringement but that’s the only thing they’ve got left in the competition space.

    So using that guide, let’s track the progression of the disease for Teradyne’s Universal Robots. In The Beginning, UR created the Cobot, and saw that it was good. PolyScope kicks ass, arms are stupid easy to replace in the field, real safety co-existence. As time goes on, switching to other companies’ products generates its own kind of lock-in and collaborative safety standards continue to provide a considerable buffer. Then, Chinese manufacturers manage to close the hardware gap, not only collapsing UR’s alpha but compressing their beta as well. Teradyne’s now suddenly in a fight for their lives because the hardware should never have been their wooden walls safeguarding their city[6].

    Commoditization comes for all markets, and one that’s probably most tactile on an everyday basis is the personal computing market. Most PC makers are optimizing their beta: Dell, HP, Lenovo. They assemble laptops and desktops from roughly interchangeable components that fade into the background compared to the price and spec sheet and whether you can remove the stupid “register your Windows license” watermark. My personal spite for modern HP products aside[7], you won’t generally find a user who ride-or-dies their Dell Latitude. The Fruit Company on the other hand, can only survive by maintaining their alpha. Sure, Apple maintains a hefty IP portfolio but they earn their market loyalty through tight component integration and great software-hardware co-design, even in the Intel Mac days when they were running the same processors as their beta compatriots. When they rolled out Apple Silicon, they then added hardware differentiation back on top of that already fat alpha.

    Coulda, woulda, shoulda. Teradyne’s now in a bind. They might still be able to dig it out and find alpha in PolyScope’s UX, in creating an App Store equivalent for robots with the UR+ ecosystem, or in building an authorized reseller army from their integrator network. Can they turn it around like Apple did in the 2000s, or do they fight for pennies like a Dell or Lenovo?

    It’s entirely possible, and even feasible. Teradyne in general and Universal Robots specifically have great people (even though they slow to 3mph for 15mph speed bumps, wtf). It’ll take creativity, a little bit of risk taking, and a willingness to experiment. No need for a moonshot here, just some cleverness and the space to implement it. But IP protection, including their lawsuit, doesn’t buy you alpha, it just buys you time. The race to zero won’t stop for a court date.

    [1] – Wins Above Replacement. Basically, how much more the player contributed to winning a game than your baseline player would. The Sabermetrics people get way too nerdy about this way too quickly, but Wikipedia’s got a decent explainer for us mere mortals.
    [2] – No one’s pockets are as deep as companies backed by state-sponsored capitalism.
    [3] – Pharmaceuticals are an entire problem with this unto themselves.
    [4] – Munged together from US Census data and the FCC’s Statistics of Communications Common Carriers.
    [5] – Suing her for $1, because that’s the minimum to demonstrate they’re protecting their trademark.
    [6] – Oh I’m sorry, we’re going to use Greek letters and I’m not going to slip some classical history in? Pulled a fast one on you.
    [7] – The last great HP product was the LaserJet 4 with the Jetdirect Print Server card and I will not be accepting questions. That absolute unit lasted for two decades after I tactically acquired it.

  • 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.