Team Enablement

We would rather you stopped calling us.

Once the first system has paid for itself, we teach your people to run it, change it and build the next one. On your real processes, in four sessions.

The handover

Watch the work move across.

Every job a running system needs doing, and who is holding it. Step through the four sessions and watch each one cross the room. The ones that move last are the ones that matter most.

DeepstillYour team

Change what it says

Add a new source

Handle a new kind of question

Read the weekly numbers

Fix an overnight failure

Ship a change to production

Judge the next candidate

We drive, you watch. We work on a real change to your own system while your people interrupt us. Nothing is a sandbox and nothing is a slide, so the questions start early.

We pair. Your team takes the keyboard and we sit next to them. The first change they ship is a real one, on a real working day, with us in the room if it goes wrong.

You drive, we watch. Your people run the whole loop and we only answer when asked. What gets asked here is exactly what goes into the runbook you keep.

You own it. We stay reachable for a month, then we stop. If the numbers hold without us, the work is finished, and the last two rows are the honest test of that.

The test is not what your team learns. It is what they ship without us in the room.

On your own system

No sandbox, no toy dataset. Every exercise is a change your company actually needs, shipped on the day.

Ends with a named owner

Somebody in your building has their name on it, knows where it runs, and has done each job once with us watching.

Optional, and always after

We never sell this next to a build. It only makes sense once something works and you can measure what it saves.

Afterwards

What your team can do on Monday.

Not a syllabus. This is the list of things that used to mean writing to us, and no longer does.

Change what it says

Adjust wording, tone and refusals, and know how to check the change did what they meant.

Feed it something new

Add a folder, a price list or a new manual, and confirm it actually landed in the index.

Read the numbers

Answered, handed over, correctly refused, and what the month cost to run.

Fix the ordinary breakages

A failed overnight run, an expired key, a source that quietly moved. The unglamorous eighty per cent.

Ship a change safely

Test it, review it, deploy it, and roll it back when it turns out to be wrong.

Judge the next candidate

Tell a real automation from an expensive one before anybody starts building it.

The format

Four sessions, and we get quieter each time.

Half a day each, spread over about a month, remote or in your office. The gap between sessions is deliberate: people need a normal working week to hit the problems worth asking about.

We drive, you watch

We work through a real change to your system while your people watch and interrupt. No slides, no exercises invented for the day.

Session one usually ends with one shipped change nobody had found time for.

We pair

Your team has the keyboard. We sit beside them and answer, but we do not reach over and take it.

The first change your team ships is a real one, on a real working day.

You drive, we watch

Your people run the whole loop themselves. We answer only when asked, and we write down every question.

What gets asked here becomes the runbook you keep afterwards.

You own it

We stay reachable for a month, then we stop. If the numbers hold without us, the work is done.

The measure of success is that the fourth session is boring.

The room

Four people, and one of them should be sceptical.

Six is the ceiling. Above that it stops being hands-on and turns into a talk, which is not the thing you are buying.

The person who owns the process

Not their manager. The one who would notice inside an hour if the system stopped.

Whoever will maintain it

Usually the most technical person available rather than an actual developer. That is normally enough.

One sceptic

Somebody who thinks this will not work. They ask what the room needs asked, and they are right more often than is comfortable.

Someone who can say yes

To wording, to access, to what gets published. Without them every session ends in a follow-up email.

If the same person is three of these, that tells you something about the company rather than about the workshop, and we will say so on the call.

The measure

One number, taken from your own ticket log.

Not a feedback form at the end of the day. We count the questions that reach us in the month before, and the same count in the month after. The gap between them is the whole report.

Questions that reach us, per week

Four sessions, about a monthThe month after

The shape above is the target, not a case study. We are a young studio and we would rather show you the definition than somebody else's graph. If the line does not bend, we run the sessions again at our own cost.

When we say no

Four reasons we turn this down.

Nobody has the time.Two half-days per person, spread over a month, is the floor. Below that people forget between sessions and you have bought a pleasant afternoon rather than a capability.

Nothing is running yet.There is no point teaching a team to maintain a system that does not exist. Build first, run it long enough to measure, then decide whether this is worth buying.

You want a certificate.We do not issue one. What you get instead is people who have shipped changes to a live system with us watching, which is a harder thing to fake and a more useful thing to have.

You would rather we stayed.Then do not book this. Enablement exists to end the relationship. If you would prefer we kept running the system, say so and we will quote that instead, honestly and probably for less.

What stays behind

Four things you keep.

The runbookWritten during the sessions out of the questions your people actually asked, not drafted by us in advance.

The recordingsEvery session recorded, so whoever joins the team in March sees exactly what the room saw.

The repositoryCode, prompts, deploy scripts and history, in your own account, with your people as the owners.

A named ownerOne person who has done every job on the list once, with us watching, and knows who to call when something is genuinely broken.

Questions

Before you book.

Can this be done remotely?

Yes, and roughly half are. On-site is better for the first session, because interrupting somebody is easier in a room than on a call, but it is not worth a flight if the diary does not allow it.

What if the person we train leaves?

That is why the runbook is written during the sessions, why every session is recorded, and why we insist on more than one person in the room. Losing somebody should cost you a week, not the capability.

Do we need developers?

No. What we hand over is meant to be maintained by whoever is most comfortable with a spreadsheet and a terminal. If you have a developer they will move faster, but the sessions do not assume one.

Can you do this for a system you did not build?

Sometimes. We have to read it first and we will charge for that reading. If it turns out to be something nobody could responsibly be taught to maintain, we will tell you that instead of taking the booking.

What if it does not work?

If the number in your ticket log does not move, we run the sessions again at our own cost. If it still does not move, the problem is not training and we say so.

Ask us after it works.

If we have built something for you and it is running, this is the conversation to have. If we have not built anything yet, start there instead and this can wait.

Book the call