How to ask for learning time at work, with a practical one-page plan
You finish a useful course, return to a full workload and never quite find the moment to try what you learnt. The next course goes onto your list while the first one stays in your notes.
If you want to develop in coding, product or delivery, the conversation needs to include time to apply the learning. A practical request names the task, the support you need and what will make room for it.
The six-part plan below turns that conversation into a clear set of decisions. You can adapt it for a one-to-one, a development review or a discussion about taking on a new responsibility.
Choose something you can put into practice
In a Product Talk discussion published on 13 October 2026, Teresa Torres and Petra Wille challenge the expectation that a single training session will create lasting capability. Their focus on practice raises a useful question for learners: where will the new skill fit into actual work?
Start with one task you want to handle more confidently. “Learn accessibility” is broad. “Review one form with an experienced colleague and explain the changes I would recommend” gives you a starting point. Keep the first application small enough to discuss and review.
You can also choose a task beyond your current role: shadowing a research session, preparing a small data query or facilitating part of a meeting. Explain how it connects to your development, even when it will not produce an immediate business result.
Build a request around six decisions
1. Name the learning goal
Purpose: Make the skill observable.
Describe what you want to be able to do afterwards. For example: “Explain which questions an onboarding report answers and identify one question it cannot answer.” Keep course attendance and practical capability separate in the request.
2. Pick a bounded task
Purpose: Agree where you can practise.
Choose one report, screen, conversation or small piece of code. Name what is outside the exercise. A practice review of a test page does not include changing the live service. If access is unavailable, agree a fictional example rather than leaving the task undefined.
3. Ask for time and a trade-off
Purpose: Make the workload decision explicit.
Suggest a realistic slot and include preparation or review time. Ask what can move, shrink or be reassigned so the learning fits. A calendar invitation does not create capacity by itself. Treat the duration as a proposal to discuss, not a universal measure of how quickly someone should learn.
4. Identify the support
Purpose: Check that help is actually available.
Name the person or resource you need and ask whether that support can be agreed. A colleague’s review is work too. Include access requirements, a place to ask questions and any adjustments that help you participate, such as written instructions or a quieter session.
5. Decide what you will bring back
Purpose: Give the review a clear focus.
Choose a small output: an annotated example, a short explanation or a set of questions with proposed next steps. Avoid promising savings you cannot substantiate. An honest account of what remains unclear can be useful evidence of where further support is needed.
6. Arrange the follow-up
Purpose: Keep the agreement from disappearing.
Set a date to discuss what you tried, the feedback and the next opportunity to practise. If urgent work interrupts the plan, agree who will reschedule it. Repeated cancellation is a planning problem to address, not evidence that your development does not matter.
A worked example: Leila’s form review
Illustrative example: Leila is a developer who has completed an introductory accessibility module. She wants to practise reviewing a form, but her next delivery commitments already fill the week. The people, task and agreement below are fictional.
She proposes reviewing the name and email fields on a test page. Her output will be an annotated screenshot, questions and suggested improvements. A colleague with relevant accessibility experience will review her observations. The exercise covers those two fields; a wider accessibility review needs separate planning.
Leila’s request: “Could we plan 45 minutes on Tuesday for me to review those two fields, followed by 15 minutes with an agreed reviewer? I will bring the observations to our next one-to-one. Which current task could move so that time is available?”
In this example, the manager agrees to defer a non-urgent documentation tidy-up, and the colleague confirms the review slot. Leila records both decisions. If either agreement were missing, the plan would still need work. Her next step is to carry out the review and discuss the feedback.
Copy this one-page learning plan
Complete these six lines before your next one-to-one. Use the prompts to record what you and your manager agree.
- Goal: I want to be able to ___, because it supports ___.
- Practice task: I will work on ___. The boundary is ___.
- Time and trade-off: I propose ___. We will move, reduce or reassign ___.
- Support: I need ___ from ___. Access or participation needs are ___.
- Output: I will bring ___, including the questions I still have.
- Follow-up: We will review on ___. If interrupted, ___ will rearrange it.
If the answer is “not now”
Ask which part cannot be supported: the timing, cost, task, access or review. A smaller practice task might help, but some learning needs a longer uninterrupted block. Agree a specific point to revisit the request rather than repeatedly squeezing it into evenings.
If you manage people, take responsibility for the conditions around learning. CIPD’s analysis of line manager support describes a role extending beyond training attendance to opportunities to apply learning. Make access and allocation clear across the team, including for people who are less comfortable asking.
For your next conversation, choose one skill and complete the six lines. Leave with a decision about the time, the support and the work that will make room for it. That agreement gives your learning a concrete place to begin.


