Every engineering leader has launched an upskilling initiative with real enthusiasm. A course catalog gets shared. A Slack channel gets created. Week one has great attendance. By week four, a production incident, a release crunch, and a planning cycle have eaten everyone's calendar, and the initiative quietly stops.
This isn't a motivation problem. It's a design problem: the plan competed with real work and lost, because nothing protected it. A plan that survives has three properties — it's tied to a concrete business need, it has protected time, and it applies learning to real work almost immediately.
Before day one: decide what the training is for
Skip this and nothing else works. Choose one or two specific outcomes, written as capabilities the team will have that it lacks today:
- "Any engineer on the team can deploy to Kubernetes through our pipeline without platform-team help."
- "We run our own cost reviews and cut waste without an outside consultant."
- "Every analyst can build and maintain a governed Power BI report."
Then identify the business reason. When a team can explain why it needs the skill — a migration, a new product, a security finding — protected time becomes easier to defend.
Days 1–30: baseline and foundations
Assess honestly. Map current skills against what the outcome requires. A simple self-rating plus a short practical exercise reveals more than a survey. You'll almost always find uneven levels; plan for that rather than aiming one course at everyone.
Protect the time. Two to four hours per week per person, on the calendar, treated like any other commitment. If it's "whenever you have time," you have no plan. Managers need to visibly defend it.
Start with structured learning. Foundations are where instructor-led, hands-on training earns its keep: a shared vocabulary and working mental model in days rather than months of scattered reading.
Pick the real project now. Choose a small, genuine piece of upcoming work where the new skills apply — not a toy. It will anchor the next phase.
Checkpoint at day 30: Can each person complete a basic task in the new area, with guidance? Who needs more help?
Days 31–60: apply on real work
Learning that isn't used decays quickly. This phase is where it becomes skill.
- Apply the skills on the chosen project, with scope small enough to finish.
- Pair up. Pair stronger and weaker people on tasks, and rotate pairs.
- Name a mentor or technical lead whose job includes answering questions and reviewing work.
- Hold a weekly 30-minute clinic for blockers and show-and-tell. It sustains momentum and surfaces problems early.
- Review the work for the new practices, not only for correctness. Code review is one of the best teaching tools you have.
Checkpoint at day 60: Has real work shipped using the new skills? What was harder than expected?
Days 61–90: embed and measure
Turn learning into team assets. Write the runbook, the internal guide, or the template the team wished existed at the start. Teaching others is both the best test of understanding and how knowledge outlives individuals.
Share outward. A short internal talk or demo spreads the practice and builds the team's confidence.
Build it into the process. Add the practice to your definition of done, your review checklist, or your onboarding. If it isn't in the process, it will fade.
Measure against the outcome you set. Compare to the baseline from day one: task completion without help, time saved, errors reduced. We cover how to do this credibly in how to measure the ROI of technical training.
Checkpoint at day 90: Did the outcome happen? What goes into the next 90 days?
The 30-60-90 at a glance
| Phase | Focus | Time per person | Evidence of progress |
|---|---|---|---|
| 1–30 | Baseline, foundations, pick the project | 2–4 hrs/week | Basic task completed with guidance |
| 31–60 | Apply on real work, pairing, weekly clinic | 2–4 hrs/week plus project work | Real work shipped using the skills |
| 61–90 | Document, share, embed in process, measure | 1–2 hrs/week | Outcome measured against baseline |
Why plans fail, and the countermeasures
| Failure mode | Countermeasure |
|---|---|
| Deadlines swallow the learning time | Calendar-block it; manager defends it; shrink scope before cancelling |
| Content with no application | Tie everything to a real project from week one |
| One-size-fits-all training | Assess first; differentiate by level |
| No one owns it | Name a sponsor and a day-to-day coordinator |
| Learning stays with individuals | Require a shared artifact: a runbook, template, or demo |
| No evidence of success | Set the baseline and outcome before starting |
A note on the 70-20-10 rule
You'll often hear that development happens roughly 70 percent through on-the-job experience, 20 percent through other people, and 10 percent through formal courses. The exact proportions are a rule of thumb rather than hard science, but the direction is sound: formal training starts the learning, and real work and coaching consolidate it. The plan above uses each deliberately instead of hoping they happen to line up.
Don't forget the manager's role
Managers are the single largest influence on whether learning sticks. They decide whether protected time is honored, whether new practices are expected in reviews, and whether people feel safe being slow while they learn. If your leads haven't been prepared for that, consider coaching them first — our Leading Technical Teams and Coaching and Mentoring for Team Leads courses are built for it.
Make the first 30 days easier
NovuSpark designs upskilling programs around exactly this shape: a baseline, live hands-on training tailored to your tools, and follow-through on your real work rather than generic examples. Explore our For Business programs, browse the course catalog, or talk to us about a 90-day plan for your team. If you're unsure where to focus first, our post on your team already has the tools — they just don't know it is a good prompt for finding quick wins.