I'm an application architect and engineering leader who's spent the better part of three decades building great software, scaling teams, and making sure nothing in the workflow is going to bring down your servers — or your company. I untangle the kind of technical debt most people politely refuse to touch — the kind that usually turns out to be a symptom of something deeper, often a security or risk posture nobody wanted to name out loud. I love the work, and it shows.
Background
I started in the late 90s — writing code and running servers in the Bay Area during the dot-com boom. That era taught me the interesting problems live at the intersection of pragmatism and ambition, and I've been drawn back to that intersection ever since through engineering leadership and architecture work — CTO, Principal Architect, Director of Engineering, Staff Architect, and the consulting engagements that show up whenever the problem is interesting and the product has real impact.
Translation
One thread that shows up in every role: I digest technical complexity quickly and turn it into language a non-technical audience can actually act on — and I make the return trip just as naturally. Engineering floor to boardroom, incident postmortem to quarterly review, architecture tradeoff to budget conversation. When leadership makes a call that looks arbitrary from the build side, I connect it to the business rationale, the risk posture, and the constraints that never show up in a ticket. When the technical side is deep in the weeds, I pull the conversation back up to what the business actually needs to decide. Most "alignment problems" I've inherited weren't culture problems or talent problems — they were translation problems nobody had time to fix.
Comfortable everywhere from the bullpen to the boardroom — and making sure both rooms are working from the same picture.
Cross-pollination
A lot of what I've done since has been moving ideas between worlds that don't usually talk to each other — dropping startup instincts (small-team ownership, tight feedback loops, ship-then-iterate product design, lightweight communication protocols) into legacy brick-and-mortar businesses that had never seen them work, and bringing hard-won operational discipline from established industries (real change management, actual runbooks, grown-up conversations about risk and security) into forward-leaning dot-coms and startups that were about to learn those lessons the expensive way. The best engineering cultures I've built came out of that cross-pollination — usually because someone finally had the patience to fix the system instead of the latest fire.
Security-first
This is the through-line — and increasingly, the reason companies bring me in.
Security-first thinking isn't a checklist you paste in at the end. It's the shape of the system from day one: access boundaries, data governance, compliance posture (GDPR, CCPA, SOC 2, and their older cousins), and the honest question of who can touch what and why. It's the least popular and least glamorous part of the job, and the part that quietly saves companies from the worst days of their lives.
But it goes further than architecture. Security concerns belong in every decision-making conversation — not just the ones with "security" in the title. Architecture reviews, vendor selection, AI tooling rollouts, hiring plans, sprint planning, budget conversations. If nobody is asking "what could go wrong, and who gets hurt when it does," you're not making a decision — you're rolling dice. I make sure that question gets asked early, plainly, and without the eye-rolling that usually kills it.
That's the work companies actually need right now. AI has compressed development cycles and multiplied the attack surface at the same time — generated code shipping without real review, credentials embedded in prompts, third-party models with unclear data handling, workflows that move faster than anyone's threat model. The vulnerabilities aren't theoretical anymore; the exploitations are in the news weekly. I'm the person you bring in to look at your entire workflow — people, process, tooling, infrastructure — and tell you honestly what's going to bring down your servers, expose your data, or end up on the front page for the wrong reasons. And then fix it before it does.
When everything is a priority, security is always the quiet casualty — until it isn't quiet anymore.
AI adoption
That same security-first instinct is why AI adoption keeps pulling me in. The market has split into two camps that are both getting it wrong: shops that refuse to touch AI at all and are quietly falling behind, and shops that are shoveling AI into every pipeline and support queue while firing the humans who understood any of it. Neither approach survives contact with a real incident.
What actually works is the boring middle — adopting AI deliberately, wiring it into workflows where it genuinely earns its keep, keeping humans in the loop where the stakes are real, and building the guardrails (data handling, model access, code review discipline, secret management, audit trails) before you turn it loose. AI has made it easier than ever to ship code nobody fully understands, introduce dependencies nobody vetted, and automate decisions nobody can explain after the fact. That's not a productivity story — that's an exploitation waiting to happen.
That's not anti-AI. That's how you get the real productivity multiplier without waking up to a breach, a lawsuit, or a codebase nobody can understand, maintain, or trust.
Remote leadership
On the operational side: I've been leading distributed teams since 2000, back when it meant developers scattered across a handful of cities and a shared IRC channel. The last twelve years have been fully remote at fully remote organizations, well before lockdowns made that trendy. I know what keeps a distributed team productive and connected, what quietly erodes it, and how to help a company go partially or fully remote without losing the culture that held people together — the trust, norms, and sense of shared purpose — or the practical habits that made the work actually function.
Distributed teams don't fail because people work remotely. They fail when leadership runs them like an office team on Zoom.
How I work
I move comfortably between the whiteboard and the terminal — still writing code, still reading the pull request, still caring about the details. But the work I find most satisfying starts further upstream: getting the full picture of what's actually broken, what constraints and criteria the business can't bend on, and what's causing the pain in the first place rather than what's merely showing up on the surface.
From there I map where things need to land — architecture, risk posture, team structure, the systems and habits that have to exist for the organization to run well — and then break that into something deliverable: incremental improvements, migration paths, and concrete changes to process and protocol that move you toward that end state without pretending you can flip a switch overnight. The goal is always a durable fix, not another round of duct tape.
What I look for in a project
I tend to get pulled toward difficult problems where there's room to think long-term and craft a bigger-picture answer — systemic issues rather than one-off emergencies. That might mean a security and risk posture that should have been part of the architecture from the start, AI adoption that needs guardrails rather than hype, foundations that need shoring up before the next growth push, or an org trying to keep its momentum while building the habits that actually scale.
The specifics change. What keeps me in is a hard problem worth understanding properly, enough context to address root causes, and the space to build something that still makes sense — and stays secure — for years to come.