One of the fastest ways to make an engineering team worse is to treat every problem like an emergency.

This is especially tempting in robotics.

Robots fail in visible, physical, occasionally expensive ways. They get stuck. They do the wrong thing. They stop in the middle of a field. They fail a demo. They behave differently in the real world than they did in simulation, because of course they do.

When that happens, the natural response is to pull everyone in, start asking for updates, and make sure the problem is getting attention.

Sometimes that is exactly the right thing to do. Urgency is real.

But urgency and panic are not the same thing.

When I joined Blue River, the team was drowning in reactive engineering. The codebase was hard to work in, the field season had produced a long list of failures, and there was limited time before the next season to make the system better.

Everything was a fire.

A robot would fail in the field and no one could quickly tell whether it was perception, planning, controls, hardware, operations, configuration, infrastructure, or something weird that only happens on Tuesdays when the logs are missing.

So everyone got pulled in.

That was understandable.

It is also expensive.

This is how a real problem becomes a coordination problem.

Now you have two problems.

Congratulations.

Find the gaps in the approach

The first thing I changed was how we decided what mattered.

The team had been treating too many failures as individual incidents. I turned the previous field season into a triage system: reviewed the failure data, grouped recurring issues, identified trends, and separated one-off failures from patterns that were costing us real time.

At some scale, the interesting question is rarely:

Why did this robot fail?

The interesting question is:

Why do we keep seeing this shape of failure?

That shift changed the conversation.

Instead of debating the latest fire, I could point to the trend. This was not a nice-to-have cleanup task. This was one of the patterns that had been repeatedly slowing us down.

Fix the gaps in the organization

Some of the fixes were technical. Some were organizational.

One gap I saw was the relationship between the application and product teams, so I hired specifically to strengthen that connection. The goal was not just to add another person. It was to reinforce a weak seam in the organization.

The useful work was not telling people to stop reacting. The useful work was changing what they had to react to.

A team can have smart people working hard and still keep losing time in the same places if ownership is unclear, communication paths are weak, or the right roles do not exist yet.

Protect the work that changes the system

Once the team had a clearer picture of the patterns, I introduced team OKRs, adjusted bandwidth around the work that mattered most, and gave longer-term projects enough cover to finish instead of getting repeatedly sacrificed to the emergency of the week.

Over the next year, the team roughly tripled mean time between intervention and reduced firefighting from about 70% of team time to 30%. The team also landed a major robotics capability upgrade that is already making it easier to integrate new sensors and improve reasoning around the tractor.

Not because one heroic fix solved everything.

Because the team got better at identifying the right problems, protecting the work that mattered, and finishing changes that improved the system.

The hard part is that this kind of work does not always look like much from the outside. Fewer escalations, clearer ownership, faster triage, less thrash. Ideally, nothing catches fire.

Robotics will always produce surprises. The goal is not to eliminate urgency; it is to stop making urgency the operating model.

The trick is knowing which problems need immediate attention, which need a postmortem, and which need a better system around them.