Making Room for Career-Changers

Context

At Sky, the Get Into Tech programme brings people from other careers into engineering. Many teams wanted to help but had no capacity to take students on, and a placement with no real work helps nobody. The programme asked whether my area had work to offer.

The business case

I wrote a proposal setting out the value to the team and to the students: a branded component toolkit to give a consistent UX across departments, which was already part of my UI-lead remit. It was real work with a real customer, sized for a cohort, and useful whether or not every student stayed. Once it was approved, I was the students’ line manager, mentor and product manager for the year.

Four students delivered a library of several dozen components, a full pack for building sites. Near the end of the year they presented it to the wider department through the UI guild (Chairing a Cross-Team UI Guild), and I pitched it as the in-house starting point for UI work, with getting-started docs and core principles. Three of the four moved into engineering roles.

Growing one person: stretch work in the area they want

One student had come from a career in finance. They were highly motivated but had little confidence they could deliver, and they weren’t drawn to UI. So I put my time into backend skills instead:

• Learning resources and coding challenges pitched just beyond what they could already do, with an open door for help.
• Introductions to backend developers and a place on projects that mattered.

Within about three months they were taking ownership of tasks; by the end of the placement they owned work end to end, including API integrations and new user-management and preferences endpoints. When they started looking for jobs, they were aiming at junior roles; I pushed them to aim for mid-level, because their work already justified it. They were hired at that level.

The same pattern with a peer

Earlier, on a TV app for Channel 5, a peer at my level was new to the stack. Talking first showed where to focus: real-world React and testing. Pairing to listen, then pairing on their real tasks, then a session just on tests, then gradually handing back control. They went on to own features independently. No authority needed, just time and a plan to step back (Pair Programming).

Scaling the mentoring

As the cohort grew and my strategy work increased, one-to-one support for everyone at once wasn’t possible, and each student needed a clear sense of the next step. What helped was being explicit: sharing the expectations for a junior developer on the team and using them as a progression plan in one-to-ones, so each conversation was about closing a specific gap.

What I’d do again

• Make the placement real work. A real product with real users is what makes the experience count, for the students and for the business case.
• Stretch in the direction the person wants to grow. Motivation compounds when the work matches it.
• Pair, then hand back control. Mentoring that never steps back creates dependence, not engineers.
• Push people to aim one level higher when the evidence supports it.

What I’d do differently

Treat progression like a fitness function from day one: time-boxed pathways with measurable levels and dated goals. Nearly hit means a few small things to adopt; hit means celebrate it.

Related notes

Building and Levelling Up a UI Team · First Week in a New Codebase