The Generational Divide in IT

6 min read

There is a very specific feeling that hits your stomach when the monitoring board lights up red. You could just be sitting there sipping your coffee on a quiet Tuesday morning, and suddenly a massive client network completely drops off the map. It is absolute chaos for those first few minutes. Everyone scrambles to figure out what just happened. Watching how different technicians handle that initial moment of panic has become somewhat of a hobby of mine lately. I spend so much time putting together content for 404 and More that I end up analyzing exactly how Tier 1 and Tier 2 techs process crisis information. You can almost instantly tell exactly what era of IT someone grew up in based entirely on their very first instinct during an outage.

You have the old guard. These are the veterans who have been in the trenches since the days of Windows NT and physical tape backups. The second a site goes offline they immediately want to start tracing physical paths. Their brain goes straight to the hardware sitting in a dusty rack somewhere in a poorly ventilated back closet. They want to check the physical blinky lights on the switch. They are mentally ready to console into a device using a baby blue rollover cable that they have kept coiled in their backpack for over a decade. They rely entirely on their gut and a very specific set of command line prompts they memorized back in 2004. There is an undeniable comfort for them in knowing that a physical box exists and can literally be kicked if absolutely necessary. They understand the fundamental routing logic in their sleep. They will sit there and trace MAC addresses across switch ports all afternoon if you let them. To them a problem is not real unless it has a blinking amber light attached to it.

Then you turn around and look at the new blood. The newer technicians have a completely different approach to the exact same outage. Their first instinct is never physical. They immediately pull up the remote monitoring dashboard. They are opening up cloud logs and checking to see if an API integration broke somewhere between the firewall and the management portal. They grew up in an environment where everything is abstracted behind a shiny web interface. The physical location of the hardware is completely irrelevant to them. They just want to know what the telemetry data is saying. If there is no alert in the logging system then the problem simply does not exist yet in their minds. They look at networks as a collection of software services rather than a pile of copper wires and metal chassis.

It is honestly hilarious watching these two mentalities collide in the middle of a high pressure situation. They secretly drive each other absolutely crazy. But the truth is you need both of them to survive in this industry today.

I see it happen all the time. The newer techs will enter a state of sheer panic when a graphical user interface goes down. They are so used to clicking neat little buttons to manage environments that a broken web portal feels like an absolute dead end. They literally do not know the command line equivalent to restart a stuck service. They will sit there mashing the refresh button on the dashboard while the client is losing thousands of dollars an hour waiting for a resolution. They are brilliant when the tools work but completely paralyzed when the abstraction layer fails.

Meanwhile the older techs have their own massive blind spots. They will completely refuse to trust the dashboard data. I have literally watched a senior admin insist that we need to dispatch a field technician to physically reboot a server. The only problem was that we had migrated that specific server out of the client closet and into Azure three years ago. The physical box was decommissioned and turned into scrap metal long before this outage ever happened. But their muscle memory is so heavily tied to physical infrastructure that they temporarily forgot we are operating in a hybrid cloud world now. They wanted to touch something that only existed as a line of code in a datacenter hundreds of miles away.

There is a scenario that plays out in almost every MSP that perfectly captures this exact dynamic. A junior tech will encounter a relatively basic problem on a workstation. Instead of just doing the simple thing they will spend four hours writing an elaborate PowerShell script to automate the fix. They want to push this script through the RMM to resolve the issue elegantly across the entire tenant. It is technically a very impressive use of modern automation. While they are busy testing variables and fixing syntax errors the senior admin just walks into the network closet and power cycles the modem. The problem is fixed in thirty seconds.

I laugh about it but it highlights a really important shift in how we handle technical education today. We are pushing so much cloud infrastructure and automation theory that we are losing some of the brass tacks fundamentals. You need that old school guy who knows how a packet actually travels across a physical wire. You need the person who knows exactly what to do when the fancy API completely stops responding.

But you also cannot run a modern managed service provider on pure stubbornness and rollover cables. The environments we manage now are simply way too complex. You absolutely need the junior tech who understands how to read a JSON payload and parse cloud audit logs. You need the kid who knows how to script mass deployments because doing it manually by logging into every single physical box is just not economically viable anymore.

It creates this really weird tension on the help desk. The senior guys think the juniors are way too dependent on shiny software tools. The juniors think the seniors are hopelessly stuck in the dark ages. Getting them to actually communicate effectively is half the battle of running a support team. I usually find that the best troubleshooting happens when you force them to sit at the exact same desk. The veteran can explain the underlying routing concept while the junior guy figures out how to query the log data to prove the theory.

That uncomfortable middle ground is exactly where the magic happens. You take the raw foundational knowledge of 2004 and you combine it with the massive scale of modern automation. It is definitely a messy process. There is a lot of heavy sighing and eye rolling involved from both parties. The old guard has to swallow their pride and admit that sometimes the dashboard is actually accurate. The new blood has to accept that sometimes you just need to unplug the stupid thing and plug it back in.

Writing troubleshooting articles really forces you to think about how you bridge this massive gap. You cannot just write a piece about a complex PowerShell script without explaining why the underlying registry key actually matters. You have to cater to the person looking for the quick fix script and the person who wants to know the exact mechanical nature of the failure. It is a constant balancing act.

I think the industry is slowly starting to realize that we swung a bit too far in the direction of pure cloud abstraction. People are starting to see the value in teaching basic physical networking again. It gives me a lot of hope that the next generation of technicians might actually know what to do when the GUI inevitably crashes. Until then I will just keep watching the standoff every time a site goes dark. It is definitely a lot cheaper than buying tickets to the movies.

But enough of my ramblings. As always... If you want to see more guides, automation scripts, and technical deep dives or silly stuff I have to say, make sure to follow on Twitter, check out the Facebook page, and sign up for the kinda weekly 404 & More newsletter!