Taught by the people who had to make it work.

The catalogue

Seven programmes.

1. 01

   Distributed Systems & Event-Driven Architecture

   3 days · on-site or remote · hands-on

   Why distributed systems fail, what consistency costs, and how to draw boundaries that survive load. Taught against real production topologies.

   Audience

   Senior engineers, tech leads, architects

   You leave able to

   • Reason precisely about consistency, ordering and delivery guarantees
   • Design an event-driven topology with a transactional outbox and idempotent consumers
   • Choose between choreography and orchestration for a given invariant
   • Recognise failure modes that only appear above a load threshold
2. 02

   Domain-Driven Design in Practice

   2 days · on-site preferred · workshop

   Event storming through to bounded contexts and a service map, using the team's own domain instead of a textbook e-commerce example.

   Audience

   Engineers, product managers, architects, together

   You leave able to

   • Run an event-storming session without a facilitator present
   • Find bounded contexts from real invariants, not from the org chart
   • Map context relationships and choose integration patterns
   • Leave with a service map of your own system, drawn by your own team
3. 03

   Cloud-Native on AWS & Kubernetes

   3 days · remote or on-site · lab-based

   Building and operating production workloads on AWS and Kubernetes, including what architecture diagrams leave out.

   Audience

   Engineers and platform teams moving to or already on AWS

   You leave able to

   • Design for the failure modes of EKS, Lambda and managed data services
   • Write infrastructure as reviewable Terraform instead of clicking through a console
   • Build CI/CD where rollback is cheaper than fixing forward
   • Set useful SLOs and instrument for them from the start
4. 04

   TDD, BDD & Test Automation That Survives

   2 days · on-site or remote · hands-on

   Executable specifications with Serenity-BDD and a test suite the team trusts enough to act on. Based on an adoption that lifted sprint velocity 30%.

   Audience

   Engineers, QA engineers, delivery leads

   You leave able to

   • Write acceptance criteria that compile and run
   • Build a layered suite where each level earns its execution time
   • Fix flaky tests at the cause, not with a retry
   • Cut regression overhead without cutting regression coverage
5. 05

   Performance Engineering & Latency Reduction

   2 days · remote or on-site · works on your system

   Finding the real bottleneck. The method comes from a decomposition that took median response time from twelve seconds to two.

   Audience

   Senior engineers, architects, SREs

   You leave able to

   • Tell structural latency from hot code, and stop profiling the wrong one
   • Read tail latency correctly and design to p99 instead of the mean
   • Apply decomposition and caching where they help, and refuse them where they do not
   • Build a repeatable performance-investigation method for the team
6. 06

   AI & Automation for Engineering Teams

   2 days · remote or on-site

   Where machine learning and LLM automation pay for themselves in an engineering organisation, and where they do not.

   Audience

   Engineering leaders, senior engineers, platform teams

   You leave able to

   • Assess an AI use case for measurable value before committing
   • Design LLM-backed automation with evaluation and failure handling built in
   • Automate process work (triage, review, documentation) with guardrails that hold
   • Understand the operating cost and latency you are signing up for
7. 07

   Architecture for Senior Individual Contributors

   2 days · on-site preferred

   The part of the staff-plus role nobody trains for: making a technical case executives fund, and writing decisions down so they outlast you.

   Audience

   Staff, principal and aspiring principal engineers

   You leave able to

   • Write an architecture decision record that is still useful in two years
   • Build and present a technical case that secures executive buy-in
   • Handle trade-offs across teams without caving or stonewalling
   • Build technical influence that does not depend on a management title