The founder of a product engineering firm gets the same question from three clients in one month: can your team build with AI? She has forty engineers, a tight quarter and no money set aside for training. A big course for everyone is out of the question. Doing nothing is also out of the question.
This post describes a modest, structured way to build capability inside the team, using time and attention more than money.
Start with the work, not the course
Learning sticks when it solves a problem someone has this week. Look at what your clients ask for and where your own delivery is slow. Pick two use cases only. For a firm like a product engineering company, these might be speeding up test writing and adding a search or summarising feature to a client's product. Everything else waits.
Ask each client contact what they expect from you on this topic. Many will say something modest, such as faster testing or a better support search. Knowing the real demand stops you from training for a skill nobody has asked for yet.
Find your people
- Ask for volunteers. Curiosity is a better selector than seniority.
- Include at least one delivery lead, because they decide where new methods can be used.
- Include one person who is cautious and asks hard questions about quality and risk.
- Look for those who already experiment in spare time and invite them to teach.
Aim for a small first group, perhaps one in eight of the team. Give them a clear mission and a short deadline.
Protect the time
Learning in spare moments does not happen. Set a fixed block each week, such as two hours on a Thursday afternoon, and mark it on calendars. Tell project managers that the block is not to be moved except for a real incident. The cost is time, so the decision belongs to the leadership: how many hours per person you can spare is a business choice, not a rule from any guide.
Tell the group what you expect at the end of ten weeks, in plain words. Also tell them what you do not expect: no certificate, no perfect result, no billable output from the learning block. People relax and experiment more when the goal is clear and failure is allowed.
A ten-week plan
- 1
Weeks 1 and 2: set the ground rules
Agree the two use cases, the learners and the approved tools. Check the rules for client data and tool use before anyone starts. See rules for using AI coding and writing tools.
- 2
Weeks 3 to 5: learn by doing
Each pair takes a small, real task, such as drafting test cases for a module. They record what worked, what failed and how long it took.
- 3
Weeks 6 and 7: review and repeat
A senior engineer reviews the output for quality. Pairs redo the task with what they learned and compare.
- 4
Weeks 8 and 9: write it down
Each pair writes a one-page how-to and a list of pitfalls. Keep it in the team wiki.
- 5
Week 10: teach the rest
Pairs run a one-hour session for the wider team and answer questions.
Use cheap, plentiful resources
Free documentation, public tutorials, recorded talks and vendor guides are plentiful. Your own project repositories are an even better source. Curate a short reading list for each use case, with a note about why each item is on it. Ask learners to rate each resource afterwards, and drop the poor ones. A few paid seats on a tool or a single course for the group lead may be worth it, but that is your budget decision.
Judge progress by work, not by certificates
Learner pair, use case and mentor.
Task attempted, date and a link to the output.
What worked, what did not and what was changed.
Quality check: reviewer's name and result.
Used on a live project: yes or no, and which one.
How-to written and stored: yes or no.
Session taught to the wider team: date.
Next step for this pair.A certificate shows that a course was completed. A tracker like this shows that someone applied the skill. It also gives you material for conversations about growth and for the skills record described in our competency and talent management work.
Do not forget roles beyond engineering
Delivery leads need to know where AI can safely shorten a plan and where it adds risk. Sales and pre-sales need to describe capability honestly and not promise what the team has not done. HR and recruiters need to know how the skills show up when they hire, as in our guide to hiring data engineers, analysts and data scientists. Short role-based sessions work better than one session for all.
Keep the learning once it is made
Skills leave when people leave. Keep the how-tos in a shared place, rotate who teaches, and add the new skills to your role descriptions and your learning and development process. Recognise teachers in reviews and growth discussions, since helping others learn is real work.
