I direct projects for a living.
For three decades, in three industries. The toolchain keeps changing. The job (figure out what to build, get the right people moving, ship on time) doesn’t.
For me, it’s: what do you want to do about your problem, and how can I help? Once I know what the problem is, I can help fix it. If I don’t know what the problem is, it’s hard to figure out.
Before software, I spent thirty years directing specialists on complex projects. The work was always the same: figure out what the client actually needs (which is rarely what they say they need), get a small team of experts moving in the same direction, ship on a deadline that doesn’t move. Different industries; same job.
Three to six weeks per trial, end to end. Setting up the remote operation, document management, exhibits and animation, witness prep with the expert witnesses, opening and closing prep with the lead attorneys, then setting up the courtroom and presenting the evidence to the jury. The deadline was the trial date and it never moved. This is where I learned the job.
One significant project. A residential build at industrial scale: PLCs, sensor networks, SCADA. The job was choreographing electrical, mechanical, and software people who didn’t naturally agree about what “done” meant. Same role I’d been doing. New toolchain, harder physics. It taught me what software people miss about hardware deadlines.
Same role again. This time the specialists are software. A few well-chosen ones with a deliberate plan, and me. I write the architecture, they write a lot of the code, and I do the parts that need a person. Deciding what to build, where to draw the line, how it should feel to use. The customer talks to me. Not a project manager, not an account team, not a support queue.
The thing all three jobs taught me: the writing is the work. The SCOPE document, the trial outline, the controls narrative (whatever you call it) is where the project actually gets built. Code is a transcription. So is wiring. So is animation. The hard part is upstream of all of it, in the document that says what you’re going to do.
That’s why I work fixed-price. If I’ve written the SCOPE well, the build is mostly carpentry, and the time it takes is predictable. If I’ve written the SCOPE badly, that’s on me. And I’d rather find out in week 1, in the document, than in week 5, in your inbox.
Who I work with
Trades businesses, professional services firms, small operations groups inside larger companies. People who have a software problem off-the-shelf can’t solve. Engagements run four to six weeks and replace something specific. Not “our entire stack,” but a definable sliver of it where custom is clearly the right answer.
I don’t take projects where the brief is “build us an app” without an opinion attached. The opinion is the project. If you don’t have one yet, that’s fine. The SCOPE phase is where we develop it. But we develop it before any code is written.
If your shape fits, write to me.
A few sentences about the wedge in your workflow, what you’ve tried, and what done would look like.
Get in touch →