Enablement and handover

Enablement and Azure training for teams

Handover is the part of a consulting engagement most often promised and least often delivered. It usually arrives as a documentation drop and a two-hour walkthrough in the final week. Enablement is the same commitment taken seriously: sessions on your code, run by the people who wrote it, spread across the engagement rather than bolted onto the end.

Add enablement to an engagement

What this actually is

Working sessions on the code we wrote for you. Not an introduction to Terraform. A walkthrough of your modules, your pipeline, your policy set: why the management group hierarchy is shaped the way it is, what breaks if a module is changed, how to add a subscription, what the pipeline does on a pull request and what it refuses to do. Your engineers open the code and make a change during the session, with us in the room, which is the only reliable way to find out whether the transfer landed.

Azure and AI fundamentals for your teams. Targeted at the people who will live with the estate: the platform team who will run it, the developers who will deploy into it, and where relevant the analysts and data people who consume it. Content is built against your environment, so the identity model in the slides is the identity model in your tenant, and the naming convention in the exercise is yours.

Architecture review coaching. We sit in your design reviews and ask the questions we would ask ourselves: where does this store data, who can reach it, what does it cost at three times the volume, what happens when it fails, what does an auditor see. After a few cycles your architects run the review and we attend as a second opinion. The goal is that the review survives our departure, because a review process that only works when a consultant is present is not a process.

Documentation and runbooks written to be executed. Written for the person doing the task at seven in the morning, not for the person approving the invoice. Every recurring operational task has a runbook, and each one gets tested by someone from your team while we are still there to correct it.

An exit review. A session at the end of an engagement that names what the team can now do unaided, what still depends on us, and what we would recommend before that dependency becomes a problem. It is written down, including the uncomfortable parts.

Sold inside an engagement, not as a course catalog

This is a service, not a school. There is no public schedule, no course numbers, no certification track, and no seat price. Enablement is scoped as a work package inside a delivery engagement, or as a block attached to an estate we already run.

The reason is not commercial modesty. Training that is detached from your environment teaches generic Azure, and generic Azure is already taught well and free by Microsoft’s own learning material. What no course can cover is why your policy set exempts one subscription, why the network topology has an asymmetry in it, or what the team agreed in week one and forgot. That knowledge exists only inside the engagement, and it decays quickly once the people who hold it move on. Enablement is how it gets out of our heads and into yours while it is still accurate.

So the honest framing is this: if you need a training organization, we are not one and we will say so on the first call. If you need your team to be able to operate, extend and defend what was built for them, that is what this is, and it should be in the statement of work from the beginning rather than negotiated as an extra at the end.

When it happens

Enablement is spread across an engagement rather than saved for the end.

During the decisions phase. Your team is in the room when the expensive choices are made, because understanding a decision is much easier than reconstructing it from the result. The decision record is a shared artifact, not a report we hand over.

During the build. Sessions follow the work: the pipeline session happens the week the pipeline is built, the policy session the week the policy set lands. Your engineers review our pull requests, which is enablement disguised as code review and works better than either.

At handover. The runbook walkthroughs, with your team executing and us watching rather than the reverse.

After. Where an engagement continues into managed Azure, the quarterly architecture review is itself an enablement session, and the balance shifts over time from us presenting to your team presenting.

What you keep

  • Written walkthroughs of your infrastructure code, tied to the repository they describe.
  • Runbooks for every recurring task, each one tested by a member of your team.
  • The decision records, with the reasoning behind each choice rather than only the choice.
  • Session material built against your environment, in your repository, yours to reuse and edit.
  • The exit review, naming honestly what your team can do unaided and what it cannot yet.

Who this is for

Organizations that intend to own what was built for them. It matters most where an internal team is small and will inherit something more sophisticated than what it ran before, typically after an Azure landing zone, a DevOps and infrastructure as code engagement, or an AI engineering build where the operating model is new to everyone. It applies just as much on the workplace side, where the tenant governance from a Microsoft 365 digital workplace engagement has to be maintained by the people who did not design it.

Who this is not for

If you want a course catalog, scheduled classes and certification preparation, buy that from a training provider. It is a real discipline and it is not ours.

If the plan is to outsource operations permanently and the team has no intention of touching the estate, enablement is a line item nobody will use. Say so, and we will scope a managed arrangement instead of pretending a transfer is going to happen.

And if the team is not given time to attend, this fails quietly. Two hours a week is a real commitment, and an engagement where nobody is released to attend produces a well-documented estate that nobody understands.

Questions we get

Can we buy training on its own, without a project?

Only where we already know the estate, typically because we built part of it or we run it. Enablement works because the material is your code, your policy set and your architecture. Detached from that it becomes generic Azure content, which Microsoft publishes for free and teaches better than we would.

Do you prepare people for Microsoft certification exams?

No. We do not run exam preparation, we do not issue certificates, and we are not a training organization. If certification is the goal, buy it from a training provider whose whole business is passing people through an exam. Our sessions target the ability to operate and change your estate, which is a different objective.

Who runs the sessions?

The engineers and architects who did the work. Our practice does not hand enablement to a separate trainer reading someone else's notes, because the useful part of a session is the answer to the question nobody prepared for, and that answer comes from the person who wrote the code.

How much time does this take from our team?

Budget two hours per session and expect four to eight sessions over the life of an engagement, spread rather than stacked. Enablement compressed into a single week at the end is a handover ceremony, not a transfer, and people forget most of it before they first need it.

What if our team is not ready for the architecture you built?

Then that is a scoping problem and we would rather find it in week one than at handover. Sometimes the honest answer is a simpler architecture. Sometimes it is a longer enablement block, or a managed arrangement while the team grows into it. What we will not do is deliver something sophisticated, run a training session, and call the gap closed.

Do we get the material?

Yes. Recordings where the session was recorded, the written walkthroughs, the exercises and the decision records, all in your own repository. The material is written against your environment, so it stays useful after we leave rather than becoming a slide deck nobody opens.

Have a question about this work?

Three fields. An architect reads it and answers within one business day.

Every field is needed.

We reply to this address. Nothing else is sent to it.

The goal, the deadline, and what is in the way. Three lines is plenty.

What you send travels over TLS to our own Azure Function in Canada East and lands in our own Odoo CRM in Montreal. No third-party form script, no advertising cookie. We keep it to answer you, and delete it after twenty-four months if nothing comes of it. Privacy policy.

Bring us the workload. We bring the architecture.

Thirty minutes, one architect, no deck. Come with a problem and leave with an opinion you can act on.

Book a 30-minute review Write to us instead