Every hardware team is governed by the same three forces.

Performance.
Cost.
Schedule.

It doesn’t matter if the team is five people or five thousand. These three constraints sit behind every design review, every argument, and every compromise. Every engineering decision is an attempt to rebalance them.

What changes is not whether they matter.
What changes is when they stop forgiving you.

There is a curve that defines hardware development, and almost no one draws it.

Early in a program, the curve is steep. Decisions are cheap. Changes feel reversible. A missed assumption can be corrected with a sketch, a quick CAD edit, or a different material call. Performance targets are still elastic. Cost models are rough. Schedules feel distant.

Then, quietly, the curve flattens.

At some point, the same change stops being a design tweak and starts becoming a system event. A dimension change affects tooling. A material change triggers supplier requalification. A performance improvement pushes cost or slips schedule. Nothing is isolated anymore.

The decision didn’t get worse.
The system got rigid.

This is where teams get confused.

They experience late-stage resistance and assume the problem is technical complexity. But complexity is not the real constraint. Loss of optionality is.

Early in development, performance, cost, and schedule behave like independent axes. You can trade one without collapsing the others. Later, they converge. A change in one now taxes all three simultaneously. Performance improvements cost time. Cost reductions threaten performance. Schedule pressure locks everything in place.

This is why small changes late in hardware programs feel irrationally expensive. It’s not because engineers suddenly became conservative. It’s because the system has finished setting.

Experienced mentors recognize this instantly. They push uncomfortably hard early. They ask questions that feel premature. They force decisions when flexibility still exists. And later, they resist change with equal intensity.

From the outside, this looks like stubbornness.
From the inside, it’s discipline.

What software culture often misses is that hardware does not forgive late clarity. There is no refactor phase for physics. There is no patch for a missed tolerance once tooling is cut. The curve does not reset just because the insight arrived late.

Every hardware team eventually learns this lesson. Some learn it through missed schedules. Others through cost overruns. The unlucky ones learn it through failures in the field.

The teams that perform best are not the ones that make fewer mistakes. They are the ones that make their most consequential decisions while the curve is still steep.

Because in hardware, progress is not about finding the perfect answer.
It’s about choosing while choice still exists.

And that curve is always there, whether you draw it or not.

—Arjun