Corporate training
Taught by the person who had to make it work.
Seven programmes for engineering teams, delivered on-site or remote. Each one comes out of an engagement on the work page — the material is what was actually used, not a curriculum assembled to fill two days.
Why this is different from a course
Most technical training is written by someone who researched the topic. This is written by someone who was accountable for the outcome — and who has been on the wrong side of the decisions being taught.
The Serenity-BDD material is the adoption that lifted sprint velocity 30% on a real delivery team. The performance module is the method that took a median response time from twelve seconds to two. The leadership module comes from building a development centre from zero to 30% of organisational revenue in six months.
Sessions run against your system wherever the format allows it. A domain-driven design workshop that event-storms a textbook example teaches the notation; one that event-storms your domain produces a service map your team will actually use.
- Formats
- On-site or remote · 2–3 days · hands-on
- Group size
- Up to 16 — beyond that the workshop stops working
- Audience
- Mid-level through principal, plus product where it helps
- Tailoring
- Programmes are combined and cut to fit a real team
- Follow-up
- Optional review sessions once the material meets production
The catalogue
Seven programmes.
- 01
Distributed Systems & Event-Driven Architecture
3 days · on-site or remote · hands-on
Why distributed systems fail, what consistency actually 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 the failure modes that only appear above a load threshold
- 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 rather than a textbook e-commerce example.
Audience
Engineers, product managers, architects — together
You leave able to
- Run an event-storming session without a facilitator present
- Identify bounded contexts from real invariants, not from the org chart
- Map context relationships and choose integration patterns deliberately
- Leave with a service map for your own system, drawn by your own team
- 03
Cloud-Native on AWS & Kubernetes
3 days · remote or on-site · lab-based
Building and operating production workloads on AWS and Kubernetes — including the operational realities that 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
- Express infrastructure as reviewable Terraform, not console archaeology
- Build CI/CD that makes rollback cheaper than fixing forward
- Set meaningful SLOs and instrument for them from the start
- 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
- Kill flaky tests at the cause rather than the retry
- Cut regression overhead without cutting regression coverage
- 05
Performance Engineering & Latency Reduction
2 days · remote or on-site · works on your system
Finding the real bottleneck. Method taken from a decomposition that moved a median response time from twelve seconds to two.
Audience
Senior engineers, architects, SREs
You leave able to
- Distinguish structural latency from hot code — and stop profiling the wrong one
- Read tail latency correctly, and design to p99 rather than to 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
- 06
AI & Automation for Engineering Teams
2 days · remote or on-site
Where machine learning and LLM-based automation genuinely pay for themselves in an engineering organisation — and where they quietly do not.
Audience
Engineering leaders, senior engineers, platform teams
You leave able to
- Assess a proposed AI use case for real, 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 profile you are signing up for
- 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 that executives fund, and writing decisions down so they survive 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 either caving or stonewalling
- Grow technical influence that does not depend on a management title
Enquire for a team
Tell us the team, not the topic.
The most useful thing you can put in this form is what the team is struggling with. The programme that fits usually turns out to be a combination, and occasionally the honest answer is that training is not what you need.
Would rather talk? Book a call