AxdaleHow I work

IndexClose

michael@axdale.com
Warsaw, Poland (CET)

Method

How I work

I work in writing. All of my planning, updates and handover are written, from the first brief to the last pull request.

Written work leaves a record. A decision in a pull request comment does not drift the way a spoken one does. You can forward it, check it later and hold me to it.

Writing also removes the time zone problem. I work from Warsaw, Poland (CET). Teams in London read my update the same afternoon, and teams in New York read it by midday.

Writing has a cost. It asks you for a clear brief and one named person who decides. I keep that cost small with short templates and questions that come with a default answer.

The more context you give me, the better I work. Links to the repo, tickets, past incidents or a short recording you made all help, and none of it is required.

In earlier client work some decisions happened in a live conversation. Now I keep every step in writing, and I do not offer meetings or video.

A heavy glass paperweight on a stack of blank paper. One straight orange line is ruled across the top sheet under the glass, with a black steel ruler beside the stack.

[2]The week

Five written steps

  1. [1]

    Brief

    You send a written brief, short or long, with whatever context you have. It says what should change for your users, where the code lives, what is out of bounds, who decides and how big the whole job is.

  2. [2]

    Plan

    I reply within one working day with a written plan. It has the goal for the week, 3 to 5 acceptance criteria, the scope, the access I need and an estimate for the paid follow-on.

  3. [3]

    Daily update

    By 18:00 CET on each working day you get a written update with six parts. Shipped, next, blocked, decisions needed from you, hours and risks.

  4. [4]

    Pull requests

    Each pull request does one thing and is small enough to review in about 20 minutes. It has tests, passing CI and a description of what changed, why, how to test it and the risks.

  5. [5]

    Review

    I answer review comments within 4 working hours. I never push to your main branch, and I do not merge my own work unless you allow it in writing.

  6. [6]

    Handover

    At the end of each week you get a report and a handover note. It covers how to run, test and change the work, the known issues, the next steps and every access I held.

[3]A daily update

One update at the end of each day

An example from the How I Work document, for a fictional client.

Daily updateBy 18:00 CET
Day 3 of 5, Week 2, SOW EXAMPLE-02

Shipped
- PR #41 eval set grown from 15 to 28 cases (review requested)
- Fixed timeout on long tickets, test added

Next
- Add the eval run as a CI gate
- Token cap per request

Blocked
- Need a staging test key with a higher spend cap (asked in issue #38)

Decisions needed from you
- Keep the 15 second limit, or allow 20 seconds for long tickets?

Hours
- 7.5 today, 23.0 of 40 this Week

Risks
- None new

[4]Response times

Warsaw, Poland (CET)

All times are Warsaw time, CET or CEST in summer. I work 09:00 to 17:00, Monday to Friday, except public holidays in Poland.

  • Reply to a new briefWithin 1 working day
  • Written plan and acceptance criteriaWithin 1 working day after the brief
  • Reply to a question or review commentWithin 4 working hours
  • Daily written updateBy 18:00 CET each working day
  • Weekly reportBy 18:00 CET on the last working day of the week
  • Handover note when the work endsWithin 2 working days
  • Notice of a security incidentWithin 24 hours

[5]Tools

Plain tools

I work inside your tools. I do not ask you to adopt new ones.

  • [1]Your GitHub or GitLab, on a branch or a fork
  • [2]Your issue tracker, or a short list in the pull request
  • [3]Email to and from michael@axdale.com for updates and approvals
  • [4]Your secret manager, or a one-time encrypted link
  • [5]Only the AI coding tools you approve in writing
  • [6]Markdown in the repository, so the documentation lives next to the code

[6]Documents

Read the rules before you start

D-01

Engagement Agreement

The main contract, with the free first week, paid weeks, ownership, confidentiality and how either side ends it.

PDF, 12 pages, 289 KBPDF Markdown
D-03

How I Work, Async

The operating manual for the brief, the plan, the daily update, pull requests, review, handover and response times in CET.

PDF, 6 pages, 235 KBPDF Markdown

All documents

Last reviewed

Next step

If an agent or LLM feature breaks in production, send me a written brief.

Start a brief

I reply in writing within one working day.

How it starts

  1. [1]Send a written brief
  2. [2]Sign the agreement
  3. [3]Week 1 starts