First Release
A complete process for Motorola Solutions' graduate engineers: how they are prepared for, onboarded, built up on real work, released as contributing engineers, and grown, all within their first year.
Building it rightWorking across sitesEngineering with AILearning by doingFrom hired to released.
Motorola Solutions hires graduate engineers in Malaysia every year, in a market where engineers are scarce. First Release is the process that turns each graduate hire into a contributing engineer within 90 days, and keeps them growing through their first year.
It runs in five stages. Before day one, every graduate's team is prepared: a buddy and a mentor are named, starter work is screened, and tools are ready. In week one the graduate is onboarded into the mission and makes a first change. Through week 10 they build capability on real backlog items along the Version Path, with a short bench drill each week. In weeks 11 to 13 they release one real change through the full engineering process. From month 4 they grow. Not everyone is released at the same level, so each graduate gets a Feed Forward Report that tells their next owner where they are strong, what support they need, and what they should own next, with one of four support pathways.
The learning design follows Kolb's experiential learning cycle. Every two weeks each graduate builds something real, reflects on it with their buddy, learns one engineering habit in a short bench drill, and tries it on the next item, so most of the time goes into practice on real work, not into presentations.
The content is built on three priorities that follow Motorola Solutions' own direction: the quality habits of mission critical products, working across global sites and newly acquired teams, and using AI with human judgment. Everything is measured against 12 competencies. The process is light for L&D to run: Wordsburg runs the programme office, and every material is built for translation and local use from the first draft.
The starting point.
The blueprint starts from what Motorola Solutions has published about its Malaysian operations. Each point is confirmed with L&D during Discovery.
A deep engineering bench
About 1,100 engineers work at the company's R&D centre in Malaysia, one of its two largest in the world. They design radios, LTE devices, video products, and the software around them, for products used in public safety.
A steady graduate intake
Fresh graduate engineers, graduate trainees, and interns are hired in Malaysia throughout the year, where the main engineering hub faces a shortage estimated at about 60,000 skilled engineers and technical staff.
A company moving fast
Sales rose 13% in Q2 2026, the company acquired several businesses in 2025 and 2026, and the company is building agentic AI into its Assist platform, always with a person in control.
Who a First Release graduate is.
The profile describes who the programme is for. It guides the intake, sets the starting point on the competency framework, and makes clear what each graduate is being developed toward.
Typical profile. Exact roles and numbers are confirmed with L&D during Discovery.
What it builds on
- The hire: the role, team, and hiring assessment
- Induction: HR, compliance, and company orientation
- The team: its backlog, tools, and review process
- The learning platform: existing technical content
What First Release is not
- A replacement for HR induction
- A course to finish before real work starts
- A probation test
- A coding bootcamp
Where they are heading
- An independent engineer on their team
- An owner of an area of the product or codebase
- A buddy for the next intake
- The specialist or technical lead track
The profile on the competency framework
A typical graduate joins at Starting to Assisted on most competencies, and is released at Contributing, with Independent on two or more competencies as the signal of a fast track.
What First Release is designed to achieve.
- Faster first contributionEvery graduate merges a first change in week two and releases a real change by day 90, with time to contribution measured for every intake.
- Mission critical habitsBuild the habits that mission critical products demand: reading before writing, testing, and designing for failure.
- Engineers who work across sitesPrepare graduates to work with teams at other sites, time zones, and acquired companies from their first quarter.
- Engaged managers and buddiesMake managers, buddies, and mentors active developers of graduates, with a clear role, protected time, and simple tools.
- Graduates who stayGive every graduate a 12 month plan and a reason to stay, in a market where engineers are hard to replace.
Six principles behind every design choice.
Built on what Motorola Solutions runs
Uses the existing hiring process, HR induction, team backlogs, review process, tools, and learning platform, and adds what is missing.
Learned by doing, through Kolb's cycle
Graduates learn on screened items from their team's real backlog, and go around Kolb's experiential learning cycle every two weeks: build, reflect, learn, and try again.
Rated on one yardstick
The same 12 competencies are used to set the Release Plan, run every build check, release the graduate, and report.
Backed by buddies and managers
Every graduate has a named buddy and mentor, with protected time, and a manager who takes part at every stage.
Kept light to run
A programme office, a simple fortnightly rhythm, and clear owners keep the load on L&D and engineering managers low.
Localised and accessible by design
Built for translation from the start, with Build Notes in each graduate's language and materials usable on any device.
The Release Pipeline: one framework, built like engineering work.
First Release runs like a release pipeline. What Motorola Solutions already has feeds in at the top. Each graduate moves through five stages from left to right, with a key conversation at each gate. Inside the Build and Release stages, the Version Path takes them through five versions, driven by a learning loop based on Kolb's experiential learning cycle that repeats every two weeks: build, reflect, learn, and try. Underneath, one yardstick of 12 competencies is used at every build check, evaluation runs along the base, and released outcomes come out on the right.
A T shaped engineer, with clear ownership.
Good engineers are T shaped: broad craft across the top, deep product knowledge down the middle, standing on a solid foundation. First Release develops the foundation and the craft. Product and technical depth stays with each engineering team, as it does today, and is written into each graduate's Release Plan so the whole engineer is developed.
What each stage does, and what it produces.
| Stage | Purpose | Key activities | Outputs | Timing |
|---|---|---|---|---|
| 1 · Prepare | Make day one productive | Intake confirmed with talent acquisition; buddies and mentors matched and briefed; starter backlog screened; accounts, tools, and lab access requested; manager orientation | Buddy and mentor pairs; a screened starter backlog per graduate; a ready environment | 8 weeks before start |
| 2 · Onboard | Welcome the graduate and ship a first change | Welcome conversation; Mission Start with the people who use the products; Release Plan agreed; environment set up; first small change | Signed Release Plan; first commit; baseline ratings | Week 1 |
| 3 · Build | Grow capability through real work | Version Path from Check out to Integrate; eight bench drills; buddy pairing; mentor sessions every two weeks; four build checks | Changes merged; reviews given; a cross site handoff; build check records | Weeks 2 to 10 |
| 4 · Release | Prove contribution on one real change | A capstone change through design, build, test, review, integration, and release; two final drills; demo to the team; release review | A change in the release branch; release ratings; a Feed Forward Report per graduate | Weeks 11 to 13 |
| 5 · Grow | Keep growth going, and keep the graduate | Feed forward conversation; one of four support pathways; a named next owner; month 6 check in; a step up the ownership ladder | A pathway and 12 month plan per graduate; ramp and retention report; insights for the next intake | Months 4 to 12 |
It fills the gap between induction and real work.
First Release keeps the hiring process and HR induction as they are, fills the weeks where graduates usually wait for real work, and replaces a late probation judgment with evidence from week two.
Practical by design: learning through Kolb's experiential learning cycle.
First Release is not a course that comes before real work. It is built on David Kolb's experiential learning cycle: people learn best when they go around a loop of doing something real, reflecting on what happened, making sense of it, and trying again. Every two weeks, each graduate goes around this cycle on their own backlog item, so in 90 days they complete six full cycles on real engineering work.
Each stage of Kolb's cycle has a named activity, an owner, and evidence.
| Kolb stage | In First Release | What happens | Who leads | Evidence |
|---|---|---|---|---|
| Concrete experience | Build | The graduate works a real item from the team's backlog, chosen for their version, using the team's real tools and process | Graduate, with the buddy | The change, its tests, and review history |
| Reflective observation | Reflect | A 15 minute buddy debrief, the code review comments, and a short Release Log entry: what happened, and why | Graduate and buddy | Release Log entry |
| Abstract conceptualisation | Learn | A 45 minute bench drill turns the lesson into one named habit, with a worked example from a mentor and practice in pairs | Wordsburg facilitator, mentor as guest expert | Drill commitment |
| Active experimentation | Try | The graduate tries the habit on the next item, and the mentor checks it at the next session or build check | Graduate, with the mentor | Build check ratings |
Two weeks in the Review version, step by step.
An example with fictional details, to show how one turn of the cycle changes what a graduate does.
Each 45 minute drill is a small Kolb cycle of its own.
Drills are short and hands on. Most of the time goes into practice and feedback on real or sanitised engineering artifacts, not into presentation.
Eight principles, and what each one means in First Release.
Every design choice traces back to established research on how adults, and engineers in particular, learn at work.
How the 90 days are spent.
Planned programme time per graduate, about 52 hours over 13 weeks, on top of their normal backlog work.
Measured at four levels, from reaction to business results.
Evaluation follows the four levels of the Kirkpatrick model, so the programme shows not only that graduates learned, but that they work differently and the business sees the result. The full KPI list is in the Measurement tab.
Twelve competencies in four clusters: the yardstick.
The same framework is used to set each Release Plan, run every build check, release the graduate, and report to engineering leadership. One foundation cluster applies to every engineer; the other three follow Motorola Solutions' priorities.
Five levels, the same for every competency.
Graduates, buddies, mentors, and managers rate on the same five levels, using real work as the evidence. Raters are calibrated at the first build check, so a level means the same thing in every team.
Shows the competency occasionally, mostly when guided step by step.
Shows it in routine work with a buddy's help, but not yet on their own.
Shows it reliably in their own work, without prompting. The standard for release at day 90.
Shows it in unfamiliar or cross team work, and helps others do the same.
Raises the standard for the team, and others learn from them.
What each competency looks like at each level.
Each indicator describes observable behaviour at work, so ratings rest on what graduates do rather than on impressions.
What a graduate experiences, from offer to month 12.
A welcome note from the manager, the buddy's name, and a ready laptop and lab badge on day one.
Mission Start, the Release Plan agreed, and a first small change with the buddy.
Real backlog items, bench drills, reviews, and a handoff to another site.
One real change in the release branch, a demo to the team, and the release review.
A Feed Forward Report, a support pathway, a named next owner, and a step up in ownership.
Mostly through real work, then people, then formal learning.
The blend follows the widely used 70 20 10 model: most growth comes from challenging work, a good share from other people, and a smaller share from formal learning. First Release plans all three.
Real work
Starter items from the team's own backlog that grow in difficulty, a handoff to another site, and one capstone change taken all the way to release.
People
A buddy from the same team, a senior mentor, their manager, a field or support engineer in Mission Start, and the rest of their intake.
Formal learning
Ten 45 minute bench drills, a two minute Build Note every Monday in their own language, and selected content from the company's learning platform.
Five versions, ten drills, each building on the last.
The Build and Release stages follow the way engineering work actually ships: check out the code, read it, get reviewed, integrate with others, and release. Each version has two bench drills, a harder piece of real work, a smaller role for the buddy, and a build check at the end.
45 minutes: recap, a worked example from a mentor, practice in pairs on real artifacts, feedback, and one committed action.
30 minutes at the end of each version, chaired by the mentor with a Wordsburg assessor: pass, pass with warnings, or rerun.
A two minute note every Monday, in each graduate's language, that sets up the week's drill and habit.
Every version is put to work on the team's own backlog.
The starter backlog
Before day one, each manager nominates real, low risk items from the team's backlog. Wordsburg and the mentor screen them so they climb in difficulty, from a first commit to a cross team item.
A handoff across sites
In the Integrate version, every graduate works on an item that touches a team at another site, and hands work over across time zones with a note the other site can act on overnight.
The First Release capstone
In weeks 11 to 13, each graduate owns one real change through design note, build and test, review, integration, and release, then shows it to the team at the release review.
The capstone in four checkpoints
Design
A one page design note agreed with the mentor and the reviewer.
Build and test
The change built with tests written first, using approved tools.
Review and integrate
A review by two engineers and a handoff to the test team at another site.
Release
Accepted into the release branch; release note and a ten minute demo.
Build, reflect, learn, try. Every two weeks.
The learning loop is Kolb's experiential learning cycle, applied to engineering work. The full design behind it is in the Learning approach tab.
Build
Concrete experience: the graduate works a real backlog item.
Reflect
Reflective observation: buddy debrief, code review comments, and a Release Log entry.
Learn
Abstract conceptualisation: a bench drill turns the lesson into one named habit.
Try
Active experimentation: the habit is tried on the next item and checked by the mentor.
One structured conversation in each part of the journey.
| Conversation | Stage | Who takes part | Outcome |
|---|---|---|---|
| Welcome conversation | Onboard | Manager and graduate, on day one | Clear expectations and a plan for week one |
| Release Plan agreement | Onboard | Graduate, manager, buddy, and mentor, in week one | A signed Release Plan with starter items and goals |
| Mentor session | Build | Mentor and graduate, every two weeks | One adjustment and one commitment |
| Build check | Build and Release | Graduate, mentor, and a Wordsburg assessor, at weeks 2, 4, 7, 10, and 13 | Pass, pass with warnings, or rerun, with ratings |
| Feed forward conversation | Grow | Graduate, manager, mentor, and L&D, after day 90 | A support pathway, a named next owner, and a 12 month plan |
Not everyone is released at the same level. Feed forward makes that useful.
By day 90 every graduate has shipped a real change, but they arrive at different levels across the 12 competencies. Instead of a pass or fail verdict, the release review produces a Feed Forward Report: insight that looks ahead, for the person who owns the graduate next. It names their strengths, their two growth priorities, the support they need, and the next level of ownership they are ready for, so learning support continues where it is needed most.
Feedback looks back. Feed forward plans the next step.
The idea comes from Marshall Goldsmith's work on feed forward: people improve faster when the conversation is about what to do next, rather than only about what went wrong. First Release uses both: feedback during the 90 days, and feed forward at the handover.
| Question | Feedback, during the 90 days | Feed forward, at day 90 and after |
|---|---|---|
| Purpose | Improve the work in hand | Shape the next six to nine months of growth |
| Looks at | What happened on an item or in a build check | The pattern across all five versions and 12 competencies |
| Who receives it | The graduate | The graduate and their next owner: manager, mentor, and a new buddy if needed |
| Output | Review comments and build check ratings | A Feed Forward Report, a support pathway, and the next level of ownership |
| Follow up | The next item | Month 6 and month 12 reviews against the report |
One page per graduate, written for their next owner.
Prepared from the Release Log, the five build checks, buddy and mentor notes, and the pulse. Agreed with the graduate before it is shared. An example with fictional details:
Different starting points, one direction: more ownership.
The pathway decides how much learning support continues after day 90, who provides it, and how fast the graduate takes on more ownership. Pathways are reviewed at month 6, and graduates move between them as they grow.
The next level of ownership, step by step.
The Feed Forward Report names the next rung for each graduate. Each pathway climbs the same ladder, at its own pace.
45 minutes after the release review.
- 10 minLook backThe graduate shows their release and what they learned across the five versions
- 10 minName strengthsWhat to build on, with evidence from build checks
- 10 minAgree two prioritiesThe two competencies that matter most for the next six months
- 10 minChoose a pathwayThe pathway, the next owner, and the support each person gives
- 5 minSet the next rungThe next level of ownership, with a date to review it
Graduate, manager, mentor, and L&D take part. The buddy joins when the pathway continues their role.
Every intake makes the next one better.
The Feed Forward Reports are also read together. Patterns across the intake feed forward into the next intake's design: which drills to strengthen, which starter items to change, and what to brief buddies on.
Who does what.
Each activity has one accountable owner. Wordsburg carries the operational load, so L&D and engineering managers can focus on decisions and people.
Managers are part of it, at every stage.
The manager decides what work a graduate gets and how fast they grow. Every manager is oriented before the intake starts, then gets a clear role in each stage, a simple fortnightly card, and the tools to play it, in about one hour a fortnight.
Prepare
about 2 hoursNominate starter items, name the buddy, and request tools.
Onboard
about 2 hoursHold the welcome conversation and sign the Release Plan.
Build
about 1 hour a fortnightGive the next item, protect buddy time, and attend the v0.1 build check.
Release
about 2 hoursApprove the capstone, and attend the demo and the release review.
Grow
about 1 hour a monthTake ownership from the Feed Forward Report and act on the pathway.
Manager orientation
One 60 minute session before the Prepare stage ends, on site in Malaysia with a virtual option.
- 10 minSee why it mattersWhat a slow ramp costs, and why the manager makes the difference
- 15 minLearn your roleWhat managers do in each of the five stages, and how much time it takes
- 20 minPractice in pairsScreening a starter backlog and holding a short welcome conversation
- 10 minFind your toolsWhere the toolkit lives, and how the fortnightly card works
- 5 minPlan first actionsThree things to do before the graduate's first day
Kept simple after that
Managers get only what they need, when they need it.
The manager toolkit
Manager guide
Their role in each stage, what good looks like, and the time it takes.
Starter backlog guide
The eight tests for a good starter item, with examples from engineering teams.
Day one checklist
Accounts, tools, lab access, and the welcome note, ready before the graduate arrives.
Welcome conversation guide
Five questions for day one, and how to set expectations without overload.
Release Plan template
Starter items, goals from the team's domain, and agreed buddy and mentor time.
Feedback cards
Short prompts for everyday feedback, one for each of the 12 competencies.
Rating guide
How to rate each competency on evidence, with examples for each level.
Flag response playbook
What to do, and how fast, when the pulse shows a graduate stuck or overloaded.
Feed forward guide
How to read the Feed Forward Report, choose a pathway, and plan the next level of ownership.
Fortnightly card
The "this fortnight" card with three actions, linked to the live dashboard.
Engineers with a defined part to play.
Buddies
One engineer per graduate, from the same team and one to three years ahead, close enough to remember being new. A daily 15 minute check in for four weeks, then twice a week; reviews that explain the why; and introductions to people and tools. About 20 hours over 90 days, taken off their sprint load in writing, and recorded in their own development.
Mentors
One senior engineer for every four graduates. Each mentor holds a 30 minute session with each graduate every two weeks, chairs the five build checks with a Wordsburg assessor, and is a guest expert in two bench drills. About 12 hours over 90 days, supported by a mentor guide and a short briefing.
Three short labs for buddies
Being a buddy, not a fixer
What a buddy does and does not do, the meeting rhythm, and how to answer with a question.
Reviewing to teach
Review comments that explain why, and when to let a safe mistake through to learn from it.
Stepping back
Rating the graduate fairly, writing the buddy note, and what being a buddy taught them about leading.
One live view of the intake, open to stakeholders at any time.
A secure online dashboard shows the intake's progress at any moment, so engineering leadership, L&D, mentors, and managers never wait for a report. Each person sees the view that fits their role. The preview below uses illustrative figures.
Competency progress by cluster
Average level on the five level scale: baseline to latest build check
Version Path
| Version | Build check | Result |
|---|---|---|
| v0.1 Check out | Week 2 | 24 passed |
| v0.3 Read | Week 4 | 23 passed 1 rerun |
| v0.5 Review | Week 7 | 20 passed 4 warnings |
| v0.8 Integrate | Week 10 | in progress |
| v1.0 Release | Week 13 | not started |
Open flags
| Graduate | Signal | Status | Agreed action |
|---|---|---|---|
| G05 | Stuck on item for 6 days | Support | Mentor to split the item |
| G16 | Buddy unavailable, release crunch | Support | Manager names a second buddy |
| G21 | Stay score low | At Risk | Feed forward conversation this week |
Pulse trend
Intake average across confidence, workload, support, and intent to stay
This fortnight's card
- Give the cross site item for the Integrate version
- Check the buddy's load and protect their hours
- Give one piece of feedback using the feedback cards
Release Plan progress
Illustrative preview. Figures and names are examples only.
Available at any time
Online at any time, on a laptop or a phone, with a single secure sign in.
Kept current
Updated weekly from drill attendance, the pulse, and build checks, with a fortnightly summary for the steering group.
Tailored to each role
Steering group, L&D, mentors, and managers each see what they need to act on.
Private by design
Individual data is seen only by the graduate, their manager, buddy, mentor, and L&D. Others see the intake as a whole.
Who sees what
| Stakeholder | What they see | Level of detail |
|---|---|---|
| Steering group | KPIs, competency progress, Version Path results, and risks | Intake level |
| L&D | Every graduate's status, open flags, actions, and pulse trends | Individual and intake |
| Mentors | Their four graduates' build checks, ratings, and actions | Their own graduates |
| Managers | Their own graduate's progress, next actions, and the fortnightly card | Their own graduate only |
| Buddies | Their graduate's Release Plan and the next check | Their own graduate only |
| Graduates | Their own Release Plan, ratings, and upcoming drills | Their own record only |
Fifteen KPIs at four levels.
Baselines are taken from the previous graduate intake or from team history wherever possible. Targets for each KPI are agreed with L&D and engineering leadership during Discovery, once baselines are known.
| KPI | What it measures | Data source | When measured |
|---|---|---|---|
| 1 · The graduate growth in each engineer | |||
| Competency growth | Movement up the five levels across the 12 competencies | Build checks | Week 1 baseline and week 13 |
| Time to first change | Days from start to the first merged change | Team's code system | Weeks 1 to 4 |
| Release rate | Share of graduates released as contributing engineers by day 90 | Release review | Week 13 |
| Graduate confidence | Self rated confidence to work without step by step help | Pulse | Weeks 1, 7, and 13 |
| 2 · The team value to engineering | |||
| Changes merged | Changes merged per graduate in the first 90 days | Team's code system | Week 13 |
| Review rework | Review rounds needed per graduate change, against team norms | Review records | Weeks 7 and 13 |
| Escaped defects | Defects found after release in graduate changes | Defect tracker | 30 days after release |
| Manager rating | Manager's rating of the graduate's contribution to the team | Release review | Week 13 and month 6 |
| 3 · The pipeline strength of the engineering bench | |||
| Retention | Graduates still with the company | HR data | Months 6 and 12 |
| Buddy growth | Buddies rated on coaching and review, and their own next step | Buddy Record | Week 13 |
| Feed forward follow through | Pathway actions completed by the next owner, and graduates who step up the ownership ladder | Feed Forward Reports | Months 6 and 12 |
| 4 · The process health of the programme | |||
| Day one readiness | Graduates with accounts, tools, and lab access working by day 3 | Programme office | Week 1 |
| Participation | Attendance at bench drills | Programme office | Weekly |
| Buddy time | Buddy check ins held as planned | Pulse | Every two weeks |
| Response time | Flags acted on within the agreed time | Dashboard | Weekly |
When each measure is taken.
A simple cadence, with clear decision rights.
Steering group
The L&D lead, an engineering director, the talent acquisition lead, and the Wordsburg programme director. Approves the intake and starter backlog rules, reviews KPIs, and decides on changes.
Programme office
Run by Wordsburg. Schedules every drill and check, runs the pulse, keeps the live dashboard current, and produces the fortnightly report for L&D.
Team alignment
Engineering managers are kept informed through their existing staff meetings and the fortnightly card, so the programme adds no new meetings for them.
Escalation when a graduate is struggling
Keep the normal rhythm
Buddy, mentor, drills, and build checks continue as planned.
Act within one week
Buddy and mentor agree one change: a smaller item, more pairing, or a different reviewer.
Act within three days
A three way conversation with the manager and L&D; the steering group sees patterns, not names.
One programme, working for every graduate.
Built for translation
An English core in plain language, with a shared glossary of engineering terms, so translation does not mean redesign.
Localised where it counts
Build Notes, guides, and the pulse in the languages agreed with L&D, for example Bahasa Malaysia and Chinese.
Kept in English for engineering
Drills, reviews, and code stay in English, the working language of global engineering teams.
Accessible on any device
Digital materials designed to WCAG 2.1 AA, usable on a phone, with drills offered on site and virtually.
From Discovery to the month 12 report.
About 15 months for the first intake, starting with a four week Discovery that tailors this blueprint to Motorola Solutions' teams and graduate calendar.
Every action, who leads it, and what it uses.
From Discovery to month 12, each action has an owner, a timing, an output, and the materials it uses. Wordsburg prepares every material, in English and the agreed languages, and reuses Motorola Solutions' existing induction, tools, and learning platform. Select any material to see a larger preview and where it is used.
What could get in the way, and how the design handles it.
| Risk | Mitigation |
|---|---|
| Buddies are too busy to support | Buddy hours are agreed in writing and taken off their sprint load; the manager checks the load every two weeks; a second buddy is named during release crunches |
| Graduates touch safety critical code or hardware | Starter items are screened as low risk; every change goes through the team's normal review, test, and quality gates, with no shortcuts |
| Starter items are not ready on day one | Items are nominated and screened four weeks before start, with a reserve list for each team |
| Exposure of source code and intellectual property | All work stays in Motorola Solutions' systems; Wordsburg facilitators never need source code access; drills use client artifacts only with permission, and sanitised samples otherwise |
| Confidential code in AI tools | Only approved tools, under the company's AI policy; competency D2 and one drill make the rules explicit |
| A graduate falls behind | A rerun with an adjusted item, not a failure; flags reach the manager in days, not at a month 6 probation review |
| Uneven experience across teams | One yardstick, a manager orientation, and a fortnightly card keep teams consistent, and the dashboard shows where they differ |
Planning assumptions.
- One intake of 15 to 30 graduate engineers, timed to the graduate hiring calendar
- Graduates join engineering teams at Motorola Solutions sites in Malaysia
- One buddy per graduate and one mentor for every four graduates
- Mission Start and the release reviews are held on site in Malaysia
- Approved development tools, AI assistants, and the learning platform are available to graduates
- Languages for Build Notes are agreed during Discovery
To get started.
- A named L&D lead and a steering group
- The graduate intake dates, teams, and roles
- Time to contribution data from the last intake, as a baseline
- Engineering managers willing to nominate starter items
- The AI use policy and the list of approved tools
- Whether the intake uses the HRD Corp levy, and through which providers
HRD Corp
Bench drills, buddy labs, and manager orientation are training for Malaysian employees, and may be claimable against Motorola Solutions Malaysia's HRD Corp levy when a registered training provider delivers a registered course. Wordsburg confirms its delivery route, through a registered Malaysian partner, before any fee is quoted as claimable. Programme office and content production are priced separately.
Three steps to the first intake.
- 1
Review
Walk through this blueprint with L&D and an engineering director, and agree any changes to scope or emphasis.
- 2
Agree
Confirm the first intake's timing, teams, and the start of Discovery.
- 3
Discover
Four weeks to set baselines, confirm competencies and KPIs, screen the first starter backlogs, and finalise the detailed design and plan.
First Release programme blueprint, version 1.1, 12 November 2026. Prepared by Wordsburg for Motorola Solutions Malaysia. Confidential. Figures in "What we know so far" come from published sources: Digital News Asia (August 2022), Motorola Solutions results (2026), job listings (2026), and The Vibes (September 2026).