Method and delivery · Singapore

Our method: bring the task, keep the judgement.

We do not start with a tool tour. We start with the work your team already has to finish this month. Sessions are built around those files, and we write down what held up so people can repeat it after we leave. Judgement stays with the people who own the outcome.

Handwritten notes

The task audit

Before we teach a single instruction, we ask the group to list the work that actually repeats. Ten to twenty items is enough: a weekly status note, a customer reply category, a variance commentary, a policy question that arrives every Monday. We sit with the list and sort it into three piles. The first pile is work that can be handed to a model with a written review step. The second is work worth assisting, where a draft saves time but a person still has to decide. The third is work we leave alone.

Sorting is a conversation, not a score. We look at whether the source material is available in the room, whether an error would be easy to catch, whether the output goes outside the team, and whether the task involves personal data or a judgement the organisation would not want guessed. People often want to automate the task they dislike most. That is useful information, and it is not always the right place to start.

The third pile matters because it protects the programme. If we pretend every task is suitable, people learn a habit of pasting first and checking later. We would rather name the limits in week one. A support team may keep refund decisions with a person. A finance team may keep the final commentary on a restatement. A communications unit may keep anything that could be read as a public position. The audit becomes a shared map, and we teach against that map rather than against a generic syllabus.

Teaching in pairs

As a collective we deliver with two facilitators in the room, whether that room is on Mohamed Sultan Road, in your office, or on a video call. One person leads the concept and the shared example. The other works the room: sitting beside someone whose document will not open, helping another person tighten a constraint, noticing when a table of numbers has been treated as narrative. Adult learners stall in private. A second person in the room catches that stall before it becomes a lost hour.

The ratio matters because the work is on each participant’s own screen. A lecture can survive one voice. Supervised practice cannot. When twelve people are rewriting a real reply or a real commentary, questions arrive in clusters. One facilitator answering from the front will queue those questions and lose the people who go quiet. The second facilitator keeps the queue short and keeps the session honest: if the method does not work on the file in front of us, we change the method in the moment rather than promising it will work later.

We keep groups small enough for that pairing to be real. Hands-on sessions stay at sixteen or fewer. Leadership briefings can be larger because they are not a workshop at each desk. If a sponsor asks for thirty people in a clinic, we split the group or we decline. The pairing is the delivery model, not a nice extra when the diary allows it.

Practice over demos

Every concept is short, then we give the room fifteen to twenty-five minutes on a live file. If we are talking about including context and constraints in an instruction, people open the document they brought that week and write the instruction against that document. If we are talking about checking a draft against source material, they do the check on their own draft, not on a sample we invented for the slide.

Nobody watches a deck for two hours. We will show one worked example so the room shares a vocabulary, then we stop talking. The facilitators move. People who finish early take a second, harder version of the same task. People who need more time get it. The session ends when the group can describe, in their own words, what they will do next Tuesday without us in the chair.

This is slower than a polished demonstration, and it is the reason teams still have a routine at the thirty-day follow-up. A demo teaches recognition. Practice on your own material teaches use. We would rather cover fewer ideas and leave them installed than cover a catalogue of features that evaporate on the commute home.

Working session

Verification discipline

Most training stops at a fluent draft. We treat the draft as the beginning of the work. A source check means the participant can point at the sentence, number or quotation in the original material and show that the output matches it. If the model has added a citation, a date, a customer name or a percentage that cannot be found, that line is treated as wrong even when it sounds confident.

We teach people to look for fabricated references, rounded figures that did not come from the spreadsheet, and quotations that have been tidied until they no longer belong to the speaker. We also teach a slower check for tone and policy: would this reply commit the organisation to something the team is not allowed to promise. The checklist is written during the programme, in the team’s language, against the kinds of output they actually send.

Review has to survive after we leave. That means it is not a feeling of caution. It is a named step in the routine, with a person responsible and a rule for what happens when the check fails. Some teams add a second pair of eyes for anything that leaves the building. Some teams keep a short “do not send” list next to the prompt library. We write that into the handover so the habit is a document, not a memory of a workshop.

Confidentiality and data handling

We advise, in plain terms, on what should never be pasted into a general tool: personal data, unpublished financials, legal advice still in draft, customer identifiers, anything your existing policy already treats as restricted. We work with the policy you have. We do not replace your information-security team, and we do not ask people to route around a rule because it would make the exercise neater.

During an engagement we may look at representative documents so the teaching is real. Those documents stay in your environment unless you explicitly provide a redacted copy. We do not retain client files after the work ends. Notes we keep for delivery planning are stripped of names and figures that are not needed. Material we bring into the room, such as practice sheets and checklists, is ours.

If your organisation already licences a document-grounded assistant with access controls, we teach inside that setup. If you only have a general assistant, we spend more time on what stays out of the box. Either way, confidentiality is part of the task audit, not a slide at the end. People remember a rule they have already applied to their own Monday morning pile.

The handover pack

A programme that leaves no documentation leaves nothing. We write the pack with the group, using the language they already use for their work, so it can be edited without us. It is not a slide export. It is a short set of working papers the sponsor can put on an internal page.

  • Adapted prompt library. Instructions tied to the team’s actual document types and macro categories, written during the sessions and checked against real outputs.
  • Output review checklist. The source check, the numbers check, the quotation check, and the policy check, in the order the team agreed to use them.
  • Written routine. When the work is done, who reviews it, what happens when a check fails, and where the library lives so it does not vanish in someone’s downloads folder.
  • Do-not-automate list. The third pile from the task audit, with a sentence on why each item stays with people, so the next enthusiastic colleague does not undo the boundary.
  • Thirty-day follow-up. One session to see which parts of the routine are still in use, which prompts have drifted, and what the team wants to tighten.

We count the pack as finished when someone in the team can explain it to a colleague who missed the programme. If that test fails, we rewrite until it passes. Documentation is part of the teaching, not an appendix we send after the last workshop.

How a programme runs

The five steps below are the same shape whether you book a clinic, a six-week cohort or an embedded sprint. Depth and calendar change. The order does not. We would rather delay a start date than skip the audit, because teaching without a map produces fluent drafts and no lasting routine.

Scoping conversation

Thirty minutes with the sponsor. We ask about the function, the tools already licensed, how many people will be in the room, and which pieces of work are causing friction. You leave with a sense of fit. We leave with enough to write a short proposal covering format, dates and price.

Task audit

We collect the recurring work and sort it. Participants see the three piles before any teaching begins. The sponsor confirms which boundaries are non-negotiable. That map becomes the syllabus.

Teaching sessions

Live sessions with two facilitators. Concepts stay short. People work on the files they brought. We adjust the next session against what actually happened in this one, rather than following a script that ignores the room.

Supervised practice

In a cohort this sits between weekly sessions. In a sprint it sits in the same fortnight. People apply the method to one live recurring task. We review samples and catch the places where the routine is still theatre.

Handover pack

Library, checklist, routine, do-not-automate list, and a date for the thirty-day follow-up. The team should be able to run the next cycle without us in the chair.