Well, I’ve restarted the blog. Now for the slightly more practical announcement: I’m looking for paid work. Capitalism compels me.
I’ve been building Transpire, turning the emails, PDFs, spreadsheets, data from ERP integrations, and other assorted evidence of supply-chain activity into something people can actually use. You ordered twelve parts, the carrier says delivered, somebody counted eight, and the invoice says twelve. The software should help you deal with that. There are still four parts missing, however green the checkmark might be.
We haven’t found enough paying customers in the time we needed to. I need paid work, and I’d like to keep building software that makes someone’s day better. There’s a lot worth doing with AI inside the software, doing useful work and staying out of the way.
A fair amount of that work has involved coding agents. They write substantial amounts of software, investigate problems, run tests, and review each other’s work. I spend a lot of time figuring out what to ask them to do, questioning what they came back with, and improving the tools they have to work with. Which has turned out to be pretty interesting work in its own right.
The amusing part is how familiar some of this is. Is this benchmark measuring what we think it is? It’s certainly fast, but the database is on a RAM disk, so perhaps we should try it with the part where it actually keeps the data. Does the backup work? Well, have we restored it? I’ve been having these conversations for years. Now some of them are with agents. The questions, and quite often the answers, haven’t changed all that much.
I’ve also been working on the development process itself: the tools and instructions the agents use, how they test their work, and how we figure out whether any of it is helping. If the agents keep writing the same little scripts, perhaps those should be tools they can just use. If they can’t get the application running, they’re going to have a hard time telling whether they broke it. And if they keep ignoring the tools we already have, adding another paragraph of instructions may or may not help. This has become a fairly interesting part of building the product, and I’d like to keep doing it.
Leading engineers is work I enjoy. So is writing software. So is figuring out what we should actually be making. I’ve never really encountered a “purely technical” problem; eventually there are people involved, usually with differing ideas about what the problem was. A role that combines those things would suit me well. A role where I spend all my time managing and none of it building would be a much harder sell.
For those who know me from a different part of my life: I spent nearly fifteen years at Lex Machina, joining when the engineering team was two people and eventually leading a global engineering and product organization of more than thirty. That included building legal analytics systems, growing the team, and taking the company through acquisition and integration. Before that, there was publishing, semantic web work, and a fair amount of XML. There is always more XML.
I’m open to a few shapes this could take: another founder looking for a technical partner, a small team within an established company, or consulting on a problem that needs someone to get properly involved. Consulting might well be through Transpire LLC. The company can still do useful work even if the product hasn’t paid the bills. Interesting people with interesting problems remain a pretty good starting point.
If we’ve worked together before, I’d love to hear from you. If someone comes to mind who I should talk to, introductions would be appreciated. Thoughtful recruiters are welcome too.
My résumé is here, and you can get in touch here.
