How I Work

How I run an engagement, what I value in the work, and what working with me feels like in practice.

Philosophy

Simple beats clever. The best code is no code. The second best is automated, reproducible, and idempotent. Most "complex" problems shrink once you look at the data and narrow the scope.

Problem-Solving

• Understand first — I don't start until I understand the problem and what "done" actually means
• Data first — Most problems become clearer once you look at the data
• SQL first — Push work to the database where it belongs
• POC first — A working proof, fast — often same-day
• Narrow the scope — Half the value of an engagement is deciding what not to build
• Domain deep-dive — I invest time learning the business; context drives better calls than process does
• Details matter — Catch issues before they become problems. While others talk, I ship
• End-to-end ownership — I see problems through from discovery to production and beyond

Technical Values

• Simplicity over cleverness — Write code your future self will thank you for
• Correctness matters — Especially with data: get it wrong once and everything downstream is wrong too
• Minimal infrastructure — Don't run what you don't need
• Pragmatic tech choices — Bring in new technology when the problem demands it, not because it's fancy

Collaboration

• Direct — Clarity and honesty over politics
• Async-first, your cadence — Written updates, demos, screenshots, SQL, and data samples carry most of the work; calls, pairing, and check-ins whenever they genuinely move things faster. I match how your team runs, not the other way around
• Low coordination overhead — One person across product, backend, data, and infra means fewer handoffs and fewer meetings — not fewer conversations when they matter
• Cross-functional — Comfortable with founders, product, sales, data science, and ops
• Low ego — The best idea wins, regardless of where it comes from

Working Together

• Scope, not tickets — I'd rather own a problem than execute a backlog
• One channel, fast loops — Slack or equivalent, daily-ish written updates, and calls whenever they help
• Clean handoff by default — Code, docs, and decisions in a state your team can pick up without me
• Tell me the stakes — Money, deadlines, risks, customer pressure. Context drives better calls than process does

Embedding and Handoff

When I embed with a team, the goal is to leave it stronger than I found it — not to become a dependency.

• In your repos and your channel — knowledge transfers as the work happens, not in one final dump.
• Docs as I go — architecture notes, decisions, and a runbook written alongside the code.
• Set the bar, not just the feature — review standards and patterns the team keeps using after I'm gone.
• A clean ramp-down — a walkthrough of what shipped, why, and the known edges, so the work keeps running without me.