About

How I work

Keep what’s familiar, remove the bottleneck

The more a solution changes how a team works, the more resistance it meets, and the less patience people have for the next one. So I change as little of the visible process as I can. The spreadsheet, the inbox and the handoff stay where they are. What changes is the manual work behind them.

I ask three questions on every project:

1. What stays familiar?
2. What tedious work goes away?
3. What does anyone have to learn or do differently?

If the answer to the third question is long, I look for another design.

Start with the work, not the request

Most of my projects start with a goal from leadership and a process nobody fully owns. It was usually inherited, it’s partly documented, and it’s spread across a few people who each know their own piece.

So before building anything:

• I talk with the people who do the work.
• I map what actually happens, step by step.
• I look at the real data.

The original request is often a symptom of a different bottleneck, and finding that is most of the job. Part of working independently is knowing when to confirm a requirement with leadership instead of building on an assumption.

Pick the tool that fits the workflow

• Excel Office Scripts and macros when the work already happens in a spreadsheet people use.
• Power Automate for schedules, email, files, and steps that should run in the background.
• Python for structured processing and repeatable calculations.
• Claude skills with embedded Python when people benefit from asking in plain language but the result has to be exact. The model handles the conversation, and code handles the numbers.

Where AI fits in a workflow

When AI is part of the tool people use, I keep defined operations in code. A model is good at interpreting a request. It shouldn’t be doing arithmetic that has to be right every time. Running those steps in Python makes them repeatable and testable, and aims to cut the tokens each request uses.

Tests and context

Every rule gets a test, and changes go to copies of a file before the real one. Each project also has a context document with:

• the requirements;
• the decisions and the reasons for them;
• known limits;
• a dated change log.

That way the next change starts from what’s true now, not from memory.

Rollout and handoff

• Before launch: I test on copies of the real files.
• After launch: a monitoring period. The team owns the daily work from day one, and I fix what comes up.
• At handoff: the context document goes with the system, so whoever maintains it next has the same picture I did.

How figures on this site are labeled

Every outcome figure on this site carries one of three labels:

• Measured: counted or timed, over a stated period.
• Estimated: calculated by a stated method, such as minutes per task × how often it happens. The method is given next to the number.
• Illustrative: invented numbers, like everything in the demos.

I report time and capacity, not dollars, unless a dollar figure was actually measured. Where there’s no baseline, I say so instead of guessing.

Research entry types

Every research entry carries one type tag:

Working paper

A full argument with data, methods and limits, not yet peer-reviewed.

Data brief

One question answered with one dataset.

Benchmark

Several methods compared on the same task and data.

Experiment

A test I designed: a hypothesis, the setup and what held up.

Every entry also states its question, method, data and status up front, and its figures carry the same three labels as above.

Contact

Email contact@jeremyburris.com, or find me on LinkedIn and GitHub.