The Autonomy Paradox

# #

The instinct for time management in technical work isn't just a junior engineer problem — it's a new-to-the-work problem. It's just more visible in junior folks.

When someone is new, you expect them to struggle. So you coach them to communicate, ask questions, get unblocked. Good advice. But here's the tension: people also want to make an impact. They want to figure things out themselves. So no matter how much you encourage communication, in any given moment, they're the ones deciding what to do. That decision is autonomy.

Autonomy means no intervention. And that creates two opposing forces:

Take a concrete scenario. You're new to an org. You're tasked with reverse engineering firmware — specifically the peripherals. You hit a new peripheral and get stuck. Do you push through or ask for help?

Most junior engineers push through. They don't want to signal they're stuck. Sometimes that pays off. Often, they burn hours on something a five-minute conversation would have solved. My rule of thumb: no meaningful progress in two hours? Stop and ask.

But now flip it. You've been on that project a year. You know the target cold. And yet you're still being nudged to check in at every step. At some point that's not coaching — it's friction. You finish your last peripheral analysis, you see something interesting, you go explore it. You figure something out. It's genuinely useful. But it's not what the PI wanted.

This is the other failure mode. Not the junior burning cycles alone — but the experienced engineer drifting out of scope because the check-in culture never adapted to their growth.

PIs have their own styles, but ultimately they're busy. In a perfect world, their teams would operate autonomously — calibrated autonomy, where the level of independence matches the person's familiarity with the work, not just their seniority. The coaching challenge isn't "always communicate more." It's teaching people to recognize which moment they're in — and respond accordingly.