A client wanted a number by the next morning. I told him he'd have to wait a week for it, and that when it came, it might be higher than what he was expecting, not lower.
He didn't love hearing that in the moment. He also didn't argue with the number once he saw the reasoning behind it.
That's closer to the real job than the picture most people carry into hiring for the Operator Seat: someone walks in, looks around, and starts producing motion right away. A plan by Friday. Answers on the next call. The actual work looks different in the first week, and it looks different again once things are actually moving. Worth being honest about both.
The Plan Nobody Asked For
The instinct in this seat isn't to produce a plan quickly. It's to refuse to produce one before you actually know what you're planning against. I spent that week doing the unglamorous version of the job: mapping the real technical build, tracing every dependency neither of us controlled yet, pricing out costs nobody had accounted for anywhere in the original scope. None of that looks like progress from the outside. What there is, instead, is an honest number.
You don't get an honest number by guessing fast. You get it by actually looking.
The deeper look didn't make the number smaller. It surfaced real costs nobody had priced: an interface for approving what an AI system would draft on its own, report costs nobody had budgeted, a dependency on a partner's process that doesn't fully exist yet. I could have kept the first number and let him feel like his instinct about "lighter scope" had been right. That's the easier conversation. It's also the wrong number, and he's the one who'd have paid for the gap.
Not the Captain. I'm Number One.
I explain the Operator Seat to people I coach the same way every time: I'm not Picard, I'm Riker. I'm not the one with the vision, that's the founder's job, and it should stay the founder's job. My job is making sure whatever they decided actually happens. It means knowing the whole ship well enough to know when "aye aye" is the wrong answer. Someone who says yes to every number and every deadline because saying no feels uncomfortable isn't filling this seat. They're just producing comfortable motion.
This is a fair question to ask: isn't that just what a good PM does, or a COO, or a trusted consultant? Some of it overlaps. But a PM tracks the tasks, not the outcome, so a change request lands as a scheduling problem instead of a scope one. A consultant advises from outside the work, then leaves before the thing they recommended actually ships or breaks. This role sits in the gap neither one covers: close enough to the daily build to catch a spec that's drifted, accountable enough that walking away isn't an option when something goes sideways.
Refusing a plan you haven't actually verified isn't insubordination. It's the entire value of the seat.
I'm not the one with the vision. I'm the one who makes sure what you decided survives contact with the actual work.
Once It's Actually Moving
Filling the Operator Seat doesn't stop being work once the build starts. The discipline just changes shape. Day to day, holding this seat means keeping the whole thing well enough in my head that I can hear a change request and know its blast radius before I say yes to it.
I watched what happens without that on a recent replatform. The plan was for the founder to personally review every spec before his team's AI agents built against it, sound, on paper. He got pulled into an urgent client fire, and nobody else on the team knew the product well enough to catch a spec that didn't match his intent. They found out only after they'd already built the wrong thing, and had to retrofit two human review gates before anything shipped again. That's what happens the moment the one person holding the whole picture becomes unavailable and there's no seat behind them. It's why every Picard needs a Riker.
The same instinct applies when the change request comes from the top. I tell the people I coach: when a founder or CEO floats a change, the job isn't to say yes because they said it, it's to walk them through what actually breaks before they say "make it so." A process tweak, a scope add, a "can we also just" - all of it sounds reasonable in isolation. Someone has to know what it actually touches and be willing to say so, to the person signing the checks. I say yes to plenty. I just don't say yes before I know what I'm actually agreeing to.
And it's not only the build itself. When something's about to launch, holding this seat means the dev side has its house in order, but also that marketing knows the date and the story, and customer service isn't blindsided by a feature they've never seen. At Azrieli, that meant staying in the loop with fulfillment, customer service, and engineering every time something major shipped, not because any one of them asked me to, but because a launch nobody's coordinating across departments isn't really a launch.
The One Question Worth Asking
None of this is a framework I could hand you in five steps, and if it were, I'd be suspicious of it, the work changes shape depending on what's actually broken. But there's one question worth asking if you're trying to tell whether someone is actually holding this seat or just performing it: what did they refuse to commit to in the first week, and what do they still push back on now that things are moving? If the answer to either is nothing, nobody's actually looking.
I won't pretend the slower version is the popular one. But the fast version, the one where someone shows up with a plan on day one and says yes to everything after, isn't filling the seat. It's just occupying it.
That takes longer than a plan by Friday. It's also the only version that ships.