Understand before proposing
I spend the first part of the work understanding the need and the systems around it. Listening to the people who carry out the process reveals rules and exceptions that appear in no specification. The proposal should reflect that understanding and make clear what will be tackled first.
A focused, measurable first phase
I start with a specific process, with an agreed baseline and success criterion. Expanding the scope makes sense when the first phase’s data justifies it, not before.
AI proposes; people decide where there is risk
I define what the system decides and what a person confirms. Actions that commit the company or have consequences that are hard to reverse require validation proportionate to their risk. The system’s autonomy grows as the results support it.
Maintainable solutions
I use the platforms and components that already solve the problem. A new dependency or a more complex architecture needs a reason. The solution should be understandable to the people who will continue the work.
Verifiable progress
Every delivery should be verifiable. I define tests for important journeys and a set of reference cases that is rerun when the model or instructions change. I share what works, what is missing and which decisions need review.
Documented decisions
I explain options in terms of usefulness, maintenance cost and effect on operations. If new information changes the proposal, I share it before continuing down a path that could create unnecessary work. Documenting decisions supports collaboration and handover.
Continuous improvement from real use
Once the system is running, usage data and the team’s questions show what to improve. A new technology is worthwhile when it contributes to the problem, not for its novelty.