The Most Expensive Engineer in Robotics Is Excel
On the unkillable spreadsheet quietly running every robotics company.
Every robotics company has a hiring plan. ML engineers, robotics engineers, perception specialists, controls engineers, simulation engineers, embedded developers, DevOps, safety engineers, and lately, a foundation model researcher or two. One role never makes the list, and somehow it ends up making more product decisions than everyone else on that list combined: Excel.
The industry likes to imagine itself as a cathedral of sophisticated software. Conference talks are full of transformer architectures, diffusion policies, world models, RL, CUDA kernels, trillion-parameter ambitions. The demos look futuristic, and investors nod along to slides full of arrows connecting GPUs to robots. Behind all of it, though, sits the actual mission-critical dependency: a spreadsheet nobody wants to admit exists. Not version controlled. No clear owner. Half the formulas quietly broken. And somehow it’s the only place that maps dataset names to robot IDs to calibration sessions to bag files to eval results to customer demos - plus whatever “run_237_final” was supposed to mean. Delete the training code and someone rebuilds it from Git history by tomorrow afternoon. Delete that spreadsheet and the company loses three months of institutional memory.
Every robotics startup starts with the same beautiful principles. Clean pipelines. Reproducibility. Metadata first. Automation over manual work. Then the first customer demo shows up on the calendar, and someone exports a CSV in a hurry. Someone else copies it into Excel “just temporarily.” A few cells get colored green for no reason anyone could explain later. A new tab appears. A manager duplicates the file because they’re scared of overwriting the original, and now there are two versions. A week later, seven. A month later, twenty-three, living in a folder called Data Organization, which itself contains Data Organization Final, Data Organization Final 2, Data Organization Final New, Data Organization Final Latest, and - inevitably - Data Organization Final Latest Updated Copy. Nobody knows which one production actually depends on. Everyone acts like they do.
Robotics companies like to say they’re building autonomous systems, and technically, they are - the spreadsheets got there first. Nobody remembers creating them. Nobody fully understands how they work anymore. Everyone is a little afraid to touch them, because changing one hidden column somehow breaks the eval dashboard three layers away. At some point the spreadsheet stopped being a tool and started having agency of its own.
If you’ve spent any real time in robotics, you’ve sat through a version of this exchange: Where did this dataset come from? I think Rahul collected it. No, Rahul says it was Ankit. Ankit left last year. What robot was it? I think Robot 5. There were two Robot 5s. Was this before or after the camera recalibration? Nobody investigates further. Someone just renames the file Robot5_NEW_FIXED and the meeting moves on.
We joke that machine learning models are black boxes. The data pipeline is usually darker. Ask a robotics company about its transformer and you’ll get eight attention heads, flash attention, rotary embeddings, mixed precision, gradient checkpointing - a beautifully specific answer. Ask where a particular demonstration came from and you get silence, followed eventually by “I think it’s in Dropbox somewhere.”
Version control is its own subplot. Software engineers have Git. Data engineers have object stores, more or less. Robotics engineers mostly have hope. Two people editing the same spreadsheet at once effectively forks reality - both versions keep existing, neither gets deleted, and months later someone discovers the production model was trained on the wrong branch of Microsoft Excel.
Calibration deserves its own paragraph of shame. Every team insists calibration is automated, by which they usually mean a guy named Akash knows how to do it. If Akash goes on vacation, the robots briefly become philosophical objects instead of physical ones, and people gather around a whiteboard trying to remember whether the LiDAR transform lives in YAML, JSON, or “that spreadsheet.” Someone eventually finds Calibration_v8_REAL_FINAL_USE_THIS.xlsx, and nobody asks the obvious question about why camera extrinsics live in Excel. Everyone just accepts it and moves on.
Evaluation follows the same script. A dashboard proudly reports Success Rate: 94.7%. Compared to what, exactly? Nobody’s quite sure - the baseline model got overwritten at some point, the validation split has drifted, a few “outlier” scenarios got quietly dropped because they made the number look worse, and someone renamed three metrics last quarter because the old names were confusing. The graph goes up regardless. Everyone celebrates scientific progress.
The most expensive meetings in robotics aren’t architecture reviews - they’re archaeology expeditions. Ten engineers trying to answer questions that should take thirty seconds: which dataset produced this model, which controller was active, was this before or after the encoder swap, did we retrain after the sync fix, why are there three folders called “Production,” who created “Production New,” and why is “Production Old” somehow the newest one of all. Nobody writes a line of code in these meetings. Everyone just digs.
People tend to underestimate what this actually costs. GPU bills show up as invoices. Cloud storage shows up as invoices. Salaries show up on payroll. Spreadsheet chaos shows up nowhere on any statement, and yet it quietly eats weeks - duplicate experiments, repeated data collection, wrong conclusions drawn with total confidence, customer demos run on outdated models, failed reproductions, entire investigations launched because a CSV column shifted by one index six months ago. It never appears on the balance sheet. It just invoices you slowly, in engineering time.
There’s a real irony in a team spending three weeks shaving 12 milliseconds off inference latency and then losing two full days because nobody can say for certain which demo corresponds to kitchen_pickup_good_new_latest_fixed2. Optimization is addictive because benchmarks reward it publicly. Organization stays invisible because nobody has ever tweeted about a metadata schema.
This might be part of why robotics feels slower than software in general. Software engineers mostly debug code. Robotics engineers debug reality - sensors, actuators, physics, synchronization, calibration, networking, human operators, damaged hardware, mislabeled data, missing timestamps, and yes, spreadsheets pretending to be databases. Every missing piece compounds with the others, until the hardest problem in the building isn’t intelligence at all. It’s just remembering what happened last Tuesday.
There’s a familiar stage every robotics startup hits eventually, where the spreadsheet has become so load-bearing that nobody dares touch it. People start discussing a proper data platform. Roadmaps get written. Infrastructure proposals get approved in a planning meeting somewhere. Six months later, a new column shows up in Excel anyway, because it was faster for now. Temporary systems, it turns out, have remarkable survival instincts.
The industry loves to argue about whether scaling laws, RL, synthetic data, or foundation models are what finally unlocks general-purpose robots. Those debates matter. But they also distract from a less glamorous truth: most robotics companies aren’t actually limited by intelligence. They’re limited by memory - not GPU memory, organizational memory. The plain ability to answer simple questions with confidence. Where did this data come from. What changed. Why did performance regress. Can we even reproduce this result. Until those have reliable answers, every new model gets built on ground that’s a little less solid than anyone’s admitting.
So next time someone tells you their stack runs on CUDA, PyTorch, ROS, and diffusion policies - smile, because it probably does. Just know that somewhere underneath all of it sits a file named final_v3_latest_FIXED_USE_THIS_ONE(3).xlsx. Nobody owns it. Nobody trusts it. Nobody can delete it. And somehow, it’s still the highest-impact engineer at the company.
We were guilty of this at Minus Zero too, until late we started making it more reliable.
Till then, share and subscribe for more anecdotes while building in physical AI space.