Toward a spec that survives twelve time zones
Six years leading engineers in Pune and the Philippines taught me to write specifications for someone I could not interrupt. It turns out that is the same skill as directing an agent.
4 min read
Leading teams in Pune, and later a mix of India, the Philippines, and the US, taught me to write specifications for people I could not interrupt. Directing an agent relies on many of the same habits. The analogy has limits, and the limits matter. I am not going to pretend an agent is a junior engineer. That comparison is disrespectful to both.
One round trip per day
From June 2014 to January 2017 I was the technical lead at Zibtek for an offshore engineering team in Pune. The clients ran from startups through Adobe and Livefyre. Several engagements ran at once. Each had its own Agile cadence: planning, standups, retros, tuned per client. I built internal Laravel tools so commits and client-developer communication did not wait on me being awake.
The constraint that shaped every habit was the clock. If a question had to come back to me, the answer arrived tomorrow. Ambiguity left in the doc did not become a Slack thread. It became a lost day.
"Just ask me if you're unsure" is a manager failing to do their job. It sounds like openness. It is a transfer of the specification back onto the person with the least context for when I will be around.
At Life Happens, February 2018 through December 2023, the same constraint scaled up. The engineering team was India-based contractors, typically five and peaking at fifteen for major projects. Support sat in the Philippines. About fifteen US W-2 staff company-wide. Three continents. For a stretch I held engineering and customer success at the same time, which is a brutal way to learn that a misunderstanding in the spec becomes a misunderstanding on a phone call.
I assumed those years would be the least relevant part of my background once I was back in the editor. So far they have been the most useful.
The habits, stated plainly
Specify to the point of tedium. If a sentence can be read two ways, it will be read the expensive way.
Define done before anyone starts. "Done" is not a feeling the team reports. It is a check you wrote when you still had the whole problem in your head.
Review the artifact, never the process. I could not watch Pune work. I could read what they produced. Standups described motion. The branch described reality.
A misunderstanding is your defect. Not because the other person is infallible. Because you are the one who can still change the document before the next round trip. If they built the wrong thing, the wrongness was available in the spec and you left it there.
Writing a spec for five engineers eight time zones away is the same problem as writing a spec for an agent. One round trip. No hallway. No "can you hop on."
The mapping
Round trip becomes the context window. You get one coherent attempt, maybe a retry, not an afternoon of clarification.
The timezone gap becomes the thing everyone likes about agents and then hates: there is no interactive rescue. If you did not put it in the prompt, the run will not come ask. It will invent.
The standup becomes the transcript. Motion is cheap. The artifact is the only honest status.
I do not have a sanitized spec from Pune to paste here, and I am not going to reconstruct one from memory and call it a receipt. The receipt is the years, the constraint, and the habits the constraint forced. If I ever publish an excerpt, it will be one I can point at.
What I refuse to carry over
Agents are not junior engineers. Juniors have a persistent principal. They accumulate a track record. They can be trusted in the way a person earns trust, which is slowly, in one direction, and revocable without deleting the person. An agent has none of that. Treating the model like a new hire is how you skip the part where a new hire would have been allowed to ask.
The useful management framing is the spec, the definition of done, and the refusal to review vibes. The sloppy framing is "I manage a team of agents." I do not. I run attempts. Some of them are good.
Agents also do not push back. A good engineer in Pune would tell me the spec was impossible, or that the acceptance test described a different product. The model will cheerfully build the contradiction and tell me it is done. That is not initiative. That is the absence of a principal.
Still figuring out
I know how to write a spec for a person I cannot interrupt. I am still learning how far that document can go before the missing pushback becomes the whole risk. The discipline transferred. The trust model did not. I keep wanting the second one to come along for the ride, and it will not.
Related: Distributed teams, Context engineering, Agentic operator