Eventually, every robotics organization has this meeting.

A robot did something weird in the field. Maybe it stopped when it should have kept going. Maybe it took an awkward path around an obstacle. Maybe it hesitated just long enough that everyone nearby noticed.

Maybe it technically did what the software told it to do, which is sometimes worse.

So people get pulled into a room: planning, perception, controls, maybe localization, maybe hardware, and someone from field operations who has already had this conversation three times today and is trying very hard to be polite.

Then someone asks the question:

“So… whose bug is this?”

Planning says the robot was reacting to what perception gave it. Perception says the uncertainty was real and planning should have handled it. Controls says it executed the trajectory it was given. Hardware says the sensors were within spec. The field team says the customer does not care.

Nobody is wrong, exactly.

The robot is still behaving badly.

I have been in some version of this meeting across robots for roads, fields, homes, and space. Different robots, different products, different environments, different org charts. The conversation barely changes.

A robot does not know it has a planning team. It does not know that perception, controls, localization, infrastructure, simulation, and machine learning all have separate roadmaps. It does not know which interface was clean on paper, which team owns the metric, or which dependency was negotiated two quarters ago.

It experiences one continuous system.

So does the customer.

The organization, however, does not. It experiences the robot through the boundaries it created to make the work manageable.

The way out is not to pretend the boundaries are fake. They exist for a reason. Perception really does need ownership of perception. Planning really does need ownership of planning. Controls really does need ownership of controls.

The problem starts when the boundary becomes more important than the behavior.

Once that happens, teams naturally start optimizing their own components instead of the overall system. That is a subtle shift, but it changes the conversation. Instead of asking what the robot should do, we start asking whose component should change.

That is backwards.

Before deciding whether perception, planning, or controls should change, the team has to agree on the behavior it is trying to produce.

In this situation, should the robot continue or stop?

Should it treat the obstacle as something to avoid, something to slow near, or something to ignore?

Should it prioritize progress, clearance, smoothness, or caution?

Those are behavior questions. They do not belong cleanly to one component.

Once the desired behavior is clear, the component work becomes clearer too. Perception may need to represent the obstacle differently. Planning may need to reason about distance or uncertainty differently. Controls may need to track the intended path more tightly. More importantly, those changes can point in the same direction.

That is the part of technical leadership in robotics that is easy to underestimate.

Not drawing the perfect org chart. That does not exist.

Not making every team responsible for everything. That does not work either.

The job is noticing when “not my component” has become “not my bug.”

Because in the field, the robot still has to work.