From carrying a sample bag to shipping a platform

The thing nobody tells you about a sales job is how much of it is data that lives in the wrong place. Which accounts are slipping. What actually got used last quarter versus what got ordered. Where the next opening is before it's posted anywhere. I kept hitting the same wall: the information I needed to be good at my job existed, but it was scattered across systems that weren't built to answer my questions. So I started keeping my own records. Spreadsheets, then spreadsheets with formulas, then spreadsheets that had clearly outgrown being spreadsheets.

That's the moment the itch starts, and it's an itch you cannot outsource. Nobody was going to build the small, specific tool I needed, because the market of people who needed exactly that was one person. If I wanted it, I was going to have to make it. That's a very different motivation from "I should learn to code because it's a good career." It's "I have a problem, and the only path to the tool runs through me learning this."

The best reason to learn to build something is that you need the thing and nobody is coming to make it for you.

I did not learn to program the way a curriculum teaches it — start at the bottom, build up through the fundamentals, arrive one day at the ability to make something real. I learned sideways, dragged forward by the specific thing I was trying to make. I needed the spreadsheet to live somewhere other people could see it, so I learned enough web to put it online. I needed it to not lose data, so I learned enough about databases to store it properly. Every concept I picked up, I picked up because it was standing directly between me and the next thing I wanted the tool to do.

This is slower than a bootcamp in the early days and faster than one forever after, because you're never learning in the abstract. There's no gap between studying a thing and using it — the studying is the using. The downside is that your knowledge comes out lopsided and full of holes; there are foundational things I learned embarrassingly late because I never happened to need them. The upside is that everything I know, I know because I once needed it to ship, which means it's the knowledge that's load-bearing rather than the knowledge that was on the syllabus.

Here's the part that surprised me. I assumed my sales background was a thing to overcome — a non-technical past to apologize for. It wasn't. The instincts that made me decent at the old job are the ones that make me careful at this one. A rep learns fast that overselling is fatal: the day your product does less than you promised is the day you lose the account for good. So I build the way I sold — I'd rather undersell what a system does and have it hold up than dress it up and watch it break in front of the person who trusted it.

The other instinct is that the person on the other side of the tool is real, and stuck, and doesn't care about your architecture. In sales you can't hide behind jargon; the surgeon does not want to hear about your supply chain, they want to know if the thing works. Software has an enormous appetite for hiding behind jargon, and every time I catch myself doing it I hear the old job telling me to cut it out and say plainly what the thing does and doesn't do.

For most of the years I spent learning sideways, the ceiling on what one person could ship was real and low. A working platform needed a team — someone for the database, someone for the front end, someone to keep it running when it fell over. I couldn't hire that team, so I made smaller things and lived under the ceiling. What changed is that the ceiling moved. Now I run an autonomous command center that dispatches agents to do the work I used to do by hand, each in its own isolated git worktree so two of them can't overwrite each other's changes while they run in parallel. The thing I bring to it is the old thing: I point a capable worker at the stuck spot and check whether it actually helped.

The discipline that keeps that from turning into a mess is also borrowed from the sample bag. I don't let an agent build straight from an idea; I write the plan down and stress-test the plan before I trust it, the same way I used to rehearse the hard questions a surgeon might ask before I ever walked into the room. The tools are new. The habit — prepare, don't wing it, assume you're wrong until the thing in front of you proves you right — is the exact one the old job drilled into me, and it transfers cleanly from a case tray to a deploy.

Here is the thread that runs through the whole strange career. In sales I was the least expert person in every room, and it worked out fine, because my value was never being the expert — it was showing up, telling the truth, and leaving the other person more capable. Building software with a fleet of agents put me right back in that room. The agents know their narrow task better than I do, the same way the surgeon knew the anatomy better than I ever would. My job is not to out-know them. It is to aim them, and to verify that it actually works instead of trusting a claim that it did.

That reframing is why the sales past stopped feeling like a thing to hide. The job was never selling — it was standing between a stuck person and a capable tool and making the handoff honest. I do the identical job now, except the stuck person is often me, and the capable tool is a machine I pointed at the problem. The bag got lighter and the tools got sharper. The move is the same one I have been making my whole working life.

I tell this story deliberately, because the path I took is one the industry quietly treats as illegitimate. No degree, no bootcamp, no clean origin story — just a decade of needing tools badly enough to make them, and a lot of holes in the foundation I've been backfilling ever since. It would be easy to launder that into something tidier. But the messy version is the useful one, because it's the one that's actually available to people who think the door is closed to them.

If there's a thesis under everything I make now — the autonomous command center, the network of sites, the whole overbuilt apparatus — it's that the tools got good enough that the distance between having a problem and building the solution collapsed. I'm the proof and the guinea pig of that at the same time. A former sample-bag carrier who taught himself to ship platforms is not an inspiring exception. Increasingly, he's just what becomes possible when one motivated person picks up tools that used to require a team. I went from carrying the bag to building the thing in the bag. More people can make that walk than believe they can.