You'll own a $1.5–2M growth budget and an existing content engine. Your job is to turn that into a scalable, repeatable revenue machine.
Anvil is building the platform layer for Physical AI — robotics hardware and software that's radically more accessible than legacy industrial solutions. The growth story here is the kind marketers usually have to invent: we started on a $1M pre-seed, were shipping hardware to NVIDIA and Cobot within months, and closed our full seed six months later — $7M raised in total. In our first 12 months we did over $2.1M in revenue at 40–50% gross margins, and we reinvest that margin directly into growth.
The product-market fit signals are specific and unusually strong. Founders buy us themselves — the CEO of Formic, the CTO of The Bot Company, the CEO of Zordi, and the co-founders of Flexion, Senra, and Haply all placed orders personally. The researchers who define robot learning buy us on their own cards. When YC funds a robotics company, buying Anvil has become the default first step, and ITRI — Taiwan's national research institute — has come back six separate times. Demand runs from F100 (NVIDIA, Qualcomm, Toyota, Google) to pre-seed, across 60+ countries, with no single account the business depends on. And all of it happened with founders doing marketing part-time.
We're not asking you to bootstrap a growth function from nothing, and you won't have to manufacture a story — the logos, the repeat buyers, and the customer content already exist, and gross margin is your budget. We're asking you to take real capital, real traction, and real assets and scale them intelligently — fast.
The situation you're walking into:
Average order value is ~$13,000. This is not an impulse purchase — but our price point is dramatically lower than legacy robotics competitors, low enough that most of our customers buy without a formal PO or procurement cycle. That's a structural advantage. We need someone who understands exactly why that matters and builds the funnel around it.
We already have a strong content production engine — video, written, and a growing library of user-generated content from real customers running our robots. You won't be building this from scratch. You'll be directing it, deciding what gets made and where it goes.
Gross margin is your growth budget. We treat marketing spend — paid ads, swag, gifting, events — as a lever to pull harder as revenue grows, not a cost to minimize. If you can show us the funnel math works, we will fund you well beyond a typical seed-stage marketing budget.
What you'll own:
Full go-to-market: LinkedIn, X, Email, and Google Ads, run as one system feeding one pipeline — not disconnected channels
Funnel construction and instrumentation: mapping awareness → consideration → close with real conversion data, understanding where our no-PO, high-ACV buying motion breaks from typical B2B assumptions
Capital allocation: deploying a growth budget in the hundreds of thousands of dollars per quarter, deciding the mix across paid media, content production, events, and gifting/swag, and proving out what's working
Content direction: you won't need to pick up a camera yourself, but you will decide what stories get told, what gets filmed, how customer UGC gets sourced and used, and how it gets distributed across channels
Team: you may bring on 1–2 contractors or part-time specialists to support execution as winning motions emerge, but the majority of your time and budget goes toward directly driving traffic, demand, and sales — not building an org chart
What the first 100 days look like:
By day 30: every channel and asset is instrumented and tracked — you have a real baseline, not vibes.
By day 60: you've formed hypotheses on which channels will work for us and have live experiments running against them, with data coming back.
By day 100: you're already contributing measurably to pipeline, and you deeply understand our customer — how they decide, where their budget comes from, why they buy from us instead of the incumbents — from data and from talking to buyers and non-buyers directly.
We move fast here. If that excites you more than it worries you, keep reading.
Who you are:
You think in funnels and unit economics by default. You can build a CAC/payback model from scratch and you know the difference between content that drives engagement and content that drives pipeline.
You've deployed real marketing budget before — ideally $500K+ annually — and you can speak specifically to how you allocated it and how efficiency held (or didn't) as spend scaled.
You've sold, or marketed, to a technical buyer. Our customers are engineers. Every piece of content — video, ad copy, landing pages — needs to hold up to technical scrutiny. If you can't tell the difference between a spec sheet and marketing fluff, this isn't the role.
You've run paid acquisition (Google Ads at minimum) and organic/content simultaneously, and you think of them as one system, not separate disciplines.
You've found and scaled a channel before — you know what it takes to go from an unproven hypothesis to a repeatable, budget-worthy motion, quickly.
Bonus: background in robotics, hardware, industrial automation, or another deeply technical B2B category with a considered-but-fast purchase cycle.
Education & experience:
You do NOT need to have held a \"Head of Marketing\" title before. Our ideal candidate has typically spent 4–6 years in growth/demand-gen marketing — or 2–3 unusually fast-growing ones — with the most recent stretch as the trusted right hand to a strong VP/CMO: running the budget, the channels, and the reporting while someone else held the title. You've seen how the top seat operates up close, absorbed the judgment, and are ready to take the wheel for the first time.
Bachelor's degree or an equivalent practical track record. No advanced degree required — we weight demonstrated funnel ownership and growth trajectory over credentials.
What this role is not:
Not a brand marketing role. We care about pipeline and revenue, not awareness for its own sake.
Not a \"hire an agency and manage it\" role. We want someone who directs the work closely and has an opinion on every asset.
Not a 0-budget scrappy growth-hacking role. You'll have real capital. We need someone who knows how to deploy it responsibly and prove it's working fast — not just someone who's good at doing more with less, and not someone who needs a year to figure out where to start.
You'll be the person who takes Anvil's next robot from a sketch of what it should do to a physical machine that ships at scale.
Anvil is building the platform layer for Physical AI — robotics hardware and software that's radically more accessible and suitable for a new generation of intelligent automation than legacy industrial solutions.
We own and operate our own manufacturing. Sourcing and production were built in-house from scratch, and in our first 12 months, on that line, we built and shipped 200+ robots (OpenARM and OpenYAM manipulators, paired with a custom Linux Devbox, and teleop kits, cameras, and end effectors) to customers like NVIDIA, Qualcomm, Toyota, Google, Cobot, and Path Robotics in 60+ countries, while we grew from two founders to 30 people across three offices. Very few robotics companies at any stage can say that. Almost none can this early.
The devkits we ship are the wedge, not the business. Volume has earned us what money alone can't buy: a custom force-sensing actuator partnership with major actuator OEMs, meaning our next robots ship with hardware capability nobody else has — and an install base that doubles as the distribution channel. That's the strategy: aggregate volume → supply chain partners → unique long term advantage.
The next step is a bigger one: a bimanual robot platform — a completely new kinematic, built from the ground up around our custom force-sensing actuators — that has to work as a production deployable product manufacturable at scale.
The situation you're walking into:
Anvil has real hardware DNA — the devkit class hardware line already ships to customers — but no one is yet owning the next generation deployment ready platform, from concept through mass production.
This is not a revision of the OpenARM line. The new robot is a clean-sheet design — new kinematics, designed from scratch — and the first product built around our custom force-sensing actuators.
We're deliberately going firmware-light for this generation: compute is a full Linux Jetson on a carrier board with EtherCAT out to the actuators, so at most there are a few simple boards to design. The engineering weight is mostly mechanical, with EE that's light and straightforward — power distribution, connector hubs, harnessing.
You'll work daily alongside mechanical and electrical engineers, plus our in-house production team and component vendors, but you won't be their formal manager. Anvil is small enough that this role is about technical direction and judgment, not headcount.
You'll report to a mix of the CEO and CTO — practically, mostly the CEO, who sits in Taipei next to the rest of the hardware team day to day.
What you'll own:
The technical vision and system level architecture for Anvil's next robot: what it's made of, how it moves, how its subassemblies fit together, and how the wiring runs through all of it.
Translating kinematic and product requirements into a physical, buildable machine — material choices, actuation approach, subassembly breakdown — not just a concept sketch.
Manufacturability from day one: making the tolerance and process calls that determine whether this robot can go from one prototype to hundreds of units without a redesign.
Guiding the work of mechanical and electrical engineers and vendors so their pieces come together into one working robot, even though you won't personally do all of their deep technical work.
Direct ownership of DFM, tooling, and production readiness on Anvil's own manufacturing line in Taipei, and direct engagement with the component vendors (sheet metal, CNC, motors, electronics) who feed it.
What the first 100 days look like:
By day 30: ramped on OpenARM/OpenYAM's design history and lessons learned, the force-sensing actuator program, and the in-house Taipei production line and vendor relationships. Teardown of existing competitor products who have shipped in volume to learn from their designs. Has been on-site in Taipei for the program kickoff, sat in on at least one build, and reviewed all of Anvil's current vendors and understand their strengths, weaknesses, tolerances, and pricing.
By day 60: has a first pass system architecture for the new bimanual robot — kinematics, actuation approach built around the custom force-sensing planetary actuator, major subassemblies — pressure-tested against what our production line and vendors can actually build.
By day 100: is driving the new robot's system architecture end to end, with mechanical and electrical engineers executing against a plan you set. Is the person others check manufacturability and cross domain tradeoff calls with.
Who you are:
You've designed physical hardware that went from a concept to something manufactured at real volume — you understand materials, actuation, and subassembly design well enough to make the calls yourself, not hand them off.
You think about manufacturability and mass production from the first sketch: tolerance stacks, vendor capability, assembly sequencing, and what breaks when you go from one unit to a hundred.
You don't need to be an expert in PCB design, motors, reliability testing, or structural engineering, but you can think laterally across all of them — enough to know when something's wrong, ask the right question, and make a defensible call at the boundary between mechanical and everything else.
You have genuine, provable depth in at least one or two of PCB/electronics design, actuation and motor systems, reliability engineering and accelerated life testing, or structural and materials engineering — beyond just being conversant in it.
You're comfortable driving technical direction across engineers and vendors you don't formally manage, earning the \"lead\" in your title through judgment rather than authority.
You default to a design that can actually be built and shipped, not the most elegant one on paper.
You don't need to relocate — this role can be remote. But hardware gets real in person, and you'll travel to Taipei for the on-sites that anchor each program: major project kickoffs, initial system bring-up, and first production batches. We run those deliberately — they're what lets the rest of the work be remote.
Education & experience:
Bachelor's or Master's in mechanical engineering, mechatronics, or a related field. A PhD is not required — this is a build it and ship it role, not a research role.
Years matter less to us than trajectory. A typical req for a role like this might ask for 8–10+ years and prior \"Head of Hardware\" experience; we're looking for someone with 4–6 unusually fast growing years spent as the strong #2 to a senior hardware leader on a real, shipped robotics or hardware product — someone who watched how the materials, actuation, and manufacturability calls actually got made, made a growing share of them personally, but never had the whole program handed to them. This is that handoff.
What this role is not:
Not a people management role. There are no direct reports today, and building a management org is not the mandate — this is a hands on technical ownership role.
Not a role where you personally design the PCBs, tune every motor controller, or write the perception stack. Those are owned by specialist engineers; your job is system level judgment and integration across their work, plus genuine depth in one or two of those areas.
Not a role for someone who's only ever designed hardware that stayed a prototype. If you've never taken something through a real manufacturing ramp, this isn't the right seat yet.
Not a role with an existing DFM/manufacturing playbook to inherit for the new robot — where it doesn't exist, you're building it.
You'll be Anvil's first robot learning hire — the person who takes the papers everyone is retweeting, gets them running on our hardware in weeks, and ships them as demos and guides polished enough that the whole field notices.
Anvil is building the platform layer for Physical AI — robotics hardware and software that's radically more accessible than legacy industrial solutions. In our first 12 months we built and shipped 200+ robots (OpenARM and OpenYAM manipulators, Linux Devboxes, teleop kits, and a UMI-style handheld data-collection device) to customers in 60+ countries, doing over $2.1M in revenue on our own Taipei manufacturing line.
And here's what makes this seat unusual: not how much data we have — how much leverage you'd have over what gets collected. Most robot learning engineers work with whatever data someone else decided to collect, on rigs they can't change. Here, the entire collection system bends to your judgment — and there's a factory behind it. We design and build our own UMI-style handheld collector in-house, on our own Taipei manufacturing line, sitting inside the Asia supply chain: if the data would be better with a different camera, a different mount, a new sync scheme, or a custom fixture that doesn't exist yet, you prescribe it and it gets built — in weeks, not procurement quarters. We have factory access most teams can't get — our own facility and our investors' and partners' plants — meaning differentiated, real-industrial-task data rather than the same recycled public datasets. And we have people who can do the collection work if you write the protocol: you prescribe what good data looks like, they collect it. Let's be honest about scale, because it matters: this is not a foundation-model data operation, and we're not pretending it is. It's the setup to reach LeRobot-shirt-folding scale — hundreds of high-quality demonstrations of the right task, on tooling shaped to your spec — with more control and less friction than almost anyone in the field gets.
The situation you're walking into:
We have 200+ robots in the field and zero dedicated ML function. Model training happens in the gaps between the founders' and controls engineers' actual jobs. You are hire #1 for the entire robot learning function, and for the foreseeable future the team is you.
We ship a UMI-style handheld data-collection device — and nobody has yet closed the loop of training a policy purely from its data and running it on our arms. Validating that pipeline end to end is a product decision waiting on you, and it's one of your first deliverables.
Robot learning is compounding weekly — VLAs, diffusion policies, ACT, world models. At our stage the highest-leverage move is not novel research; it's replicating the best public work on our hardware fast, and publishing it. Think the LeRobot shirt-folding project — data to deployment, in the open — running on Anvil arms, with our name on the guide.
Demos are not vanity here. A flagship replication is simultaneously marketing to the exact community that buys us and the enablement guide our customers follow. Which means the last 10% — the clean repo, the honest success rates, the written guide, the good video — is where most of the value lives. We need a builder with a real knack for polish before calling a project done.
The collection system above is built but undirected. The UMI exists and can be revised to your spec, the operators exist, the factory access exists — but nobody with ML judgment decides what to collect, how, and what \"good\" looks like. The leverage is sitting there; the person who prescribes it doesn't exist yet.
What you'll own:
Training pipelines, end to end: teleop and UMI data ingestion, dataset formats and quality triage, training jobs, and an eval harness with honest success-rate protocols — built so that eventually someone who isn't you can train a model.
Paper replication → published demos: picking the highest-leverage public work (folding-class manipulation, VLA fine-tunes, diffusion policies), getting it running on Anvil hardware in weeks, and shipping it as a public demo video + reproducible guide.
UMI pipeline validation: being the person who proves — or fixes — the path from our handheld data collector to a working policy on an OpenARM. The UMI is built in-house, so your findings don't end as feedback — they become hardware revisions you prescribe.
The data flywheel: DAgger / human-in-the-loop correction workflows on our teleop stack, so policies improve from intervention data instead of plateauing after the first training run — and, as your protocols mature, scaling collection beyond yourself: designing what dedicated data-collection operators record in our factory and, over time, in partner facilities.
The polish bar: nothing you ship stops at \"works on my machine.\" Every project ends with the video, the guide, and the repo someone else can run.
What the first 100 days look like:
By day 30: your rig is set up, and a first policy (ACT or Diffusion Policy class) trained on Anvil-collected data is running on real hardware. You have a written map of where our stack fights you.
By day 60: the UMI pipeline is validated end to end — a policy trained purely from handheld-collected data, running on an OpenARM — with a clear-eyed writeup of what's broken in the pipeline and what to fix.
By day 100: your first flagship replication (folding-class) is live on Anvil hardware and published — demo video, honest success rates, reproducible guide.
Who you are:
You've personally trained and deployed imitation-learning policies — ACT, Diffusion Policy, VLA fine-tunes — on real robot arms. Not cloud benchmarks: real motors, real cameras, real failures.
You're fluent in the layer under the model, because that's where deployments die: action chunking and temporal ensembling, inference latency versus control-loop frequency, camera synchronization and timestamp alignment, joint-space versus cartesian command interfaces.
You replicate papers in weeks. Given a paper and a repo, you know what will transfer, what won't, and where the unreported gotchas hide.
You have data instincts: you can scrub through teleop demonstrations and see what's wrong — inconsistent grasps, occlusions, timing skew — before wasting a training run on it.
You're a finisher. Your projects end with a guide, a video, and a repo with a README — and you know the difference between a demo that worked once on camera and one with a measured success rate you'd defend.
You're honest about results. You report n, the eval protocol, and the failure modes — especially in public.
You're comfortable being the only ML person in a fast, lean, founder-led company, setting your own agenda and shipping on a weeks-not-quarters cadence.
Bonus: LeRobot or similar open-source contributions; DAgger / interactive imitation learning experience; public demos that got real reach; RL fine-tuning on real hardware.
Based in or willing to relocate to San Francisco, Hong Kong, or Taipei. This role needs to sit with robots, cameras, and a GPU box, wherever that is — Taipei puts you next to the hardware team, SF next to the demo room and customers. Flexible hours for cross-timezone collaboration either way.
Education & experience:
Master's or Bachelor's in CS, robotics, or a related field — a PhD is explicitly not required or expected, and a publication record is not the bar. Your portfolio is: policies you personally trained running on real hardware, with the repos and videos to prove it.
Years matter less to us than trajectory. A typical req for a \"Head of Robot Learning\" would ask for a PhD plus 5–8 years; we're looking for 2–4 unusually fast-growing years — or 1–2 on a steep curve — spent as the research engineer beside a strong robot learning lead: the person who made the lab's or team's work actually run on hardware, closed a growing share of the hard problems personally, but never owned the direction because someone above them did. This role is the first time the wheel is yours.
What this role is not:
Not a research role. No publication mandate, no novel architectures for their own sake. You're making the frontier run on our hardware, not extending it.
Not a cloud ML role. If your experience is training and eval with no physical robot in the loop, this isn't the seat.
Not a management seat. \"Head of\" means you own the function; the team is you, possibly for a year or more.
Not a solutions-architect role. The deliverable is never a plan or a memo — it's a policy running on an arm and the published artifact around it.
Not a role for 90%-done builders. If your projects historically end at \"it worked, moving on\" — before the writeup, the video, the reproducible repo — our polish bar will chafe daily.
You'll be the person who catches the gap between the CAD file and the part that showed up on the factory floor — and gets it fixed.
Anvil is building the platform layer for Physical AI — robotics hardware and software that's radically more accessible than legacy industrial solutions. We own and operate our own manufacturing — sourcing and production built in-house from scratch, no contract manufacturer anywhere in the loop — and in our first 12 months that line built and shipped 200+ robots to customers like NVIDIA, Qualcomm, Toyota, Google, Cobot, and Path Robotics in 60+ countries, while we grew from two founders to 30 people across three offices. And devkits are just the wedge: a custom force-sensing actuator partnership with major actuator OEMs and a new generation of robots are next, which means the factory you'd be joining is about to get a lot busier.
Everything we ship is designed in-house and built on our own line from components our vendors send us — sheet metal, CNC, machined parts — and the gap between a drawing and the physical part that arrives from a vendor is where production either stays on schedule or stalls. We need a junior engineer on the ground in Taiwan who can close that gap quickly and reliably.
The situation you're walking into:
You'll spend roughly 60–70% of your time in CAD — modeling, updating drawings, and tracking revisions as parts and designs evolve.
The other 20–30% is basic electromechanical and software work: understanding simple electrical systems (24V vs. 48V rails, correct wire gauge, how power over USB works) and running basic scripts on Linux-based systems to support testing and diagnostics.
You are not expected to design circuits, write firmware, or own software architecture — you'll have peers who are much stronger in EE and software, and they're your backstop, not your competition.
You will not be working alone on ambiguous calls. This is a junior IC role with senior support close by — your job is to execute well and know when to escalate, not to make final judgment calls solo.
What you'll own:
Day-to-day in-house CAD design work: creating and updating models and drawings, maintaining revision control, and keeping documentation aligned with what's actually being built on our own line.
Being the first line of defense when a vendor-supplied part — sheet metal, CNC, machined components — doesn't match its drawing: identifying the discrepancy, figuring out whether it's a drawing error, a tolerance issue, or a manufacturing defect, and proposing a fix.
Direct communication with vendor contacts to explain issues, negotiate rework or corrections, and keep production unblocked.
Applying basic electrical judgment (voltage, wire gauge, power delivery) when a mechanical issue intersects with an electrical one, and knowing when to pull in an EE.
Running basic scripts on Linux systems to support testing, data pulls, or simple diagnostics — not writing production software.
What the first 100 days look like:
By day 30: you know Anvil's CAD environment, file/revision conventions, and current product line cold. You've shadowed at least one factory floor visit and one drawing-vs-part discrepancy resolution end to end.
By day 60: you're independently handling routine drawing updates and can identify a drawing-vs-part mismatch on your own, though you're still looping in a senior engineer before proposing fixes to the vendor.
By day 100: you're independently identifying, diagnosing, and proposing fixes for routine drawing/part discrepancies, and communicating directly with vendor contacts on routine issues without needing a senior engineer in the loop every time.
Who you are:
You're comfortable and competent in a parametric CAD tool (SolidWorks, Fusion 360, or similar) — even if your experience is from coursework or an internship rather than years of professional work.
You can read and produce a basic technical drawing, including fundamental GD&T concepts (tolerances, datums) — you don't need to be an expert, but you need to be functional.
You know the practical difference between 24V and 48V systems, can select an appropriate wire gauge in the 15–20 AWG range for a given load, and understand the basics of how power delivery over USB works.
You're comfortable in a Linux terminal — navigating the filesystem, editing a config file, running an existing script, and doing basic troubleshooting. You are not expected to write software from scratch.
You're comfortable walking a factory floor, physically handling parts, and having a direct, sometimes difficult conversation with a vendor contact when something doesn't match spec.
You default to flagging problems rather than staying quiet about a mismatch you've noticed, even before you're sure what's causing it.
Fluent in Mandarin, with working proficiency in English (Anvil's internal reporting and documentation are in English).
Based in or willing to relocate to Taiwan, with the ability to be on-site at factory/production locations regularly.
Education & experience:
Bachelor's degree (or equivalent diploma) in mechanical engineering, mechatronics, or a related field. No graduate degree needed.
0–2 years of professional experience. The ideal background is an internship or first job spent working directly under a senior mechanical or manufacturing engineer — you've watched how drawing-vs-part problems actually get resolved and vendor conversations actually get handled, done growing pieces of it yourself, and are ready for the work to be yours. A sharp new grad with strong hands-on project or internship work beats years of narrow, repetitive drafting.
What this role is not:
Not an embedded systems, firmware, or software engineering role. Scripting is a small, supporting slice of the job, not the core of it.
Not a senior or autonomous EE design role. Your electrical knowledge needs to be solid at a foundational level, not expert — you have peers for anything beyond the basics.
Not a remote or desk-only CAD job. You need to be willing and able to be physically present on the factory floor when a part doesn't match its drawing.
Not a role where you're expected to make final calls alone on ambiguous technical tradeoffs — you have senior support, and using it well is part of the job.
You'll be the reason Anvil's robots keep running when nobody's watching — and the person who can explain why, in plain language, to both leadership and the customer standing next to a frozen arm.
Anvil is building the platform layer for Physical AI — robotics hardware and software that's radically more accessible than legacy industrial solutions. We own and operate our own manufacturing in Taipei — no contract manufacturer in the loop — and in our first 12 months we built and shipped 200+ robots (OpenARM and OpenYAM manipulators, Linux Devboxes, and teleop kits) to customers in 60+ countries: NVIDIA's GEAR lab, Qualcomm, Toyota, Google, Physical Intelligence, Cobot, Path Robotics, and the university labs whose papers define robot learning.
Devkits are the wedge, not the business. That volume has earned us a custom force-sensing actuator partnership with major actuator OEMs, and the install base becomes both the distribution channel for our next- generation robots and a platform that software partners build on. Every step of that strategy rests on one unglamorous fact: the robots already in the field have to keep working. Every one of those 200+ robots runs on a platform layer nobody notices until it breaks: process orchestration, logging, health, and lifecycle, spanning hardware, ROS2 middleware, and the application layer above it.
The situation you're walking into:
Anvil ships real robots to real customers, and each one depends on a runtime platform that currently has no single owner — reliability work happens, but it's not anyone's full-time job.
The same engineers who should be heads-down on ML, controls, and manufacturing keep getting pulled into platform fires: a broken bring-up jig, a factory test that won't run, a demo config that needs to work by tomorrow.
Most \"it doesn't work\" reports actually live at the boundary between hardware, ROS2 middleware, and application code — and the root cause is rarely in the layer where the symptom shows up.
This role is deeply communicative in two directions that have nothing to do with writing code: keeping Anvil's leadership informed on what's happening in robot learning and what it means for product and customers, in plain language; and working directly with deployment customers to understand their constraints and get them to a working outcome. Both audiences are non-technical relative to you, and making them smarter is part of the job, not a distraction from it.
What you'll own:
Reliability and root cause: keeping robots running 24/7, and fixing hardware, ROS2, and infrastructure issues at the actual root cause, not with a patch that just moves the symptom.
Clean, stable hardware interfaces — APIs between sensors/actuators and the application layers above them— so upstream teams don't have to think about the hardware boundary.
Observability and cloud: the logging, metrics, debugging tooling, and data pipelines that move information between robots and the cloud.
Internal enablement: unblocking ML, controls, and manufacturing quickly — factory testing workflows, experimental URDF or hardware branches, photoshoot/demo configurations, hardware bring-up and PCIe validation, and generally \"closing the loop\" on last-mile hardware+software problems.
What the first 100 days look like:
By day 30: ramped on the runtime platform architecture, the ROS2/hardware stack, and current known issues. Has personally closed at least one internal-team unblock (factory testing, bring-up, or a demo config) and shadowed a customer debugging session end to end.
By day 60: has shipped a first real reliability fix or platform improvement that measurably reduces recurring internal escalations. Is the first line of response for at least one class of hardware/software boundary issue.
By day 100: internal teams (ML, controls, manufacturing) are not waiting on platform support for routine needs. Is trusted by leadership as the plain-language translator on robot learning progress, and by customers as a credible technical point of contact.
Who you are:
You care about systems that actually work in the real world, not just clean abstractions on paper.
You're wired toward root cause analysis, not durable-looking patches that just address the symptom.
You move fast: bugs resolved in days, not weeks; features shipped in weeks, not months.
You're comfortable working across boundaries — hardware, middleware, and application layers — rather than staying in one layer.
You prefer incremental improvements over large rewrites.
You're pragmatic: you choose the solution that works reliably over the one that's theoretically elegant.
You're comfortable debugging when the problem is unclear, the logs are incomplete, and the issue comes from an interaction between multiple complex systems.
You can genuinely explain deep technical reality in plain language to people who don't share your technical depth — Anvil's leadership and Anvil's customers alike.
Bonus: familiarity with CAN, cameras, sensors, or real-time systems; experience with containers, CI/CD, and cloud pipelines; exposure to Physical AI models, robot control systems, or computer vision.
Based in or willing to relocate to Taipei or San Francisco — we're hiring for this role in both locations: one seat next to the hardware team and production line in Taipei (strong China-based candidates are also in scope for this seat), one alongside leadership and the demo room in San Francisco — with flexible hours for cross-timezone collaboration when a deployment or debugging issue is urgent.
Education & experience:
Bachelor's or Master's in computer science, electrical engineering, robotics, or a related field. A PhD isn't required or expected — this is a build-it-and-keep-it-running role, not a research role.
Years matter less to us than trajectory. A typical req for a role like this might ask for 3–5 years; we're looking for someone with 1–3 unusually fast-growing years (or 1–2 on a steep curve) spent working directly alongside a senior platform/infrastructure or robotics systems engineer — someone who watched how real cross-layer root-causing happens, closed a growing share of real issues personally, and is ready to carry meaningfully more of that responsibility themselves.
What this role is not:
Not a feature-building software role scoped to a single service. The job is keeping the entire system working continuously, predictably, and debuggably — across layers, not within one.
Not a research role in ML, perception, or controls. You enable those teams and translate their work; you don't own their algorithms.
Not a role for someone who wants to stay in one layer — just ROS2, just hardware, or just cloud. The real work lives at the boundaries between them.
Not a scripted, decision-tree support role. Every internal or customer issue needs real root-cause judgment, not a runbook lookup.
You'll be the reason Anvil's data collection system goes from \"the parts work\" to \"the whole thing works.\"
Anvil is building the platform layer for Physical AI: robotics hardware and software that is radically more accessible than legacy industrial solutions. We own and operate our own manufacturing, and in our first 12 months we built and shipped 200+ robots to customers in 60+ countries: NVIDIA's GEAR lab (the team behind GR00T), Physical Intelligence (the frontier lab behind pi0), Qualcomm, Toyota, Google, and the robot learning labs at Stanford, MIT, Columbia, CMU, and Georgia Tech. The researchers who define this field run their experiments on our hardware, and many of them bought it with their own money.
Devkits are the wedge, not the business. That volume has earned us a custom force sensing actuator partnership with major actuator OEMs, and the install base becomes both the distribution channel for our next generation robots and a platform for the data and software layers above them. The handheld data collection system is the front end of that strategy: the instrument that turns real world tasks into training data at scale.
Our handheld data collection system lets people capture high quality demonstration data for training robots to do real tasks, wherever the task actually happens, with no teleoperation rig and no motion capture stage required.
The situation you're walking into:
Anvil already has specialist engineers deep in each piece of this system: pose tracking, model training, SoC/chip integration, and industrial design. Each piece works, but nobody currently owns making them work together as one product a customer can actually pick up and use. That is the gap you would fill.
What you'll own:
Full technical ownership of pulling the handheld data collection software system together end to end.
Acting as the systems and product engineer across specialist teams, including pose tracking, model training, SoC/chip, and industrial design. You will not personally do their deep technical work, but you are the one who understands how it all needs to fit together, catches the gaps between teams, and makes the call on what integrates now versus later.
Building real infrastructure for parts of the system that do not have it yet, including turning the model team's scripts into something repeatable.
What the first 100 days look like:
By day 30: ramped on every major piece of the system, including pose tracking, app software, cloud pipeline, and the model team's current workflow, well enough to know where the real gaps are, not just the documented ones. Has personally used the device to collect data end to end at least once.
By day 60: has shipped a first concrete integration or reliability improvement that makes two previously disconnected pieces of the system actually work together better.
By day 100: is the person other engineers, including those in pose tracking, model training, SoC/chip, and industrial design, go to when something is not fitting together. Trusted with real technical judgment calls across team boundaries without formal authority over any of those teams.
Who you are:
You have done systems or product integration work for a robotic or perception based product before. You have been the person who made disparate technical pieces (hardware, perception, software, sometimes ML) work together into something a real user relied on. This matters more than depth in any single domain.
You have genuine, provable depth in at least one of the following, along with familiarity with several of the others:
Perception/robotics systems (SLAM, VIO, sensor fusion, mapping)
Embedded application development: you have gotten real applications built, deployed, and running reliably on constrained or embedded hardware
Cloud scale pose estimation or perception pipeline engineering: building systems that turn sensor data into trustworthy estimates reliably at scale
ML workflow, training, and deployment engineering
Physical AI and robot learning deployment, for example VLA style policies, getting a trained model to actually make a robot do something
You can operate as a team of one across teams you don't manage, building enough technical credibility in each domain to know when something's actually wrong versus just unfamiliar to you.
You default to shipping the smallest thing that actually closes an integration gap, rather than hacking something bespoke every time or overbuilding a general platform nobody's asked for yet.
Based in or willing to relocate to Taiwan, the USA, or Trinidad & Tobago. This is the same role and scope regardless of location.
Education & experience:
Master's degree in robotics, computer science, electrical engineering, or a related field — or a bachelor's with equivalent hands-on depth. A PhD is not required; this is a product integration role, not a research role.
Years matter less to us than trajectory. The typical shape is 3–5 years of engineering experience, but 2–3 unusually fast-growing years count fully if they were spent working directly alongside a staff or principal engineer on a shipped robotics or perception product. Our ideal candidate has been the second chair on a real integration effort — watched how the cross-team calls get made, made a growing share of them under a senior engineer's cover — and is ready to own the whole thing for the first time.
What this role is not:
Not a role where you'll personally develop the core SLAM algorithms, train the models, or design the chip. Those are owned by dedicated specialist engineers and teams. Your job is integration and systems and product judgment across their work, not doing their jobs for them.
Not a management role. No direct reports today. You will drive alignment and technical decisions across teams you have no formal authority over. The \"tech lead\" part of this role is earned through judgment and trust, not a title.
Not a narrow software engineering role focused on one clean layer of the stack. If you want to specialize in a single domain and hand off everything else, this isn't the right fit.
Not a role with mature ML and data infrastructure to inherit. Where that does not exist yet, you are building it, not maintaining someone else's.
You'll be the first person a customer talks to when their OpenARM or OpenYAM devkit isn't behaving — and the reason our engineering team isn't fielding the same setup question for the fifth time this week.
Anvil is building the platform layer for Physical AI — robotics hardware and software that's radically more accessible than legacy industrial solutions. In our first 12 months we built and shipped 200+ robots — OpenARM and OpenYAM manipulators, Linux Devboxes, and teleop kits — to customers in 60+ countries, off a manufacturing line we own and operate ourselves. The customer list runs from NVIDIA, Qualcomm, Toyota, and Google to a couple dozen YC-backed robotics startups, with the researchers who define robot learning in between — and the strongest signal in it is repeat buying: ITRI, Taiwan's national research institute, has ordered six separate times. Customers come back when the whole experience works, and support is where that experience lives. It compounds, too: devkits are our wedge into next-generation robots sold to this same install base, so today's well-supported devkit customer is tomorrow's robot buyer. Software and remote operations run out of Trinidad and Tobago; hardware R&D and manufacturing happen in Taipei. This role can sit with either team — Taipei or Trinidad — in person.
The situation you're walking into:
Customers are paying $5K–$14K for a devkit that needs to work — but setup spans hardware assembly, CAN-bus comms, teleop pairing/calibration, and a ROS2/LeRobot software stack. Plenty of surface area for something to go sideways.
Our customers are usually engineers or researchers themselves. They're technical — just not technical on our specific stack — which makes support here look more like peer troubleshooting than typical consumer tech support.
A base of documentation and known-issue playbooks already exists. You're not starting from zero — but right now, too many of those known issues still end up pulled into engineering's day. We need someone who makes that stop.
What you'll own:
Full ownership of inbound technical support: devkit setup, teleop calibration, and hardware/software troubleshooting across OpenARM, OpenYAM, the Devbox, teleop kits, cameras, and grippers
Diagnostics: running Python scripts and Linux commands on the Devbox, reading ROS2 and CAN-bus logs, reproducing reported issues
Escalation packaging: when something is genuinely new, building a debugging history — logs, repro steps, what's already ruled out — clean enough that engineering can act on it immediately instead of chasing you for missing details
Documentation: maintaining and improving troubleshooting playbooks and FAQs so the same issue doesn't cost engineering time twice
Customer communication: representing Anvil clearly, patiently, and professionally to a technical customer base that expects a real answer, not a script
What the first 200 days look like (we run on two-week sprints, not annual reviews):
By day 30: handling common, documented setup and troubleshooting cases with minimal supervision.
By day 100: making a measurable, visible dent in support metrics, and you've already shipped at least one real process or documentation improvement.
By day 200: operating like you've been here for years — trusted with ambiguous cases, and actively reducing (not just processing) the volume of things that reach engineering.
We move fast here. If tight feedback loops and fast growth excite you more than they worry you, keep reading.
Who you are:
Comfortable running Python scripts and basic Linux commands — file navigation, logs, permissions, simple diagnostics. You don't need to write or debug production code.
You've supported hardware-plus-software systems before — robotics, IoT, embedded systems, industrial equipment, or similar — and you know \"it's broken\" can mean five different things depending on which layer you're looking at.
Detail-oriented enough to catch something \"weird\" — in a log, in how a device is behaving — before it's been flagged as a problem.
A strong communicator who can hold your own with a technical customer. Our buyers are engineers and researchers; you don't need to out-engineer them, but you can't be talked past either.
Patient enough to explain the same setup step for the tenth time today without the customer feeling like it's the tenth time.
Organized enough that anyone picking up your case notes could continue the investigation without asking you a single clarifying question.
Near-native English, written and spoken — all customer communication and internal documentation are in English, and you'll be the voice of Anvil to customers who expect precise, fluent technical communication.
Based in or willing to relocate to Taiwan or Trinidad and Tobago, working on-site with the engineering team in either location.
Bonus: exposure to ROS2 or robotics/electromechanical concepts (manipulators, actuators, CAN bus, IK), or a background in formal technical support or field service.
Education & experience:
No specific degree required. A diploma or bachelor's in a technical field helps, but demonstrated hands-on ability — Linux, Python scripts, real troubleshooting stories — is what we actually screen for.
1–3 years supporting hardware-plus-software systems is the typical shape, but 1–2 fast-growing years count fully if they were spent working directly alongside senior support or field-service engineers: watching how hard cases actually get diagnosed and escalated, taking on a growing share of them yourself, without ever having owned the queue outright. This role is your chance to own it.
What this role is not:
Not a software engineering role. You're not expected to write or ship production code.
Not a senior/staff engineering hire. This is front-line technical support, with a clear, expected path to escalate— not a mandate to solve everything solo.
Not a scripted, read-from-a-decision-tree support role. Every case needs real technical judgment; we're not looking for someone who just follows a flowchart.
You'll be the first person a customer talks to when their OpenARM or OpenYAM devkit isn't behaving — and the reason our engineering team isn't fielding the same setup question for the fifth time this week.
Anvil is building the platform layer for Physical AI — robotics hardware and software that's radically more accessible than legacy industrial solutions. In our first 12 months we built and shipped 200+ robots — OpenARM and OpenYAM manipulators, Linux Devboxes, and teleop kits — to customers in 60+ countries, off a manufacturing line we own and operate ourselves. The customer list runs from NVIDIA, Qualcomm, Toyota, and Google to a couple dozen YC-backed robotics startups, with the researchers who define robot learning in between — and the strongest signal in it is repeat buying: ITRI, Taiwan's national research institute, has ordered six separate times. Customers come back when the whole experience works, and support is where that experience lives. It compounds, too: devkits are our wedge into next-generation robots sold to this same install base, so today's well-supported devkit customer is tomorrow's robot buyer. Software and remote operations run out of Trinidad and Tobago; hardware R&D and manufacturing happen in Taipei. This role can sit with either team — Taipei or Trinidad — in person.
The situation you're walking into:
Customers are paying $5K–$14K for a devkit that needs to work — but setup spans hardware assembly, CAN-bus comms, teleop pairing/calibration, and a ROS2/LeRobot software stack. Plenty of surface area for something to go sideways.
Our customers are usually engineers or researchers themselves. They're technical — just not technical on our specific stack — which makes support here look more like peer troubleshooting than typical consumer tech support.
A base of documentation and known-issue playbooks already exists. You're not starting from zero — but right now, too many of those known issues still end up pulled into engineering's day. We need someone who makes that stop.
What you'll own:
Full ownership of inbound technical support: devkit setup, teleop calibration, and hardware/software troubleshooting across OpenARM, OpenYAM, the Devbox, teleop kits, cameras, and grippers
Diagnostics: running Python scripts and Linux commands on the Devbox, reading ROS2 and CAN-bus logs, reproducing reported issues
Escalation packaging: when something is genuinely new, building a debugging history — logs, repro steps, what's already ruled out — clean enough that engineering can act on it immediately instead of chasing you for missing details
Documentation: maintaining and improving troubleshooting playbooks and FAQs so the same issue doesn't cost engineering time twice
Customer communication: representing Anvil clearly, patiently, and professionally to a technical customer base that expects a real answer, not a script
What the first 200 days look like (we run on two-week sprints, not annual reviews):
By day 30: handling common, documented setup and troubleshooting cases with minimal supervision.
By day 100: making a measurable, visible dent in support metrics, and you've already shipped at least one real process or documentation improvement.
By day 200: operating like you've been here for years — trusted with ambiguous cases, and actively reducing (not just processing) the volume of things that reach engineering.
We move fast here. If tight feedback loops and fast growth excite you more than they worry you, keep reading.
Who you are:
Comfortable running Python scripts and basic Linux commands — file navigation, logs, permissions, simple diagnostics. You don't need to write or debug production code.
You've supported hardware-plus-software systems before — robotics, IoT, embedded systems, industrial equipment, or similar — and you know \"it's broken\" can mean five different things depending on which layer you're looking at.
Detail-oriented enough to catch something \"weird\" — in a log, in how a device is behaving — before it's been flagged as a problem.
A strong communicator who can hold your own with a technical customer. Our buyers are engineers and researchers; you don't need to out-engineer them, but you can't be talked past either.
Patient enough to explain the same setup step for the tenth time today without the customer feeling like it's the tenth time.
Organized enough that anyone picking up your case notes could continue the investigation without asking you a single clarifying question.
Near-native English, written and spoken — all customer communication and internal documentation are in English, and you'll be the voice of Anvil to customers who expect precise, fluent technical communication.
Based in or willing to relocate to Taiwan or Trinidad and Tobago, working on-site with the engineering team in either location.
Bonus: exposure to ROS2 or robotics/electromechanical concepts (manipulators, actuators, CAN bus, IK), or a background in formal technical support or field service.
Education & experience:
No specific degree required. A diploma or bachelor's in a technical field helps, but demonstrated hands-on ability — Linux, Python scripts, real troubleshooting stories — is what we actually screen for.
1–3 years supporting hardware-plus-software systems is the typical shape, but 1–2 fast-growing years count fully if they were spent working directly alongside senior support or field-service engineers: watching how hard cases actually get diagnosed and escalated, taking on a growing share of them yourself, without ever having owned the queue outright. This role is your chance to own it.
What this role is not:
Not a software engineering role. You're not expected to write or ship production code.
Not a senior/staff engineering hire. This is front-line technical support, with a clear, expected path to escalate— not a mandate to solve everything solo.
Not a scripted, read-from-a-decision-tree support role. Every case needs real technical judgment; we're not looking for someone who just follows a flowchart.
You'll be the reason Anvil's data collection system goes from \"the parts work\" to \"the whole thing works.\"
Anvil is building the platform layer for Physical AI: robotics hardware and software that is radically more accessible than legacy industrial solutions. We own and operate our own manufacturing, and in our first 12 months we built and shipped 200+ robots to customers in 60+ countries: NVIDIA's GEAR lab (the team behind GR00T), Physical Intelligence (the frontier lab behind pi0), Qualcomm, Toyota, Google, and the robot learning labs at Stanford, MIT, Columbia, CMU, and Georgia Tech. The researchers who define this field run their experiments on our hardware, and many of them bought it with their own money.
Devkits are the wedge, not the business. That volume has earned us a custom force sensing actuator partnership with major actuator OEMs, and the install base becomes both the distribution channel for our next generation robots and a platform for the data and software layers above them. The handheld data collection system is the front end of that strategy: the instrument that turns real world tasks into training data at scale.
Our handheld data collection system lets people capture high quality demonstration data for training robots to do real tasks, wherever the task actually happens, with no teleoperation rig and no motion capture stage required.
The situation you're walking into:
Anvil already has specialist engineers deep in each piece of this system: pose tracking, model training, SoC/chip integration, and industrial design. Each piece works, but nobody currently owns making them work together as one product a customer can actually pick up and use. That is the gap you would fill.
What you'll own:
Full technical ownership of pulling the handheld data collection software system together end to end.
Acting as the systems and product engineer across specialist teams, including pose tracking, model training, SoC/chip, and industrial design. You will not personally do their deep technical work, but you are the one who understands how it all needs to fit together, catches the gaps between teams, and makes the call on what integrates now versus later.
Building real infrastructure for parts of the system that do not have it yet, including turning the model team's scripts into something repeatable.
What the first 100 days look like:
By day 30: ramped on every major piece of the system, including pose tracking, app software, cloud pipeline, and the model team's current workflow, well enough to know where the real gaps are, not just the documented ones. Has personally used the device to collect data end to end at least once.
By day 60: has shipped a first concrete integration or reliability improvement that makes two previously disconnected pieces of the system actually work together better.
By day 100: is the person other engineers, including those in pose tracking, model training, SoC/chip, and industrial design, go to when something is not fitting together. Trusted with real technical judgment calls across team boundaries without formal authority over any of those teams.
Who you are:
You have done systems or product integration work for a robotic or perception based product before. You have been the person who made disparate technical pieces (hardware, perception, software, sometimes ML) work together into something a real user relied on. This matters more than depth in any single domain.
You have genuine, provable depth in at least one of the following, along with familiarity with several of the others:
Perception/robotics systems (SLAM, VIO, sensor fusion, mapping)
Embedded application development: you have gotten real applications built, deployed, and running reliably on constrained or embedded hardware
Cloud scale pose estimation or perception pipeline engineering: building systems that turn sensor data into trustworthy estimates reliably at scale
ML workflow, training, and deployment engineering
Physical AI and robot learning deployment, for example VLA style policies, getting a trained model to actually make a robot do something
You can operate as a team of one across teams you don't manage, building enough technical credibility in each domain to know when something's actually wrong versus just unfamiliar to you.
You default to shipping the smallest thing that actually closes an integration gap, rather than hacking something bespoke every time or overbuilding a general platform nobody's asked for yet.
Based in or willing to relocate to Taiwan, the USA, or Trinidad & Tobago. This is the same role and scope regardless of location.
Education & experience:
Master's degree in robotics, computer science, electrical engineering, or a related field — or a bachelor's with equivalent hands-on depth. A PhD is not required; this is a product integration role, not a research role.
Years matter less to us than trajectory. The typical shape is 3–5 years of engineering experience, but 2–3 unusually fast-growing years count fully if they were spent working directly alongside a staff or principal engineer on a shipped robotics or perception product. Our ideal candidate has been the second chair on a real integration effort — watched how the cross-team calls get made, made a growing share of them under a senior engineer's cover — and is ready to own the whole thing for the first time.
What this role is not:
Not a role where you'll personally develop the core SLAM algorithms, train the models, or design the chip. Those are owned by dedicated specialist engineers and teams. Your job is integration and systems and product judgment across their work, not doing their jobs for them.
Not a management role. No direct reports today. You will drive alignment and technical decisions across teams you have no formal authority over. The \"tech lead\" part of this role is earned through judgment and trust, not a title.
Not a narrow software engineering role focused on one clean layer of the stack. If you want to specialize in a single domain and hand off everything else, this isn't the right fit.
Not a role with mature ML and data infrastructure to inherit. Where that does not exist yet, you are building it, not maintaining someone else's.
You'll be the reason Anvil's robots keep running when nobody's watching — and the person who can explain why, in plain language, to both leadership and the customer standing next to a frozen arm.
Anvil is building the platform layer for Physical AI — robotics hardware and software that's radically more accessible than legacy industrial solutions. We own and operate our own manufacturing in Taipei — no contract manufacturer in the loop — and in our first 12 months we built and shipped 200+ robots (OpenARM and OpenYAM manipulators, Linux Devboxes, and teleop kits) to customers in 60+ countries: NVIDIA's GEAR lab, Qualcomm, Toyota, Google, Physical Intelligence, Cobot, Path Robotics, and the university labs whose papers define robot learning.
Devkits are the wedge, not the business. That volume has earned us a custom force-sensing actuator partnership with major actuator OEMs, and the install base becomes both the distribution channel for our next- generation robots and a platform that software partners build on. Every step of that strategy rests on one unglamorous fact: the robots already in the field have to keep working. Every one of those 200+ robots runs on a platform layer nobody notices until it breaks: process orchestration, logging, health, and lifecycle, spanning hardware, ROS2 middleware, and the application layer above it.
The situation you're walking into:
Anvil ships real robots to real customers, and each one depends on a runtime platform that currently has no single owner — reliability work happens, but it's not anyone's full-time job.
The same engineers who should be heads-down on ML, controls, and manufacturing keep getting pulled into platform fires: a broken bring-up jig, a factory test that won't run, a demo config that needs to work by tomorrow.
Most \"it doesn't work\" reports actually live at the boundary between hardware, ROS2 middleware, and application code — and the root cause is rarely in the layer where the symptom shows up.
This role is deeply communicative in two directions that have nothing to do with writing code: keeping Anvil's leadership informed on what's happening in robot learning and what it means for product and customers, in plain language; and working directly with deployment customers to understand their constraints and get them to a working outcome. Both audiences are non-technical relative to you, and making them smarter is part of the job, not a distraction from it.
What you'll own:
Reliability and root cause: keeping robots running 24/7, and fixing hardware, ROS2, and infrastructure issues at the actual root cause, not with a patch that just moves the symptom.
Clean, stable hardware interfaces — APIs between sensors/actuators and the application layers above them— so upstream teams don't have to think about the hardware boundary.
Observability and cloud: the logging, metrics, debugging tooling, and data pipelines that move information between robots and the cloud.
Internal enablement: unblocking ML, controls, and manufacturing quickly — factory testing workflows, experimental URDF or hardware branches, photoshoot/demo configurations, hardware bring-up and PCIe validation, and generally \"closing the loop\" on last-mile hardware+software problems.
What the first 100 days look like:
By day 30: ramped on the runtime platform architecture, the ROS2/hardware stack, and current known issues. Has personally closed at least one internal-team unblock (factory testing, bring-up, or a demo config) and shadowed a customer debugging session end to end.
By day 60: has shipped a first real reliability fix or platform improvement that measurably reduces recurring internal escalations. Is the first line of response for at least one class of hardware/software boundary issue.
By day 100: internal teams (ML, controls, manufacturing) are not waiting on platform support for routine needs. Is trusted by leadership as the plain-language translator on robot learning progress, and by customers as a credible technical point of contact.
Who you are:
You care about systems that actually work in the real world, not just clean abstractions on paper.
You're wired toward root cause analysis, not durable-looking patches that just address the symptom.
You move fast: bugs resolved in days, not weeks; features shipped in weeks, not months.
You're comfortable working across boundaries — hardware, middleware, and application layers — rather than staying in one layer.
You prefer incremental improvements over large rewrites.
You're pragmatic: you choose the solution that works reliably over the one that's theoretically elegant.
You're comfortable debugging when the problem is unclear, the logs are incomplete, and the issue comes from an interaction between multiple complex systems.
You can genuinely explain deep technical reality in plain language to people who don't share your technical depth — Anvil's leadership and Anvil's customers alike.
Bonus: familiarity with CAN, cameras, sensors, or real-time systems; experience with containers, CI/CD, and cloud pipelines; exposure to Physical AI models, robot control systems, or computer vision.
Based in or willing to relocate to Taipei or San Francisco — we're hiring for this role in both locations: one seat next to the hardware team and production line in Taipei (strong China-based candidates are also in scope for this seat), one alongside leadership and the demo room in San Francisco — with flexible hours for cross-timezone collaboration when a deployment or debugging issue is urgent.
Education & experience:
Bachelor's or Master's in computer science, electrical engineering, robotics, or a related field. A PhD isn't required or expected — this is a build-it-and-keep-it-running role, not a research role.
Years matter less to us than trajectory. A typical req for a role like this might ask for 3–5 years; we're looking for someone with 1–3 unusually fast-growing years (or 1–2 on a steep curve) spent working directly alongside a senior platform/infrastructure or robotics systems engineer — someone who watched how real cross-layer root-causing happens, closed a growing share of real issues personally, and is ready to carry meaningfully more of that responsibility themselves.
What this role is not:
Not a feature-building software role scoped to a single service. The job is keeping the entire system working continuously, predictably, and debuggably — across layers, not within one.
Not a research role in ML, perception, or controls. You enable those teams and translate their work; you don't own their algorithms.
Not a role for someone who wants to stay in one layer — just ROS2, just hardware, or just cloud. The real work lives at the boundaries between them.
Not a scripted, decision-tree support role. Every internal or customer issue needs real root-cause judgment, not a runbook lookup.
You'll be the person turning parts on the shelf into robots that are ready to ship.
Anvil is building the platform layer for Physical AI — robotics hardware and software that's radically more accessible than legacy industrial solutions. We own and operate our own manufacturing, with sourcing, assembly, testing, and production built in-house.
As an Assembly Technician, you'll work directly on our production line in Taipei, assembling robotic systems and making sure each unit is built correctly, tested, and ready for customers. This is a hands-on role for someone who enjoys building things, pays attention to details, and is comfortable learning quickly in a fast-moving environment.
You'll spend most of your time hands-on: assembling robots, mechanical parts, motors, wiring, and other components.
You'll follow drawings, work instructions, and BOMs to make sure each unit is assembled correctly.
You'll perform basic functional checks and testing before products move to the next stage or ship to customers.
When something doesn't fit, looks wrong, or doesn't work as expected, you'll identify the issue and work with engineers to resolve it.
You don't need to design the robot or write software. Engineers will be close by when deeper technical support is needed.
Day-to-day assembly of robotic systems and subassemblies.
Installing mechanical components, motors, cables, connectors, fasteners, and other hardware.
Following assembly instructions, drawings, and BOMs accurately.
Performing basic testing, inspection, and quality checks on completed units.
Identifying assembly issues, defective parts, or inconsistencies and reporting them clearly to the engineering team.
Keeping tools, components, and the assembly area organized.
Helping improve assembly procedures as we learn how to build products faster and more reliably.
Supporting packing and production preparation when needed.
You enjoy hands-on mechanical or electrical assembly work.
You're comfortable using common hand tools such as screwdrivers, hex keys, torque tools, and calipers.
You can follow drawings, instructions, and checklists carefully.
You're detail-oriented and notice when something doesn't look or fit right.
You're comfortable working around mechanical parts, motors, cables, and electronics.
You're willing to ask questions when something is unclear rather than guessing.
You learn quickly and are comfortable working in a fast-moving startup environment.