Learning “by Osmosis”

When I started my first IT technician role the September after getting my A-Level results, I had no real idea what I was stepping into. I only knew the IT Support Office because I’d spent time hanging around it, and it was my old school, so I at least knew the people and the layout.

What I didn’t know was how much I’d learn simply by being around others. Our “team” was just the two of us, but working alongside Derek (still one of my closest mates) taught me more than any course could — not just technical skills, but the confidence to try things.

In my final week at that school, just after accepting a new job, I decided I had to complete a migration to Exchange for staff email. I’d never done one before. It resulted in me accidentally deleting every single staff member from Active Directory (who knew AD accounts and mailboxes were linked?) and uninstalling Office from every machine because Outlook had a different licence back then.

That experience was pretty typical of my early career: experimenting, breaking things, fixing them, and deploying bespoke solutions that schools genuinely needed — including a full WordPress-based learning platform for a secondary school.

Across all of that, two lessons stuck with me:

• Working closely with colleagues — bouncing ideas around and being trusted to try, succeed, and fail — is the fastest and most powerful way to learn.
• If I messed something up, it was my job to fix it.

These two things are often missing in today’s IT teams.

Mistakes now have far greater impact because schools rely on technology more than ever. And teams are rarely structured in a way that allows junior colleagues to learn “by osmosis”. There often isn’t the time, the staffing, or the breathing room.

Lourdes IT — the MSP I built within a trust — only succeeded because people gave me chances, and because we created an environment where learning could happen naturally. But as we grew, maintaining that environment became harder. Bigger teams, tighter contracts, limited onsite allocations, and increased pressure over “value for money” all meant less slack in the system and fewer opportunities for development.

And that’s the real challenge the sector faces.

We send T1 colleagues onsite and expect them to understand complex environments inside out, often alone, with minimal support. Schools expect MSPs to provide fully trained staff from day one — yet MSPs can’t charge enough to fund that development time upfront. Any colleague not on the timetable is seen as a cost, not an investment.

Apprenticeships are framed as the solution, but they only work if apprentices have time with experienced colleagues — not if they’re sent out alone and judged against the performance of a seasoned technician.

The best technicians I’ve ever worked with all had one thing in common: they had time. Time with me, or time in previous roles, to sit alongside someone, try things, break things, fix things, and grow.

So how do we rebuild that environment today?

The answer is simple — and also the hardest thing to deliver:

Time.