A few years ago, I put something out on LinkedIn that I wasn't sure would land.

I called for a Robotics leadership role at the C-level. Not a project manager. Not a vendor liaison. A seat at the executive table for someone whose entire job is to own automation, not as a project, but as a capability that bridges engineering, operations, IT, and innovation.

Shortly after, GXO created exactly that. A Chief Automation Officer.

People nodded quietly. "Interesting idea." "Maybe for the big guys." "We're not there yet."

But every theme I've explored in this newsletter - every breakdown, every pattern, every expensive surprise - traces back to the same root cause:

Automation didn't have leadership. It had a budget line.

Recovery takes longer than failure. Teams spend more time debating what kind of problem they have than actually fixing it. That's not a technology problem. It's a coordination problem. And it persists because no one at the leadership level owns the alignment between ops, maintenance, IT, and engineering around automation.

A Chief Automation Officer does.

Integration shows up as a bullet on page 37 of the vendor eval. The real question isn't whether systems can connect - it's where judgment lives once they do. But integration keeps getting buried because there's no strategic leader forcing it into the first three agenda items.

A CAO makes integration a gate, not an afterthought.

I watched a site go from 6 automation staff to 28 as bots scaled from 45 to 100+. The labor savings didn't disappear because the robots failed. They disappeared because nobody modeled the organizational complexity that comes with scale. Nobody modeled it because nobody's job was to model it.

That's the CAO's job. Before the first purchase order gets signed.

And then there's the silence. Quiet doesn't mean stable; sometimes it means ownership has gone missing. The vendor leaves. The project team disbands. The system drifts. And nobody notices until something breaks badly enough to force a conversation.

Every one of these problems is downstream of the same upstream gap. No one in the room when budgets get set, and priorities get decided, who can say: this is what automation actually needs to succeed. Not just at go-live. Permanently.

Most companies treat automation like a capital expenditure. You scope it, fund it, install it, and commission it. Done. But automation isn't a conveyor extension. It's closer to your WMS or your safety program - something that requires ongoing expertise, organizational muscle, and cross-functional alignment just to deliver what the business case promised.

The CAO is the person who makes sure that happens.

They make sure automation investment connects to the business model, not just the throughput model. They're the ones asking: does this technology fit our operation as it actually runs or as we wish it ran? They catch the geography mismatch, the architecture problem, the assumption drift, before it becomes a $4 billion industry lesson.

They own the team design. Not just headcount, but the structure. Who monitors. Who recovers. Who carries the deep system knowledge. And they build it on purpose, with career paths and training pipelines, instead of letting it assemble itself reactively under pressure.

And they own the coordination. Ops talks urgency. Maintenance talks precision. Engineering talks data. IT talks architecture. I've seen what it looks like when those languages never overlap - I walked into a five-year-old system where uptime was green but nobody trusted anyone. The CAO builds that trust fabric. They're the reason the integration workshop gets mandated, the post-go-live ownership doesn't vanish, and the recovery protocol actually gets practiced.

Amazon and Walmart didn't win because they bought better robots. They won because they made automation a C-suite strategic priority with real capability investment. They built the organizational muscle first.

GXO created the Chief Automation Officer role - one of the first operators to formalize this at the C-level. The leader who held that role has since moved on.

If your automation strategy walks out the door when one leader leaves, you haven't built a capability. You've built a dependency.

The playbooks, the team structure, the cross-functional rhythms, the integration standards, those need to live in the organization, not in one person's head.

I've written before about how operators become real-time WES systems during Peak. Heroes filling design gaps. The same dynamic plays out at the leadership level. If your automation strategy depends on a single champion, you don't have a strategy. You have a vulnerability.

The CAO's job isn't just to lead. It's to build the muscle so that automation stays on track even when leadership changes.

That's what makes it strategic.

It never has been. What I care about more is whether your organization is designed to absorb automation before you buy it.

Who owns the system, six months after the vendor leaves, at 2 AM on a Tuesday?

Who owns the WMS integration conversation permanently?

What does your automation team look like at 100+ bots? Who's designing that now?

If those questions don't have owners, you don't have a strategy. You have a purchase order.

Automation is not capex. It's organizational infrastructure. And it needs a leader.

If you're heading to MODEX in Atlanta next month (April 13–16) - carry this question onto the show floor with you. Before you ask a vendor about throughput or cycle time, ask yourself: who back home is going to own this? If you don't have an answer, that's your first investment. Not the robot. The role.

If you're actually creating this role and want to talk about what it should look like, hit reply. That's a conversation I would love to help out.

- Parth

Thoughts? Questions? Feedback? Reply to this email.