How I work with you
Team training
Team training here is designed per client rather than sold from a catalogue: the curriculum is built around what your engineers are actually stuck on, then taught as a practical multi-day course with exercises and a working codebase they keep. That is the same method as every other engagement on this site — understand the problem before deciding what gets built — applied to training. Courses delivered so far have ranged from designing and implementing microservices with .NET to full-stack .NET with Blazor, both for government engineering teams in the Gulf, in Arabic.
Practical multi-day training designed around what your team is actually stuck on — not a fixed curriculum, and delivered with a codebase they keep.
Who this is for
You need training when the problem is knowledge rather than headcount. The difference is practical: if your engineers deliver what they are asked for but the system gets harder to change every quarter, hiring another engineer gets you to the same problem faster rather than out of it.
In practice that is one of three situations:
- A team facing an architectural decision they do not have the confidence to make. Splitting into services, restructuring modules, or deciding what to build versus buy — decisions that stay deferred precisely because everyone can see what getting them wrong would cost.
- A team that knows the tools but not the boundaries. They write .NET every day, but every new feature touches every folder and nobody can say where one part of the system ends and the next begins.
- Knowledge locked in one head. A senior engineer understands the system completely and everyone else asks them. That works right up until they take leave.
I work with engineering teams at startups, SMEs, and government bodies, mostly across the Gulf and the wider MENA region.
How a course is designed
There is no course catalogue on this page, and that is deliberate. A fixed curriculum assumes your team’s problem is the average team’s problem, which it never is — and most of what gets wasted in packaged training is wasted on days spent explaining what the room already knew.
So the process starts in the same order as every other engagement on this site:
- A conversation about the real system — what was built, what has become hard to change, which decision is stuck, and what the team complains about when no one from management is in the room.
- Establishing the starting point — what everyone already knows. Misjudging this is the single most common way a day of five gets wasted.
- Building the exercises in the shape of your system — not a generic e-commerce demo. When the exercise resembles what an engineer actually works on, what they learn transfers to their work without a translation step.
- Then the slides — last, because they are the explaining tool, not the structure of the course.
What a week looks like
Five days, in person, weighted toward exercises rather than presentation. The recurring shape of a day is: a problem is posed, the solution gets built in code, and then the alternatives that were rejected get discussed and why. The rejected alternatives are the part that sticks — knowing why an option does not work is more useful than memorising the one that does.
By the end of the week the team has built something that works, together, rather than watched one person build it.
What the team keeps
- The slides — to refer back to, and to hand to whoever joins next.
- The exercises, with their solutions, so they can be repeated a month later to test what actually held.
- A working codebase built over the five days — the reference an engineer opens when the same problem shows up in your real system.
None of it is conditional on a follow-on engagement. The course stands on its own.
Courses delivered
Two practical courses, each five days, in person, in Kuala Lumpur, in Arabic, in 2026, each for a government body in the Gulf. The two curricula have almost nothing in common, which is the point: the same class of client, and two courses that overlap barely at all.
- Designing and Implementing Microservices with .NET — for a Saudi government authority. Service boundaries, data ownership across a network, what replaces the single transaction once a unit of work is distributed, and what has to exist operationally before the first service ships.
- Microsoft .NET with Blazor — Full-Stack — for an Omani government entity. Building a complete application from interface to database within the .NET ecosystem, with the boundaries that keep both ends independently changeable.
Neither body is named because there is no permission to name them. What is described here is the material and the method, which are mine to describe. Attendee counts and feedback scores are not quoted because they were not collected, and quoting them without having collected them would be an invention.
Talks
Two talks, each 30 minutes, in Arabic, at Arabic Dev Group Malaysia:
- Multi-Tenancy Architecture — the decisions settled before the first feature that cannot be reversed once real customers hold data in the system.
- How to Scale a SaaS Platform — where the bottlenecks actually appear, and why the first one is usually somewhere the team did not expect.
Both are the subject of SaaS platform development — the service backed by three platforms I founded myself.
Related reading
- What a team decides before its first microservice — the curriculum of the microservices course, written out.
- Why a small team should start with a modular monolith — the other half of that argument, and the default I build to.
Questions about this work
How is the curriculum decided?
It starts with a conversation about the system your team actually works on and where they are stuck: an architectural decision that has been deferred for months, code that has become frightening to change, or a gap between what one senior engineer knows and what everyone else does. The curriculum and the exercises are built from that. It means two courses for the same kind of client can look completely different, and they have: one of the two delivered so far was designing and implementing microservices, the other was full-stack .NET with Blazor. The method is fixed. The content is not.
Is the training delivered in person or remotely?
Every course delivered so far has been in person — five days in the same room as the team, in Kuala Lumpur, in Arabic. That is not incidental to exercise-based training: most of the learning happens when an engineer gets stuck on an exercise and the problem gets worked through on their screen, in the moment. If travel does not work for your situation, say so in the first email and we can discuss it — but I am not going to advertise a format here that I have not actually delivered.
What does the team keep afterwards?
The slides, the exercises, and a working codebase built during the five days. The codebase matters most: it is what an engineer opens two months later when the same problem appears in your real system, and it is the difference between a course that is remembered and one that changes how the team works. None of it is conditional on engaging me afterwards.
Do you train on microservices or modular monoliths?
Both, and when to choose which — that is the actual lesson. My default when building systems is a modular monolith, because most teams pay the running cost of a distributed system well before they need it. But one of the two courses delivered so far was specifically on microservices, for a team that had reached the size where they are justified. There is no contradiction: knowing when microservices are and are not warranted is the same expertise, and someone who only covers one of the two cannot train a team on either well.
What team size works, and what if my engineers are at different levels?
Mixed levels are the normal case rather than the exception, and exercise-based training handles that better than lecturing does: the senior engineer takes an exercise further, the junior one reaches the point that matters, and both are in the same discussion. What does get settled before the course is the starting point — what everyone is assumed to know already — because misjudging that is the single most common way a day gets wasted.
What language is the course delivered in?
Arabic or English. Every course delivered so far has been in Arabic, and that is not a minor detail: serious architecture material in Arabic is scarce, and a team that learns concepts in their own language discusses them in that language afterwards — which is the language they make their real decisions in. Technical terms stay in their established English forms, because translating them makes them harder to search for later, not easier.
Team training — tell me what you're working with.
Start a conversation