I came up on NetWare and Windows NT 3.51, and I've worked on everything from mainframes to Kubernetes since. Linux has been at the heart of most of that work. It has never been the only thing on the network.
That's true almost everywhere. The servers may be Linux, but the identity system is Active Directory, the laptops are Windows and Macs, the firewall runs its own operating system, the storage array has its own, and somewhere in the building there's a box nobody's allowed to reboot that runs something older than most of the staff. A Linux engineer who can only work on Linux can only fix the part of the problem that happens to be on Linux.
Why it matters
Most problems cross a boundary. A user can't reach an application. Is it their Windows laptop's DNS settings, the VPN client, the firewall, the load balancer, or the Linux server? An engineer who understands every hop finds it in ten minutes. One who only understands the last hop spends the afternoon proving it isn't their server.
Integration is the job. Linux servers authenticate against Active Directory. Windows users mount files from Samba. Mac developers deploy to Linux containers. Scripts call Windows APIs. Making those systems work together is a large share of real enterprise Linux work.
It earns trust. Saying "that's a Windows problem" ends conversations. Saying "here's what's happening on the Windows side, and here's the fix" makes you the person people bring problems to.
It makes you better at Linux. Seeing how other systems solve the same problems, like Windows services versus systemd units, Group Policy versus configuration management, or launchd versus systemd, shows you what's essential in each and what's just convention.
What to learn, in order of payoff
1. Active Directory. If you learn one non-Linux thing, make it this. Nearly every enterprise runs its identity on it. Understand domains, organizational units, groups, Kerberos, LDAP and DNS's role in it all. Then learn how Linux joins it: realmd and SSSD, kinit and klist, and why time synchronization breaks Kerberos. That alone solves a big category of tickets.
2. Windows Server basics. Event Viewer, services, the registry at a reading level, file shares and permissions, and PowerShell. PowerShell has been open source and cross-platform since 2016, and PowerShell 7 runs on Linux. It's also a well-designed shell in its own right: it passes objects rather than text, which is an idea worth borrowing.
3. WSL. The Windows Subsystem for Linux runs a real Linux kernel inside Windows. Many of your developers work there all day. Knowing how it handles networking, file systems and memory will save you and them a lot of time.
4. macOS. Developers love Macs, and macOS is a certified Unix with a BSD userland, so you'll feel half at home. Learn where it differs: launchd instead of systemd, BSD versions of sed and grep with different flags, Homebrew, and how the Apple Silicon CPU architecture affects container images.
5. Network operating systems. Cisco IOS, Junos and the rest. You don't need to be a network engineer, but being able to read a running config, check an interface and understand a VLAN trunk or an ACL makes you far more useful in an outage.
6. Hypervisors and appliances. VMware ESXi, storage arrays, backup appliances, and firewall operating systems. Many are Linux or BSD underneath with a custom shell on top.
7. The mainframe, if your organization has one. z/OS and the CICS, DB2 and JCL world are still running a lot of the world's banking and insurance, and IBM Z happily runs Linux too. Fluency is rare and valued.
How to pick it up
- Build a small lab with a Windows Server evaluation VM as a domain controller, a Linux VM joined to it, and a Samba share. Most of the integration lessons happen in one weekend.
- Volunteer for the cross-team problem. The ticket that bounces between the Windows team and the Linux team is a free education.
- Learn PowerShell well enough to read it. You'll inherit scripts written in it.
- Pair with the other teams. The Windows admins know things about identity and Group Policy that would take you months to learn alone. Trade them something they want to know about Linux.
Agnostic, not neutral
Being platform agnostic doesn't mean having no opinions. I have plenty, and most of them favor Linux and open source. It means choosing the tool for the job, knowing enough about the alternatives to judge them fairly, and never letting "not my platform" be the reason a problem stays unsolved.
The person who understands the whole system is the one who gets called first, and for good reason.
Since then
Added October 2026. Five days after I wrote this, a faulty CrowdStrike update crashed about 8.5 million Windows machines, and getting them back meant booting each one into recovery mode and deleting a file by hand. Plenty of Linux engineers spent that weekend fixing Windows. I wrote about the outage itself in Understanding the Causes of Widespread Outages.