One email per milestone
Say you want “an HMI” for your machine, and that’s the whole spec. No forty-page document, no ticket board. That isn’t unusual. It’s what real work looks like when you hire someone to own a problem rather than execute a document. Here’s how I keep that kind of work from spiralling, and what it looks like from your side.
The one email
I split the work into milestones so it can’t spiral. At the start of each milestone I send one email, and only one. It contains:
- Everything I might need this phase.
- The risks I already see.
- What I will build.
- How it’s accepted.
- The hard criteria for moving to the next stage.
Then I tell you that none of this blocks me, and what I need from you, by when.
What you experience
One big risk becomes small stages. I drive the work rather than waiting to be chased. You watch the milestones complete and the problems surface and get closed, one by one. There’s nothing to chase and nothing to manage, just stages completing on schedule.
Why I work like this: attention economics
I work independently full time, and my scarcest resource is attention. I’ll pay real money for anything that saves it, and I try to do the same for clients: low communication overhead, high information density. That’s why I work mainly async, by email. Taking the initiative within agreed outcomes is how I like to work, and it’s fast.
A spec is one way to reduce a project's risk. A steady record of kept promises is another, and it works even before a spec exists.
This is how I actually run contracts, written from practice. No specific client, machine or project is described.
Companion note, same vein: Why I lead with a runnable demo.