Field Guide
What I Know
I've worked across four domains long enough to have an opinion in each. Sales taught me what value actually means. Customer Success and Support taught me how to read a system from the outside in. Technical Engineering is where I learned to build things that hold up under load. Agentic AI is the next axis I'm scaling on. This page is a brief tour of each, plus the one pro tip that has earned its place after every iteration.
01 / Sales
Selling is reading the room, not reading the script
Sales is where I learned that value isn't a slogan. It's a feeling you create in someone's head when they realize the thing in front of them solves a problem they actually have. I started selling gym memberships at Club16 in 2018 and stayed for four years. The product on paper was simple: a treadmill, some weights, and a monthly fee. But every conversation that closed had the same shape, and every conversation that didn't closed for the same reason. The reason was almost never price.
Most people pitch features. They list what their thing has and hope a few of those features stick. That's a script, and customers can hear scripts a mile away. The job is the opposite: figure out the one outcome the person walking in front of you is actually buying, and tie everything you say back to that outcome. Some people want to lose 30 pounds. Some people want to feel less anxious at work. Some people just want a place to be alone for an hour. The membership solves all three, but you have to know which one you're selling before you open your mouth.
I think about every technical product I touch the same way now. Customers don't care that the API has 30 endpoints. They care that the reconciliation issue that woke up their accounts team last quarter doesn't happen again. Same job, different inventory.
Stop selling the product. Sell the version of their week that exists after the product.
02 / CSS — Customer Success and Support
The support queue is the closest thing to ground truth a B2B company gets
Two letters away from the language we use to make the web look right, CSS for me means Customer Success and Support. It's what makes the customer relationship hold up after the sale. I've been on the support side at two companies. Microserve, where I ran Tier 1 tickets across enterprise environments. And Kaseya, where I now sit on the second line for ConnectBooster, an accounts receivable platform that lives entirely on API integrations.
Support gets called a cost center. That's a misread. Support is the only function in a company that has a sustained, real-time view of where the product is breaking, who it's breaking for, and what's worth fixing first. The signal in a support queue is the closest thing a B2B company has to ground truth. The companies that treat that signal as an asset move faster than the ones that treat it as overhead.
The hard part of the work isn't the tickets themselves. It's pattern recognition across them. One reconciliation error in QuickBooks isn't a bug. The same reconciliation error showing up across three customers and two PSAs in the same week is a story. The job is to read the queue like a graph and find the shape that no individual ticket shows you.
Every time you close a ticket, write the one sentence that summarizes what the customer was actually trying to do. Read those back-to-back at week's end. The roadmap writes itself.
03 / Technical Engineering
Build it locally, deploy it second, write the runbook third
Technical Engineering is the longest stretch of my landscape and the part I'm still actively widening. Three sub-disciplines fit under it for me: full-stack web development, cloud and infrastructure, and the security layer that sits across both.
Full-stack came out of the freelance work. I build commercial websites for local businesses, mostly in Next.js and TypeScript, and the constraint that shaped my style was simple: every site I ship has to load fast on a mid-tier Android phone over a slow connection, has to be hard to break, and has to rank. Three constraints, no exceptions. Anything I can't justify against those three doesn't get added.
Cloud is the next chapter and the one I'm investing in hardest right now. I'm working through AWS Solutions Architect Associate, with hands-on time across S3, EC2, IAM, and VPC, plus enterprise Active Directory and M365 admin on the Azure side. Security threads through both. I have an AWS Security credential and a Hacksplaining cert, and I think about it less as a separate domain and more as a property the rest of the system has to satisfy. If I can't explain who can read this data, who can write it, and what happens when an attacker gets one foothold, the design isn't done.
Build the thing locally first, deploy it second, write the runbook third. Skipping the runbook is what turns a working system into a fragile one.
04 / Agentic AI
Engineers who use AI will replace the ones who don't
Agentic AI is where I'm pointed next, and the one part of the landscape that didn't exist when I started my career. I've spent the last year building AI-driven workflows that run end-to-end without a human in the loop. Lead generation that scrapes, classifies, and enriches without me touching a spreadsheet. Client onboarding that takes a kickoff transcript and produces the next eight emails, the proposal draft, and the tracking sheet.
The framing that's helped me is that agentic systems are a new layer in the stack, not a feature you bolt onto an existing app. The same way the cloud rewrote what infrastructure looks like, agents are rewriting what an internal tool looks like. The companies that move first won't be the ones with the best models. They'll be the ones who figured out which workflows in their business were always procedural to begin with and just hid that fact behind humans.
I'm not bullish on AI replacing engineers. I'm bullish on engineers who use AI replacing the ones who don't. The leverage curve is too steep to ignore, and the people who internalize agentic patterns now are buying themselves a five-year head start.
Write the agent the same way you'd write a runbook for a junior teammate. If your instructions can't survive a confused junior, they can't survive an LLM either. The skill in this layer isn't prompting. It's harnessing the process.