Turning ambiguity into programs

Most interesting work doesn't arrive as a clean spec. It arrives as a sentence: "We need better evaluations for this model," or "Can we scale this to 500 experts?" The gap between that sentence and a delivered outcome is where program management actually lives.

Here's the mental model I keep coming back to.

1. Name the ambiguity out loud

The first job isn't to plan — it's to make the fuzziness explicit. What's actually being asked? What does "done" look like? What's genuinely unknown versus just undecided? Writing this down turns anxiety into a list, and a list is something you can work.

2. Find the smallest real deliverable

Big goals hide small, shippable ones. Instead of "build the evaluation program," I look for the first thing that produces a signal: one pilot, one dataset, one workflow that a handful of experts can run end-to-end. Momentum comes from shipping something real, not from a perfect plan.

3. Design the system, not the task

The difference between doing work and scaling work is whether you build the process that lets others do it without you. The programs I'm proudest of are the ones that quietly became the default way things get done — because the system, not any single person, carries the load.

4. Keep humans in the loop

At the frontier of AI, the reliability of a model rarely comes from the model alone. It comes from the people, the review steps, and the feedback loops around it. Good programs make that human judgment a feature, not an afterthought.

That's the loop: name the ambiguity, ship something small, build the system, keep people in it. Repeat. It's not glamorous, but it's how loosely-defined goals become results — and it's most of what I do.