Walk into almost any firehouse in the country and you’ll find two kinds of technology sitting side by side. There’s the gear that works because it has to — SCBA, thermal imaging cameras, the apparatus itself. And then there’s everything else: the records management system nobody trusts, the scheduling software three captains refuse to open, the new dispatch interface that half the shift learned by trial and error at 0300 on a working fire.
The gap between those two worlds keeps getting wider. Departments are buying technology faster than they’re learning how to use it. And here’s the part nobody wants to say out loud at the kitchen table: that’s not a software problem. It’s a leadership problem.
The Tech Gap Is a Leadership Gap
We like to blame the tools. The software is clunky. The vendor oversold it. IT doesn’t understand the job. Some of that is true. But strip it back and the real issue is that technology in the fire service almost never fails because of the technology. It fails because of how it gets introduced, who champions it, and whether anyone in a white helmet actually owns it.
Think about how new tech usually shows up on the job. A grant comes through, or a chief goes to a conference and sees a demo, and six months later a system lands on the watch with a one-hour training session and a laminated cheat sheet. Nobody asked the firefighters who’ll use it every shift what they actually need. Nobody built it into the daily routine. And nobody made it clear that learning it isn’t optional. So the crew does what crews have always done with a tool they don’t trust — they work around it. They keep the real information in a notebook, a group text, or somebody’s head.
That’s a leadership failure, not a user failure. When a new hoseline or a new ladder throw shows up, we don’t hand out a pamphlet and hope. We drill it. We make company officers responsible for competency. We check it on the probationary evaluation. We treat it like it matters because lives depend on it getting done right. Technology gets none of that respect, and then we act surprised when adoption craters.
Here’s why it matters more than it used to. The fire service is drowning in data it’s required to collect and report — NFIRS, NEMSIS, exposure tracking for cancer and cardiac risk, staffing and response-time records that justify budgets and grants. Accreditation increasingly runs on data. Community risk reduction runs on data. When your systems are a mess, you’re not just annoyed at a slow login screen. You’re making worse decisions about where to put your engines, how to protect your people from carcinogens, and how to defend your staffing levels when the city council comes asking. Bad data leadership has an operational cost and a budget cost, and both land on the firefighters.
Cybersecurity is the same story wearing a different coat. Fire and EMS agencies hold protected health information and run on connected dispatch and records systems. They’re targets. Ransomware has knocked dispatch centers offline and forced departments back to paper for days. That’s not the IT department’s risk to carry alone — it’s an operational readiness issue, which makes it a command issue. If a chief can speak fluently about water supply and incident command but goes blank when someone says “multi-factor authentication,” that’s a gap in fireground readiness for the modern era, even if it doesn’t feel like one.
None of this means every chief needs to become a programmer. Leadership in technology looks the same as leadership in everything else this job demands. It means setting a clear expectation that the tool gets used. It means assigning real ownership instead of letting a system float around as everyone’s problem and nobody’s job. It means budgeting for training and not just for the purchase. It means asking the people who turn the wrenches and pull the lines what they actually need before you sign the contract. The departments that get technology right aren’t the ones with the biggest budgets. They’re the ones where someone in a leadership role decided it mattered and acted like it.
Your Next Tech Leader Is Already on the Roster
So who fixes this? A lot of departments default to one of two answers, and both are wrong. The first is to hire it away — bring in an outside IT person who knows servers but has never been on a call and doesn’t understand why a firefighter won’t stop to type during a transport. The second is to wait for it to fix itself, usually by hoping the next generation of hires shows up fluent and motivated. Neither works, and you don’t need either, because the person who can close this gap is probably already riding out on your apparatus.
Look at your roster. You’ve almost certainly got a firefighter who set up the station’s camera system on their day off. The one who built the spreadsheet that actually tracks the rig checks. The one everybody quietly goes to when the MDT freezes up, because they figure it out faster than waiting on a help desk ticket. The medic who taught themselves to pull clean reports out of the EMS software. That person isn’t a hobbyist. That’s an aptitude and an interest that your department is currently wasting.
The reason they matter so much more than an outside hire is simple: they already have the thing you can’t teach quickly. They have credibility on the floor. When the firefighter who’s pulled ceiling next to you says “this system is worth learning, here’s how it actually helps you,” that lands in a way no vendor rep or city IT consultant ever will. The job runs on trust earned at real incidents. A technically skilled firefighter has that trust already. You’re not trying to teach a tech person the fire service — you’re giving a fire service person room to lead in tech. That’s a far shorter path.
The catch is that we tend to do nothing with these people, or worse, we punish them for it by quietly dumping every tech headache on their lap with no title, no time, and no recognition. That’s how you burn out your best asset and teach everyone else to hide their skills. If you want this to work, treat it like any other specialty the fire service already knows how to develop. We have hazmat techs, technical rescue specialists, fire investigators, training officers. We identify aptitude, we send people to get real credentials, we give them a role and the time to do it, and we build it into the promotional path. Technology should be no different.
That means giving the interested firefighter a defined collateral duty with actual hours attached, not just a tap on the shoulder. It means paying for relevant training — data and records management, cybersecurity fundamentals, the specific systems your department runs. It means putting them in the room when the department evaluates new tools, because they’ll spot the vendor’s empty promises faster than anyone in administration. And it means making technological competence part of what gets you promoted, so the skill is rewarded instead of exploited. A captain who understands both the fireground and the department’s data isn’t a nice-to-have anymore. Within a decade that’s going to be a baseline expectation for command.
The Bottom Line
The fire service has never struggled to develop people. We take an 18-year-old who’s never held a halligan and turn them into a competent firefighter, then a company officer, then a chief. We know how to build talent. We’ve just been treating technology like it lives outside that process — like it’s somebody else’s department, somebody else’s problem, somebody else’s skill set.
It isn’t. The tech gap is a leadership gap, which means it’s a problem this service already knows how to solve. The tools will keep changing. The way you lead people through change doesn’t. Stop waiting for the perfect software, and stop waiting for someone from the outside to ride in and rescue you. Look down your own roster. The firefighter who can lead your department into the next decade is probably already there — checking the rig, fixing the MDT, and waiting for someone to notice.