Practice
How the work is structured
Most engagements start as one of these and turn into another. A proof-of-concept becomes a training course because the team needs to maintain it; an architecture review becomes ongoing mentoring because the hard part was never the diagram.
Engagements
Five ways to work together
-
Architecture consulting
Independent architectural review, system design, and technology selection for teams building distributed, data-intensive, or standards-based systems.
-
Technical training
Multi-day hands-on courses delivered on site or remotely, from AI and large language models through WebAssembly, Rust, security, and knowledge graphs.
-
Mentoring
Ongoing one-to-one and small-group mentoring for engineers and architects growing into deeper technical responsibility.
-
Technology leadership consulting
Advisory work with CTOs, VPs of Engineering, and architecture groups on technology strategy, adoption risk, and organisational readiness for emerging platforms.
-
Proof-of-concept development
Small, focused builds that answer a specific technical question before it becomes a budget commitment.
Subjects
What the training covers
Courses run one to five days, on site or remote, and are assembled per client rather than sold from a catalogue. These are the areas with existing material to draw on; a subject with published notes links through to them.
Next
Getting started
Tell me what the system does now and what it needs to do instead. That is usually enough to say whether this is a two-day course, a two-week proof-of-concept, or a conversation you should be having with someone else.