I was in Boston last week for a quick family trip.

Nothing work-related. No site visits. Just a short stay that unexpectedly pulled me back to an earlier chapter, my time with Berkshire Grey and the early days of how I thought about automation.

Being there reminded me how much my perspective has changed.

The technology itself hasn’t stopped being impressive. If anything, it’s more capable than ever. What’s shifted is what experience has trained me to listen for.

Early on, my reactions were fairly straightforward. I paid close attention to demos, throughput curves, utilization targets, and what a system could do at scale. Those things still matter.

They just don’t carry the same weight for me anymore.

What draws my attention now is less about how polished the plan looks and more about what happens when it bends.

The first thing,

I want to understand is how a system behaves when something slips. Not if it will happen. It always does. What matters is how quickly people notice, how easily they can orient themselves, and how much time is spent simply figuring out what kind of problem they’re dealing with before anyone can act.

In real operations, issues rarely arrive as clean failures. They start as small hesitations. Minor misalignments. Quiet signals that don’t trigger alarms but slowly pull the system off balance.

Strong systems don’t eliminate those moments.
They help teams move through them without panic.

From there,

my attention usually shifts to integration not in terms of capability, but ownership.

I listen for clarity around who lives with the system once it’s live. Who debugs it when behavior changes. Who decides whether a fix belongs upstream, downstream, or somewhere in between.

When ownership isn’t clear, recovery slows down. Teams lose time just orienting themselves, and that uncertainty compounds. It doesn’t show up early in a project, but it becomes very visible over time.

Another area,

that tends to surface later than it should is building readiness.

Fire protection. Electrical capacity. Permitting timelines.
Infrastructure changes that don’t sit neatly inside a vendor scope.

These are often treated as background assumptions or rolled into a single line item, if they show up at all. Not because anyone is trying to hide anything. More often because no one in the room fully owns that layer yet.

What I listen for now is whether these realities are being named early, and how clearly teams understand what it will actually take to make the building ready for the system being proposed.

When readiness is treated as an afterthought, it has a way of resurfacing later through delays, rework, or costs that weren’t modeled in the original business case. That’s just how complexity behaves. It reveals itself in phases.

I also listen,

closely to the assumptions quietly holding everything together.

Order profiles. Inventory accuracy. Operator behavior. Volume stability.

None of these are wrong. They just become fragile when they go unexamined.

I pay attention to how openly those assumptions are named, and how teams expect them to evolve. What shifts first when volume changes. Where variability shows up before the metrics do. How much slack actually exists when conditions tighten.

The strongest conversations aren’t the ones that promise flexibility everywhere. They’re the ones that are honest about where flexibility starts to thin.

And then there’s

the human side. This is usually where my attention lingers the longest.

Not on headcount models or training decks, but on things that never show up in specs. How much context operators actually have. How much judgment they’re expected to exercise. What happens when the plan doesn’t quite match the floor.

Automation reshapes people’s roles. How that shift is handled has a real impact on how resilient a system becomes. When operators are treated as partners in recovery, systems tend to hold up better. When context is thin and judgment is constrained, fragility builds quietly before it becomes obvious.

These days, I spend less time focused on how a system performs on day one. What I care about more is where strain is likely to show up when the business changes because it always does. Volume shifts. Mix evolves. Expectations tighten.

Good automation doesn’t eliminate complexity.
It decides where complexity lives and how manageable it is when pressure shows up.

I’m not sharing this as advice or a checklist. It’s simply a reflection on how my own lens has evolved.

Strong systems don’t just perform well when conditions are ideal. They help people stay oriented when reality drifts from the plan.

That’s the perspective I’m carrying into this year.

I’ve noticed these questions tend to surface after the demo when leaders are trying to decide what they actually trust.

If that’s a conversation you’re navigating right now, I’m always happy to compare notes.

- Parth

Thoughts? Questions? Feedback? Reply to this email.