How I think · working method
From business context
to a working system.
My work connects business understanding, systems architecture and hands-on implementation. I take responsibility for the decisions, the build and the result your team will operate.
01 · Assemble the context
Start with what the business knows.
A request rarely contains the whole problem. The relevant context might include a customer conversation, a workflow configuration, a spreadsheet and the person who handles the exceptions.
We agree which sources I can use. I connect the business language to the records and rules, and make missing information visible. For a defined population of records, I check coverage rather than assuming a convenient sample represents the whole system.
02 · Investigate
Establish the cause before choosing the fix.
I compare the records, trace dependencies and test explanations for the behavior we can observe. The diagnosis must account for the normal case and the exceptions before it becomes a basis for change.
A report can be technically correct and answer the wrong business question. That is why the next step is often checking the starting event or the rule with the person doing the work.
03 · Decide and build
The judgment remains part of the job.
We compare an existing setting, a process change, an integration and a custom build. I design and implement the agreed change, then show it early enough for your team to challenge the behavior and the assumptions behind it.
The architecture follows the requirements: business rules, data ownership, permissions, integration behavior and ongoing maintenance. Those decisions determine whether the result will hold up in daily use.
04 · Verify
Inspect the result in the system.
The verification covers what actually happened in the system. We check the resulting records, test missing information and exceptions, and walk through the agreed case with the owner.
When a first attempt is wrong, the correction becomes part of the context for the next attempt. Speed matters alongside the quality of those checks.
An illustrative example
An invoice is missing. Where would we look?
1. Establish the event
Ask which event makes this job billable: completion, approval or a contract date. Compare that answer with the configured trigger.
2. Trace the record
Check the job’s status, its customer association and the integration response. Separate “never attempted” from “attempted and failed.”
3. Decide the change
A missing approval and a broken integration need different fixes. Choose the correction that addresses the observed cause.
4. Check the result
Use the agreed test case, inspect the invoice and linked source record, then confirm retries cannot create a duplicate. Walk the owner through recovery.
A hypothetical walkthrough of the method; it is not a client result or a recording of a live system.
What your team keeps
The reasoning belongs with the work.
The useful handover includes the context, decisions, configuration and agreed maintenance tasks. Your owner should understand what changed and how to approach the next decision.
How that fits inside an engagement →Let’s talk
What needs to work better?
What have you inherited, or what keeps getting stuck?
Tell me what is happening, what you have already tried and why it matters now. We’ll talk through the result you need and who will own it with us.
A free 30-minute conversation to identify the problem, separate what we know from what needs checking, and agree a useful next step. You’ll receive a written recap, whether or not we work together.
Included when you choose to email me.