All insights

Technical enablement

Enablement continues after the launch.

A course, a demonstration and a useful reference do different jobs. Connecting them helps people put knowledge into practice.

Publishing learning content is a visible milestone. Someone can open a course, attend a session or find a document. That does not by itself tell us whether they can use the knowledge when a real task appears.

Through Pickado, I owned delivery of technical courses for Lenovo programmes, working with international engineers and subject-matter experts across development, review, publication and maintenance. That experience gives me a practical interest in what connects an expert’s knowledge with a learner’s next action.

I see enablement as a set of connected supports. A live explanation, a structured course and a concise reference can each help, but they should not be expected to do the same job.

Give each format a purpose

A live session offers space for questions and clarification. A course can create a structured path through unfamiliar material. A reference can help someone find a specific detail when they need it. A demonstration can make a workflow concrete.

Choosing a format should follow the task and audience. If someone needs one step during a procedure, a long recording may be difficult to use at that moment. If someone is building a new mental model, a short checklist may leave too many gaps. Neither format is inherently wrong; it may simply be carrying the wrong responsibility.

Before producing material, I would define the action it supports and the context in which it will be used. That makes it easier to decide what belongs in the main explanation, what should become a reference and what needs a conversation.

Translate expert knowledge carefully

An expert may know why a detail matters without remembering what a newcomer needs to understand first. Learning work involves making that reasoning visible while preserving technical accuracy.

A useful conversation with a subject-matter expert can therefore include more than “is this correct?” I would ask which errors are common, which conditions change the answer and what evidence someone should inspect before acting. Those questions can reveal the structure behind the facts.

The resulting material still needs review. Clear language is not a substitute for correct information, and a polished course is not evidence that every procedure has been validated. The review process should make technical responsibility explicit.

Design for the moment of use

Consider an illustrative workshop introducing a new internal tool. A successful demonstration may create interest, but the participant’s next attempt happens without the presenter beside them.

What information will they need then? A suitable first task, an example input, the expected kind of result, a list of checks and a way to ask for help may be more useful than another overview of the product’s features.

The same principle applies to technical content. A learner should be able to connect the explanation to the work, see the relevant conditions and find the source when more detail is needed. Support for that next attempt is part of the design.

Keep ownership and maintenance visible

Technical learning has a maintenance problem: the subject can change after the material has been published. Without ownership, even well-made content can become difficult to trust.

I would make the source, review date and responsible role visible in the working process. Changes should have a route back into the material. Not every update needs a new course; some require a corrected reference, a short explanation or a clearer warning about an exception.

This is also why documentation and learning should stay connected. If the two disagree, a person trying to do the right thing has to decide which one to trust. That is an operational issue as well as an editorial one.

Look beyond attendance

Attendance and completion can tell us that material was reached. They do not establish competence, adoption or business impact on their own. Those conclusions need different evidence.

A practical evaluation might ask someone to perform a representative task, explain a decision or identify when to escalate. Feedback should also make it possible to improve the learning support. These are proposed methods, not measured outcomes attributed to my historical courses.

A launch is worth recognising. My interest is in making what follows possible: a person returning to the work, finding the right support and knowing enough to act or ask a better question.

A personal perspective. The examples explain a way of thinking; they do not assert measured outcomes or confidential client details.

All insights

The next conversation

Let’s find the useful question.

Open to opportunities where technical understanding meets customers, teams and business.

Start a conversation