What School IT Taught Me About Reliability Engineering

Most people think school IT is about fixing printers, resetting passwords, and occasionally telling someone to turn it off and back on again.

While those things certainly happened, my experience taught me something much more important: reliability is not about preventing failures. Reliability is about being able to recover when failures inevitably happen.

I started volunteering with my school's IT department around age fifteen. What began as helping out gradually turned into becoming an instrumental part of the school's technology operations. Over the years I worked on computer lab management, Chromebook repairs, Windows administration, Group Policy management, registry modifications, device deployments, and a variety of projects that most students never realize exist behind the scenes.

One of the largest projects I participated in involved a six-figure technology grant that funded a major computer lab upgrade. The school purchased roughly twenty-six MSI gaming desktops along with gaming peripherals, monitors, and supporting equipment. The room ultimately represented hundreds of thousands of dollars of investment.

From the outside, students saw a room full of high-end computers.

From the inside, I learned that technology projects are rarely about the hardware. They are about deployment, maintenance, support, and keeping everything operational after the ribbon-cutting ceremony is over.

One of the biggest surprises was how much of modern education depends on systems that schools do not control.

Teachers often rely on third-party vendors, cloud services, and externally hosted platforms for instruction, testing, and classroom management. When those services experience outages, there is often very little a local IT department can do besides wait and communicate.

As a student interested in engineering, this felt backwards to me. My instinct was always to ask why critical systems were not closer to the people who depended on them. The experience gave me a greater appreciation for self-hosted infrastructure, local control, and designing systems that can be repaired quickly when something breaks.

I also discovered that students are remarkably creative adversaries.

No matter how many restrictions are implemented, students will continuously search for ways to access games, bypass filters, and reach content they should not be accessing. School IT sometimes feels like a never-ending contest between people attempting to enforce policy and people attempting to circumvent it.

The experience gave me a healthy respect for security. Not because every student is malicious, but because every system eventually encounters users who are motivated to test its limits.

One area where my opinion changed significantly was device management.

Before working in education technology, I assumed all endpoint management systems were roughly equivalent. After spending time with both Windows and Chromebook environments, I gained a much greater appreciation for centralized management. Chromebook administration and remote control capabilities made it obvious why so many schools choose that platform despite its limitations.

The lesson was not that one platform is perfect.

The lesson was that operational simplicity matters.

Perhaps the most important lesson came from watching schools operate under constant budget pressure.

Technology departments are expected to maintain reliability, support users, deploy new systems, repair old systems, and respond to emergencies while operating within increasingly constrained budgets. Good engineering in that environment is not about building the most elegant solution possible. It is about finding a way to deliver results when resources are limited.

At fifteen, I thought IT was mostly about computers.

By eighteen, I realized IT was about people.

The computers were the easy part.

Teachers needed classrooms to function. Students needed devices that worked. Administrators needed systems to stay available. Every technical decision ultimately affected somebody's ability to do their job.

That is why I no longer define reliability as "it just works."

Real reliability is being able to fix it when it doesn't.