Learn by improving a piece of work

Choose one recurring task and agree what a useful result looks like.

Describe the recipient, decision or outcome, inputs, current steps and one recent example. Identify a step you could remove before adding technology.

• Names a specific recipient and outcome
• Describes the current process and a concrete example
• Defines an observable quality standard

Record a baseline from one real or synthetic example. Label estimates as estimates.

Compare one small change with your current approach.

Use an approved tool, or a synthetic example if workplace use is restricted. Run the same task both ways. Count setup, checking and corrections as part of the time.

• Uses comparable inputs and a baseline
• Records quality as well as total effort
• Documents a failure or limitation

Decide to keep, revise or stop. An unsuccessful trial is useful evidence, not a failed lesson.

Decide which work to remove, delegate, assist or retain.

Map the workflow from input to useful outcome. Remove unnecessary steps. Choose deliberately where AI executes, assists, or is excluded, and where people contribute judgment.

• Connects each retained step to an outcome
• Distinguishes delegation from assistance
• Names human decisions and accountability

Compare the redesign with a well-run AI-assisted version of the existing process. Explain why the redesign is or is not better.

Make useful work repeatable with clear context and acceptance criteria.

Write a reusable brief containing the goal, approved inputs, definitions, examples, constraints and output format. Try it with a second input and record what needs clarification.

• Provides relevant context and examples
• States constraints and acceptance criteria
• Tests a second input

Have a colleague or your future self use the brief without your explanation. Record misunderstandings.

Find the circumstances where the approach fails.

Create at least three test cases: ordinary, incomplete and conflicting input. Check claims against supplied sources. Record unsupported statements, omissions and correction effort.

• Includes difficult or incomplete inputs
• Checks claims against evidence
• Documents failures and a practical acceptance threshold

Decide which results can be used, need review or must be rejected. Do not turn three examples into a reliability percentage.

Build only as much automation as the task warrants.

Compare manual, assisted and automated options. Beginners can create a repeatable checklist; practitioners can prototype a permitted workflow; builders can implement a small tool with test data. Include ongoing costs.

• Chooses an approach for a stated reason
• Specifies inputs, outputs and review
• Tests a failure and records maintenance effort

Keep the prototype private until its permissions and intended audience are clear. A decision not to automate is a valid result.

Make failure recoverable and responsibility clear.

Write an operating note: who owns the result, who reviews it, when to stop, how to recover and what data is permitted. Simulate missing input or an incorrect output.

• Names ownership and review responsibility
• Defines stop and escalation conditions
• Demonstrates recovery from an exception

Ask the intended owner whether the operating note is usable. Use a simulated owner review if you cannot involve a colleague.

Find out whether the work is useful to someone else.

Ask an appropriate reviewer to use the output against your acceptance criteria. Sharing publicly is optional. Use a sanitized example, private review or rubric-based self-review when necessary.

• Identifies the reviewer or labels self-review
• Records specific feedback rather than praise
• Revises the work in response

Record what changed after feedback and which disagreement remains unresolved.

Separate saved effort from a useful business or career outcome.

Explain what the saved time enables, whose problem is solved, what costs remain and whether demand for the output has changed. Separate observed results from assumptions.

• Includes review, setup and ongoing costs
• Connects the work to a useful outcome
• Separates measured facts from estimates

Write a short evidence-based proposal. Do not equate time saved with revenue, higher pay or job security.

Explain what you tested and what the evidence supports.

Create a case study with the problem, baseline, approach, test cases, results, limitations and next decision. Use only claims you can support. Keep employer details private unless approved.

• Links claims to a result or artifact
• Includes limitations and failed attempts
• Distinguishes your contribution from AI assistance

Choose private storage, a manager discussion, a sanitized portfolio or optional public sharing.

Use your work to make a realistic next career decision.

For your chosen goal, prepare an internal improvement proposal, expanded-responsibility discussion, team adoption pilot or adjacent-role exploration. For a transition, check credentials, training, actual requirements and practical constraints.

• Fits the chosen goal and constraints
• Uses evidence of ability rather than an invented fit score
• Identifies the next fact to verify

Seek appropriate feedback. A conversation, revised proposal or decision to pause is a valid outcome; an offer is not required.

Update your understanding of the work without rewriting history.

Compare your starting evidence with tasks, AI use, responsibilities and goals now. Record what changed, what stayed uncertain and what signal would make you revisit your plan.

• Identifies changes using specific examples
• Retains uncertainties and contrary evidence
• Chooses a feasible next experiment

Save a dated reassessment and one next action. Resume or adjust the pace whenever circumstances change.