17: Serendippidus
In the last email (subject: Ducks in a row), we discussed why the ability to design work is becoming such a valuable skill. Because for organisations to leverage AI, they need to understand their workflows.
So, how do we ‘design work’?
Well, before we get into that, I want to start by highlighting something important. And I’m going to bold this so it really stands out:
Whether we’re designing work for humans or AI, the requirements for reliable performance are the same.
Isn’t that fascinating?
And validating.
Because if how we design work is the same for both humans and machines, everything we’ve ever learned about performance improvement suddenly becomes even more valuable.
Hence my optimism for those in L&D who prioritise performance improvement ahead of learning. Regardless of whether or not we’re AI experts (and I’m definitely not), we’re experts at the thing companies need to make AI effective.
Talk about right place, right time?!
So, let’s get back to the question - how do we design work?
Well, let’s start by considering the workflows we’ve been discussing in previous emails.
Now, the language we use for the ‘steps’ within a workflow can be confusing. There doesn’t seem to be a globally recognised taxonomy for this, so I’m going to use the word ‘task’. Meaning the individual things we do to achieve the outcome. Meaning the most granular step within a workflow.
Actually, if I were to be more precise, what we’re concerned with is not the most granular step - it’s as granular as it needs to be. We shouldn’t be deconstructing tasks for the sake of it. Because if we got really anal, we’d be listing out every mouse click and keyboard stroke. Which is helpful when you’re teaching pensioners to send an email (and I know this because my first training job was teaching ‘Computers for the Terrified’ on board cruise ships). But less helpful when you’re helping someone make a video.
And so, we should only get as granular as needed - and that’s determined by whoever we’re designing for (could be Sandra in Finance, or an agent running on Claude Opus 79.3).
So, until we’re told otherwise, let’s use the term ‘tasks’ to describe the smallest, atomic unit of activity someone must execute to progress through a workflow.
In my earlier email (subject: Guidance Inc.), I used ‘making a video’ as the workflow example:
Brainstorm video ideas
Research high ranking titles
Write script
Design storyboard
Setup camera and lighting
Record video
Edit video
Write description
Publish to YouTube
Share on socials
In that workflow, one example of a task is ‘brainstorm video ideas’. Which should probably be made more granular, but should suffice to explain the concept.
Now, to effectively design a task that can be executed to the desired standard by someone else or by our AI, we must consider what they need to execute it.
And to figure that out, let’s use our ‘making a video’ workflow as our example.
In fact, let’s get even more specific and imagine this video is helping salespeople run a great product demo (as per my earlier email in which I shared this example as a task new starters were struggling with). We might need to modify this workflow slightly (if the video is for salespeople, we wouldn’t put it on YouTube). But, the example is close enough.
Now, if we were considering everything the workflow user or AI needs to execute this workflow to the desired standard, we could group their requirements into these categories:
Context. Everything needed to understand the task - why it’s being done, intended outcome, relevant background and any inputs or dependencies.
Instruction. Guidance explaining how the task should be approached and what should be considered whilst doing it.
Guardrails. What’s needed to keep things on track, prevent errors or drift, and ensure the task stays within acceptable boundaries.
Blueprints & templates. Reusable structures and criteria that helps form the output,
Now, this is a little abstract without an example, so let’s consider what the workflow user or AI might need for our ‘brainstorm video ideas’ task:
1. Context
Purpose: Generate ideas for a video
Audience: Salespeople who deliver product demos
Intended outcome: Identify a video idea to improve delivery of sales demo
Current problem: Demos are too generic or feature-heavy
Evidence: Insights into where demos currently go wrong
2. Instructions
Focus: Generate ideas to help salespeople prepare, customise or deliver better demos
Output: Five discrete ideas
Angle: Base each idea on a specific problem or behaviour demonstrated by salespeople during demos
Selection: Identify the strongest idea and provide rationale behind decision
3. Guardrails
Scope: Focus on one specific demo problem per idea
Relevance: Every idea must help improve salespeople deliver better product demos
Exclusions: Do not repeat topics covered in previous videos
Feasibility: Make sure each idea is specific enough for one short video
4. Blueprints and templates
Template: Working title, audience problem, required behaviour change
Criteria: Specific, useful, relevant, distinct
Reference: Examples of previous video ideas in the same same format
When we start to put this level of structure around each task, we begin to see what’s needed to effectively design the work (and please note, this list is not exhaustive, it’s just an example of what could be considered).
Not only that, but writing clear instructions forms the basis of an AI prompt.So, if the tasks in question could be done by AI, we’re actually prompt engineering!
How cool is that?
But I can already hear the objections - how can we possibly do this for every task?
We’ll tackle that next.
Yours,
- Ant
