Open a robotics engineer vacancy and you will find mechanical design, electronics, embedded software, control theory, sensing, simulation and usually a specific vendor's programming environment.
That is not a person. It is a team, written as a job advertisement.
The vacancy that describes a team
Robotics is genuinely multi-disciplinary, which is what makes it interesting and what makes hiring for it dysfunctional.
A robot is a mechanical structure, an electrical and electronic system, and a substantial amount of software, all of which have to work as one. Understanding any one of those well takes years.
The market is not short of robotics engineers. It is short of people who can hold three disciplines at once, which is a job design problem before it is a hiring one.
The World Economic Forum's Future of Jobs Report 2025 found 58 percent of employers expect robots and autonomous systems to transform their business by 2030, and the US Bureau of Labor Statistics projects industrial engineer employment growing about 11 percent between 2024 and 2034. Demand is not the question. The question is what you are actually hiring for.
What the direction covers
The scope: mechanics, electronics and code as one discipline, plus sensors, actuators, kinematics and robot design.
Four capability areas.
Kinematics and dynamics. Where the robot's end effector is, how to get it somewhere, and what forces are involved. The mathematical core of the field.
Actuation and mechanical design. Motors, drives, transmissions, structures and stiffness. What the machine can physically do.
Sensing. Encoders, force and torque sensing, proximity, vision. How the robot knows anything about the world.
Software architecture. How the pieces communicate, in real time, reliably, and how the whole thing is programmed and debugged.
Where robots actually go wrong
The single most useful thing an organisation buying robots can know: the robot is usually the reliable part.
Industrial robot arms are mature products with long service lives and well-understood failure rates. When an automation project underperforms, the cause is almost always somewhere else.
Part presentation. The robot needs the part in a known position, or it needs to find it. Getting parts to arrive consistently is a fixturing, conveying and feeding problem, and it is where most of the engineering effort actually goes.
Variability. The real process has variation the demonstration did not. Parts differ, materials differ, temperature changes, things get dirty. A cell that works on clean new parts fails on the actual production mix.
Gripping. End effector design is underestimated constantly. Picking up a rigid box is easy. Picking up something soft, wet, variable or fragile is a serious engineering problem, and it is frequently the reason a project is abandoned.
Edge cases in handling. What happens when a part is missing, upside down, jammed or damaged. A cell without a plan for these stops, and a cell that stops often is worse than manual.
Integration with everything else. The upstream process, the downstream process, the plant systems, the quality checks.
Where this sits in the domain
Robotics engineering is the first of nine directions in Astra Trainer's robotics and autonomous systems domain, which runs through mechatronics, control systems, industrial robotics, computer vision, autonomous vehicles, drones, humanoid and service robotics, and human-robot interaction and safety.
It is the foundation the other eight assume. Partners deploying robots on a factory floor usually scope it with industrial robotics and with the advanced manufacturing domain, where industrial automation and control covers the PLC and line-level layer. Lessons are five minutes, which suits engineers and technicians who cannot leave a commissioning job for a course. You can see the nine directions here.
The integration layer nobody owns
The recurring finding across this whole domain, stated once here properly.
Buying a robot is a procurement task. Programming a robot to perform a motion is a trainable skill with vendor courses attached. Making a robot do useful work inside a real process, reliably, for years, is something else entirely, and there is no degree in it.
Integration means understanding the process the robot is joining, designing the fixturing and material flow around it, selecting and sizing sensing, handling the exceptions, connecting it to plant systems, commissioning it against real production, and supporting it afterwards.
Three consequences.
The skill is learned on projects. Which means it lives with system integrators and with the few in-house people who have done several. It transfers by doing, not by reading.
Outsourcing it has a cost. Using an integrator is legitimate and frequently correct. The trap is having no internal capability at all, because then every change, every new product variant and every fault becomes a purchase order and a wait.
It is geographically concentrated. The WEF report notes that 80 percent of the world's industrial robot installations happen in just five countries. Practical integration experience concentrates where the installations are, which makes building it locally harder in the places with the least of it and makes training the existing workforce the realistic route.
The roles, named
Robotics engineers. Usually meaning integration and application engineering rather than robot design.
Robot programmers. Vendor-specific, often certified, and the most accessible entry point.
Automation and controls engineers. Where robotics meets the PLC layer, which is the manufacturing domain's territory.
Mechanical design engineers for automation. Fixturing, tooling, end effectors and cell layout. Undervalued and decisive.
Robot maintenance technicians. Keeping cells running, and a real shortage as installed bases age.
Simulation and offline programming specialists. Proving a cell before it is built, which reduces commissioning time substantially.
Systems integration engineers. The scarce role described above.
Robotics software engineers. Middleware, perception and motion planning, closer to the autonomous end of the domain.
Who can be trained into it
Maintenance technicians. The strongest conversion in industrial settings. They already understand the equipment, the plant and how things fail, and they are on site when something goes wrong. Adding robotics and controls knowledge produces people who can diagnose a cell rather than call the integrator.
Machine operators on automated lines. Understand the process and the product variability better than any engineer, which is exactly the knowledge integration needs and the part that cannot be taught quickly.
Electricians and instrumentation technicians. Into the controls and commissioning side.
Mechanical designers. Into fixturing, tooling and end effector design, which is the underrated half.
Software engineers. Into robotics software, needing the physical-world layer: that sensors are noisy, actuators have limits and the real world does not match the model.
CNC programmers and machinists. Already think in coordinate frames, tooling and process, which transfers directly to robot programming.
Industrial robots are hazardous machinery. Working on or near industrial robots is governed by machinery safety regulation, risk assessment requirements and site procedures including energy isolation, guarding and authorisation to enter a cell. Teaching and commissioning modes carry specific risks because normal protective measures may be suspended. Structured training builds engineering understanding and hazard awareness. It does not authorise anyone to enter a robot cell, perform maintenance, or override a safety system, and those permissions come from site procedure and documented competence.
What to take from this
The job description usually describes three disciplines and a team, which is why the vacancy stays open.
The robot is the reliable part. Part presentation, variability, gripping and exception handling are where projects fail.
Integration is the scarce capability, it has no formal qualification route, and it transfers by doing projects.
Outsourcing integration entirely means every change becomes a purchase order and a wait, which is fine until the product mix changes.
And your maintenance technicians and line operators hold the process knowledge integration depends on. They are the conversion, and almost nobody offers it to them.
Why are robotics roles hard to fill?
Because the typical job description spans mechanical, electrical and software engineering plus integration, which is a team rather than a person. It is a job design problem before it is a labour market one.
What actually goes wrong on automation projects?
Rarely the robot. Part presentation and fixturing, process variability, gripper design and unhandled exceptions account for most underperformance and most abandoned projects.
What is integration and why is it scarce?
Making a robot do useful work inside a real process reliably for years. There is no degree in it, it is learned on projects, and experience concentrates where installations concentrate.
Who converts into robotics roles best?
Maintenance technicians and line operators, who hold the plant and process knowledge that integration depends on. CNC programmers transfer readily to robot programming, and mechanical designers into fixturing and end effectors.
Where does this fit in the domain?
First of nine directions in Astra Trainer's robotics and autonomous systems domain, usually scoped with industrial robotics and with advanced manufacturing. You can see them here.