Engagement Protocol

Operating Principles & Boundaries

To maintain deep focus and deliver high-integrity technical outcomes, I operate under a structured, asynchronous working model. I prioritize written clarity, rigorous logic, and systematic execution over meeting overhead and corporate rituals.

Preferred

What I take on

The situations where I do my best work, and where the return on your investment is most likely to be clear.

  • 01

    Hard Technical Problems With Real Stakes

    My work is most useful when shallow advice is not enough: prediction problems with no obvious approach, model behavior that does not match expectations, evaluation methodology that needs tightening, production systems that are fragile under load, or ML initiatives whose technical assumptions need serious scrutiny.

  • 02

    Small, Serious Teams

    I work well with technical founders, CTOs, staff-level engineers, and compact product teams who care more about getting the system right than performing innovation theater. The ideal client is pragmatic, technically literate, and willing to act on evidence.

  • 03

    Remote, Async-First Collaboration

    My best work happens through written context, clear artifacts, code, documentation, and structured review. I can work across time zones without friction when communication is explicit, archived, and focused on decisions rather than ambient availability.

  • 04

    High-Trust Advisory or Senior IC Work

    You define the objective, constraints, and success criteria; I clarify the technical path, make the trade-offs explicit, and do the work required to get there. I am most effective when given enough autonomy to investigate deeply and return with concrete recommendations or working systems.

  • 05

    Evidence Before Expansion

    I prefer engagements that begin with a bounded piece of real work: an audit, prototype, technical memo, modeling review, or architecture assessment. If the collaboration works, we expand based on evidence rather than sales momentum.

Boundaries

Where I draw the line

Saying no clearly is the only way to say yes well. These are the lines I don't cross — for your benefit as much as mine.

Narrative-Driven Math

I do not shape analysis around a predetermined narrative, investor pitch, or desired conclusion. I report what the evidence supports, including inconvenient findings. If you want confirmation theater, I am not the right fit. If you want to know whether a system will actually hold up in production, I am.

Performative Meetings

I do not join daily stand-ups, open-ended brainstorming sessions, or multi-hour status calls. My default communication is written, structured, and archived. Synchronous time is used deliberately: for scoping, complex architectural decisions, and milestone reviews.

On-Site Visits

I operate 100% remotely and do not travel for client off-sites, office visits, or in-person workshops. The work I do is best served by a stable, controlled environment that supports deep technical concentration.

Always-On Availability

I do not monitor Slack continuously or operate as an on-call responder. I work on structured schedules with clear scope, expected response windows, and protected focus time. Complex statistical and architectural problems require sustained attention; interrupt-driven work is a poor fit for that.

People Management & Org Politics

I provide technical leadership, architecture review, methodology guidance, and senior IC execution. I do not serve as a line manager: no employee 1:1s, performance reviews, hiring ownership, compensation decisions, or HR disputes.

Data Alchemy

Machine learning cannot compensate for broken data pipelines, missing telemetry, or unreliable labels. I do not take on modeling engagements when the underlying data infrastructure cannot support meaningful evaluation. If the right first step is data engineering rather than advanced ML, I will say so directly.

Process

The shape of an engagement

Every engagement is different, but the shape tends to be the same: write first, validate on a small piece of real work, and expand only after both sides have evidence the collaboration works.

  1. 01

    Initial Conversation

    We begin with a brief written exchange to ensure your problem requires my specific expertise. Synchronous calls are reserved for when real-time discussion is genuinely necessary and a mutual fit seems likely.

  2. 02

    Paid Test Run

    Within a week, you'll receive a short written proposal: scope, approach, deliverables, timeline, and a fixed fee. The test run itself is intentionally limited in scope — a bounded piece of real work that lets both of us evaluate the collaboration on evidence, not on a sales call.

  3. 03

    Mutual Review

    A structured session to evaluate the test run deliverables. We exchange honest feedback on the working relationship and make a mutual, low-pressure decision on whether to scale up the engagement.

  4. 04

    Formalizing the Work

    If we decide to continue, we agree on the scope, cadence, deliverables, and terms for the next phase. Expectations are written down before work expands.

  5. 05

    Execution & Review

    Execution is async-first. You receive high-signal written updates weekly. We hold synchronous review sessions only at major project milestones to reflect on the work, calibrate direction, and determine the next steps.

Ready?

Let's see if the problem fits.

Start a conversation →