Start with the work
Begin with the process, decision or problem people already understand. The technology comes after the reason it exists.
Teaching & enablement
The build is not finished when it works.
It is finished when the people using it understand what changed, why it changed, and what to do when something goes wrong. Teaching, documentation and handover have been part of my work for years — not an extra step at the end.
In solution delivery
Workshops, demos, documentation and handover
In live teaching
Analytics, business metrics and data-informed decisions
In consulting
Translate technical choices into language clients can use
In the room
Real teaching, with real audiences.
Years of live teaching shaped how I communicate in technical work today: make the idea clear, connect it to the audience's work, and leave people able to use it without you in the room.
How I teach
Make the system understandable before making the explanation impressive.
I learned this in rooms where technical shorthand would lose the audience in minutes. The same discipline matters in architecture workshops, stakeholder conversations and technical handover.
Remove unnecessary jargon
Technical accuracy matters, but complexity should not be used as proof of expertise. Explain the idea in the simplest language that remains correct.
Use real scenarios
People engage differently when the example looks like their own workflow, their own numbers, and the decisions they actually have to make.
Leave something repeatable
A useful session should leave behind a model, runbook, checklist or way of thinking that still works after the meeting ends.
Where this shows up now
Teaching is part of architecture work.
A good solution architect has to move between technical depth and shared understanding. The system may be complex; the conversation around it should not be.
Discovery
Understand before prescribing
Ask enough questions to understand the process, users, constraints and data before turning the conversation into a technology recommendation.
Architecture
Explain the trade-off, not just the choice
Why this platform? Why this data model? What does the decision simplify, and what does it make harder? People support architecture better when they understand the reasoning.
Delivery
Show the system in the workflow
Demos make more sense when they follow the way people actually work instead of walking feature by feature through the technology.
Handover
Design for independence
Runbooks, operating notes and training reduce dependence on the original builder. I treat that as part of the architecture, not post-project cleanup.
The teaching chapter
It started outside technology — and became part of how I work in technology.
During my independent consulting years I ran live cohort training for more than 1,000 practitioners across 12 countries. The subject was business performance, analytics and using their own numbers to make better decisions.
Most of the audience was not technical. Many were working in a second language. That forced me to learn something useful: if people cannot follow the explanation, adding more detail usually makes it worse.
Today the same skill shows up differently. It helps when I explain a data model to a business stakeholder, walk users through a new application, document an operational process, or explain why an architecture decision matters beyond the technology itself.
What good handover looks like
A system should not become fragile because one person understands it.
Architecture people can follow
Enough context to understand the major components, dependencies and design decisions without reverse-engineering the system.
Runbooks for the ordinary day
What runs, when it runs, what success looks like, where failures appear, and what the first response should be.
Training tied to roles
Users do not need the same explanation as administrators, analysts or developers. Teach each group what it actually needs to operate well.
A clear path for change
Document the assumptions and boundaries so the next person knows what can change safely and what deserves another architecture discussion.
Writing is the same discipline
Explain the decision clearly enough that someone else can challenge it.
My technical writing follows the same approach: production context first, architecture decision second, trade-offs left in.