How I work

This page is about method, not technology. Tools are listed with the case studies. Here is how I proceed when a data project lands on the table.

• Inventory first

  I do not start with the target picture but with what exists. Which systems run, which manual processes, who depends on what. Wherever possible I capture the inventory by machine, because a list drawn from conversations always has gaps. What I have not counted, I do not know.

• Yardstick before model

  Before I build anything, I fix what it competes against. For a forecast that is the simple carry-forward. For a migration it is the original. For an automation it is the old way. The comparison is in place before the first line of code. That way nobody gets to pick the level afterwards on which the result looks good. That applies to language models too: I choose them by a measurement series against my own test corpus, not by hearsay.

• Ship small, ship whole

  I deliver in small steps, and every step brings a finished benefit. No half-built sites in production. A user who gets something new today tests it today. That is the fastest feedback I can get.

• Operations belong in the foundation

  Roles and permissions, a change log, monitoring and alerts with the full error picture are not add-ons for later. They are part of the core, because I also run what I build. Every safeguard I add afterwards was missing before, and usually someone noticed.

• Replace with a date

  A legacy system does not disappear on its own. It gets a switch-off date, and the new path must be in use before that date. Without a date, old and new run side by side, and both get maintained worse.

• Uncomfortable results go at the top

  The level on which the model loses goes in the table, not in the footnote. A component that was measured and discarded gets named. Numbers I have not measured, I do not claim. Time saved, for example: if I have not measured it, it appears nowhere.

• With the business side, not for it

  The business side decides which decision should get better. I build the path there and show whether it works. I explain results so that a managing director can read them without translation, and so that a technical interviewer can recompute them. Both must come from the same number.

• Write down what only I know

  Whoever is solely responsible is the bottleneck. Every page I document early is one question fewer that only I can answer. That goes for the operations manual, decisions and measurements. A team does not come into being because a second person arrives, but because that person can carry on without me.