It’s 2:00 in the morning and somebody needs the drone.
Maybe command wants an overhead view of a working structure fire. Maybe deputies have a perimeter established and a suspect just disappeared into a wooded area. Maybe severe weather moved through and emergency management needs a quick look at damage before crews start moving into affected areas.
Whatever the call is, nobody is interested in hearing that the batteries weren’t charged, the controller needs an update or the one person who knows the password is off duty.
They expect the capability to work.
And once your agency has invested the money, trained the pilots and demonstrated what a UAS can provide, that expectation is completely reasonable.
Starting a drone program gets most of the attention. There are aircraft to compare, cameras to evaluate, pilots to certify and policies to write. It’s new, people are interested and there’s usually plenty of energy around getting it off the ground.
The harder part comes later, when the drone isn’t new anymore.
That’s actually a good thing. It means the UAS is becoming another operational tool instead of something everybody stops to watch every time it launches.
But that transition also changes the standard.
Once your fireground IC has seen the value of an overhead view, they’re going to want it again. Once a patrol supervisor has watched a drone help maintain a perimeter or search an area that would have tied up several officers, they’re going to remember that capability. Once emergency management has used aerial imagery to get a faster picture after a storm, the aircraft becomes part of the conversation the next time severe weather rolls through.
At that point, owning a drone isn’t enough.
You have to keep the program capable of answering the call.
That’s where management starts to matter.
Most UAS programs have somebody who naturally becomes the person holding everything together.
You probably know exactly who that is in your agency.
They researched the first aircraft. They know which battery has more cycles than the others. They remember the strange issue one controller had three months ago. They know the software, the passwords, the charging setup and where somebody put the spare propellers after the last training day.
When something goes wrong, everybody calls them.
That person is often the reason the program exists in the first place, and there’s nothing wrong with having somebody take ownership of it. In fact, I think somebody should.
The problem comes when ownership turns into dependence.
If your UAS capability changes dramatically because one person is on vacation, promoted, transferred or simply off that night, the program has a weak point.
A good program manager should know what’s happening with the aircraft, batteries, pilots, training and equipment. But over time, the goal should be to build enough structure around the program that everything doesn’t live inside one person’s head.
That doesn’t require an administrative monster.
It requires paying attention to the things that can quietly erode readiness.
Take equipment.
Public safety already understands this better than most industries. We don’t wait until the structure fire to discover the engine won’t start or an air pack isn’t ready.
Law enforcement works the same way. Nobody wants to be setting a perimeter at two in the morning, looking for a fleeing suspect, and suddenly discover that a radio is dead or the drone won’t launch.
Emergency management doesn’t wait until after the storm crosses the parish to start wondering whether critical resources can be deployed.
UAS equipment deserves that same mindset.
Not an elaborate inspection ceremony every morning. Just enough of a system that when a pilot reaches for the aircraft, there is a reasonable expectation that it will do what is being asked of it.
Sometimes the first signs of trouble are small.
A battery doesn’t seem to last quite as long as it used to. Someone notices an odd behavior during a flight but doesn’t think it’s serious enough to mention. An aircraft lands harder than normal and gets put back in the case. A controller wants an update, so somebody decides they’ll handle it later.
None of those things necessarily stop the program that day.
That’s why they’re easy to ignore.
Then somebody needs the aircraft for a real incident and suddenly “we’ll deal with it later” becomes a much bigger issue.
The same thinking has to apply to the pilots.
An agency may have eight Part 107-certified rPICs, but the number on the roster doesn’t tell the whole story.
Who has actually been flying?
Who is comfortable at night?
Who can work thermal imagery without spending the first ten minutes getting reacquainted with the camera?
Who understands enough about a fire scene to recognize what command is probably asking for when they say, “Give me a look at the Charlie side”?
Who can support a law enforcement operation without getting in the way of officers on the ground or becoming one more thing the supervisor has to manage?
Can they stay focused on the larger mission during a long disaster operation while continuing to operate the aircraft effectively?
Those are operational questions, not certification questions.
Everybody starts somewhere, and not every rPIC needs to be the most experienced person on the team. But whoever is managing the program should have a realistic understanding of who is ready for what.
Maybe a newer pilot needs to work alongside someone seasoned for a while. Maybe one of your stronger pilots hasn’t flown much recently and needs a few repetitions. Maybe someone is excellent in daylight but needs more experience operating at night.
That isn’t about creating tiers or rankings.
It’s about knowing your capability before somebody else is depending on it.
And if the program is doing what it was built to do, that capability will probably be tested more often as time goes on.
Success tends to create demand.
A drone that started out primarily supporting structure fires and missing-person searches may soon be used for perimeters, special events, storm damage, investigations, large-area searches and other assignments nobody was thinking about when the first aircraft was purchased.
That’s a good problem to have.
It also changes the program.
Aircraft get more hours. Batteries see more cycles. The same dependable pilots start getting called more often. Equipment that once sat in the case most of the week starts working hard.
Eventually somebody has to look beyond the next mission and ask whether the program has grown with the demand being placed on it.
As the program grows, it’s worth taking a step back and asking whether the capability can keep up with the demand.
Do you still have enough aircraft for the missions you’re supporting? What happens when your primary drone is unavailable? Are the same two or three pilots carrying most of the workload? Are you replacing batteries based on condition, or waiting until one finally becomes unusable? And what does replacement look like when an aircraft reaches the end of its useful life?
You don’t need to chase every new drone that hits the market. That isn’t good program management either. The newest aircraft isn’t automatically the right aircraft, and public safety budgets have plenty of competing priorities.
But once command begins depending on a capability, there should at least be a plan for keeping that capability available.
That is the difference between buying equipment and managing an operational program.
The same is true for institutional knowledge.
If you’re the person currently running the UAS program, one of the best things you can do for it is make sure it doesn’t always need you.
That can feel a little strange. You may have spent years learning the equipment, working through policy issues, solving problems and becoming the person everybody trusts with the program. There should be some pride in that.
But the strongest program isn’t the one that depends on the smartest person in the room. It’s the one that still works when that person isn’t there.
Bring other pilots into the management side. Let somebody else help with training. Make sure more than one person understands the equipment, accounts and procedures. Explain why things are done a certain way instead of simply telling people how they’re done.
Eventually people promote. They transfer. They retire.
The capability should remain.
That doesn’t mean creating more paperwork just to prove the program is organized. In fact, I think that can become its own problem.
Pilots should be flying, training and supporting incidents, not spending half their time entering the same information into multiple systems.
Keep the records that matter. Make equipment problems easy to report. Know who is flying. Track the things that actually affect readiness and make the process simple enough that people will use it consistently.
The point of management is not administration for the sake of administration.
The point is reliability.
When the structure fire comes in, the aircraft is ready. When deputies need another set of eyes over a perimeter, a capable pilot can respond. When the storm passes and emergency management needs information, the program can stay in operation longer than one battery and one flight.
And when the person who originally built the program happens to be unavailable, none of that changes.
That is when a UAS program has really matured.
It isn’t measured by how many drones are sitting in the case or how many names appear on the pilot roster. It’s measured by whether the agency can depend on the capability when it matters.
Because when somebody calls for the drone in the middle of the night, they’re not asking how well the program is managed.
They’re asking whether your agency can deliver when it matters.
And the answer should never depend on who happens to be working, which battery was charged or whether the one person who knows the program is awake.
A mature UAS program doesn’t just own capable aircraft.
It builds a capability the entire agency can trust.