Surveillance Engineers Who Know Nothing About Surveillance

It's surprisingly common for surveillance companies to hire engineers who know nothing about surveillance. The rationale is typically that the new employee is smart and successful at some mainstream IT/tech company.

Contrary to that, see this interesting article about the problems of engineers/developers lacking domain knowledge (i.e., in video surveillance, the domain is video surveillance).

What I find especially risky is hiring such engineers in senior / management roles where they inherently make important decisions on features / design / implementation.

Even if you are strong technically (in programming or network engineering, etc.), without a strong grasp of how surveillance works and what people want out of surveillance, the likelihood that bad decisions are made is through the roof.

Agree / disgaree?


You know you'll get no argument from me on that topic...

It's not so much a problem (IMO) to hire someone who lacks the industry knowledge, as long as they have the desire and ability to learn the relevant things. Of course that would tend to mean they'd be hired into non-senior roles, so they had some ability to come up before being put in an immediate position to have a negative impact on the company.

Which creates the worst possible situation, a team of people who know the domain led by a person who does not. Come to think of it, this is also problematic in sales and marketing as well. If the person making final decisions has a naive or misguided view of their domain, the whole team suffers. Unfortunately, this is almost guaranteed when making a senior hire with no domain expertise.

WOW! You've touched a nerve here...

VMS engineers who have never seen how VMS' are used in the field? For instance:

  • I'm convinced the timeline bar is a cruel joke foisted on unsuspecting users by a sadist. On at least some systems, it takes forever to go to a particular date and time, especially systems that don't allow the use of the scroll wheel to zoom in and out on the bar.
  • Clip saving is another area that is often given little thought. Take Genetec Security Center. They put a huge progress window up that covers 3/4 of the screen and prevents the user from performing any other tasks while the clip is being created. For long clips, that window could tie up the client for over an hour. Pelco Endura forces all clips to be saved to one location - the result must be "moved" after creation to whatever drive/folder the user wants. File naming and save locations are functions that are also often problematic. While it may be OK to use Windows Explorer to determine where to save clip files and let the user determine a file name for applications that generate few files, when multiple users often generate dozens of files in a day, the results can be disastrous - multiple files with the same name (plus "(#)"); files that everyone should have access to saved on the C: drive of one client; file lists that can't be logically sorted, etc.
  • Cluttered desktops featuring numerous buttons for obscure functions or menus with layers upon layers of submenus. Related functions scattered under multiple tabs.
  • Long switch times between "live" and playback; playback that starts at some random time or playback that the user must select which camera and timeline to start at.
  • PTZ control with too few "steps" so that variable speed pan/tilt capabilities are lost, making it difficult to follow moving vehicles or even people.

The VMS list alone goes on and on...

Camera engineers who don't understand where AGC is useful, or more importantly, where it isn't. I marvel at the number of cameras we've tested that have AGC "always on". There are applications, especially in casinos, where the net effect of "always on" AGC is a muddy picture that overloads bright areas. Slow shutter functions that force a camera to lower-than-required frame rates that can't be defeated.

Storage engineers who don't comprehend how streaming video should be handled. They claim they "know video storage" but still set up their systems with a short "drive check period". This causes perfectly good drives to be kicked out because they were just a little slow to respond to a command - typically when they were relocating a bad block. Dumb functions like "copy back" that lengthen the time a system runs in degraded mode while rebuilding a failed drive. What is the point in always keeping the same drive as a global spare?

This list is not all-inclusive. There are many areas where I marvel at the thinking process of designers/engineers. I think all of them should be required to spend time in the field talking to end users. Perhaps that will give them at least some appreciation of end user needs, rather than introducing every sort of useless gadget just to "one up" the competition.

Unfortunately, many product managers and senior engineers are far removed from customers, staying at the home office and basing decisions on third hand reports.

Disclaimer: I am an employee of Genetec. While I wholeheartedly agree that having individuals experienced in the use of a product as the products primary engineers it is not always realistic. What I do think is more realistic is the advancement and evolution of features born out of usage environments. Things like user conferences, vertical specific feature focus and mixing of end users and product management facilitate this goal. Trade shows I have found to be a great way to accomplish the later.

Users very often have extremely good suggestions as they are borne out of constant use of the product. I believe having an advocate that can speak to the needs of the users and channel them internally to the organization is something all companies should have and through this the evolution of a product can be measured.

Consumers are very adroit in my experience at figuring out which products and companies evolve to meet their needs and which do not, reflecting in a companies bottom line.

Zeb, thanks for the feedback. I am a little surprised that you cited trade shows! On the plus side, you do get both product managers and users together at the same time. I guess that's the big plus. The main negative I see is that you are away from their environment / system so it's harder to see and feel the pain points.

The best experience I had as a product manager was sitting at the end user's site, observing them use their system. That way, I didn't need them to talk abstractly about what they liked or didn't. I could simply see it on their face, as they failed, struggled, etc. Then I thought about what feature or improvement could solve that. Those were extremely productive meetings / visits.

Of course, the big downside of going to an end user is getting to the end user. Is it a lot of time and money to do so but I don't think you could replicate a lot of it otherwise...

Carl - thanks for the depth of detail in your comment. I enjoyed it.

Here's a pet peeve of mine: equipment (especially camera) designers and engineers who apparently have *never actually installed* the type equipment they're designing, and come up with some of the most bizarre concepts that make physical installationa headache.

A classic example, for me, is the Pelco ICS-111 outdoor vandal dome: the camera module sits within a springy bracket that then rides in a groove in the housing, to provide a "rotation" axis. I'm sure it seemed like a good idea at the time... but most of them I've installed, there's a slight looseness to the "springiness", and it doesn't sit evenly within the groove - four contact points, and usually only three of them actually make contact (imagine a four-legged table with one leg shorter). This makes it more likely for the entire assembly to get bumped out of place, or just shift under vibration.

Another is the venerable Panasonic gimbal design as used in the CW484/504 and similar dome models - the very need for a locking screw on the rotation ring shows poor underlying design; the spring-loaded tilt pivots fail to hold the camera module steady much of the time; and the "twist" to rotate the camera module within its holder is invariably tight and gives little to grip, making that adjustment difficult to turn without throwing something else out of whack. Meanwhile, at 1/3 the price or less, the CNB domes we use have the same style of 3-axis gimbal, but have no requirement of locking screws or springs, but with just the right amount of friction, are easy to adjust while never (so far) slipping out of place on their own.

Oh, and don't get me started on the ol' Pelco IS-90, where the service video port is a sub-mini TS jack (hard enough to come by a plug in the first place), buried deep within the housing (meaning your average DIY solder terminal sub-mini TS plug won't fit with its cover on, let alone allowing room to get one's fingers in there)... and Pelco never bothered to actually include an adapter cable to allow one to plug in an RCA or BNC service monitor, meaning you HAVE to go out and find your own plug and build your own cable if you actually want to use the thing. It's like adding the port was someone's after-thought on an A&E spec, with no concept that someone might actually want to use it.

I could go on and on... it invariably seems the bigger the brand name and the more expensive the camera, the less throught was actually given to INSTALLING it. The more installer-friendly cameras seem to consistently be the cheap, no-name models...

Okay, one more: certain Arecont domes that use hex-key locking screws for various adjustments... but actually DIFFERENT SIZE hex keys for each different adjustment. At least they're nice enough to include all the required keys, but seriously??? That's beside the multitude QA issues like hex-key screws that never actually had the hex stamped in them (just a little drilled hole)... parts mis-assembled and broken from the factory...

Excellent Statement Matt.: I could not agree More . This is a Problem with the bigger more expensive cameras , ptz's

"Surveillance Engineers Who Know Nothing About Surveillance". I agree its a problem, simply from the fatc that it's hard enough finding computer networking people who even know computer networking. When I got my first hire/fire position, I learned the hard way about people lying or stretching what they know on their resumes. I fired 5 people my first year as a manager, 4 of whom I had hired, because I was taking their word at face value and then finding out they didn't know anything or were un-trainable. What helped a lot was I eventually developed my own "technical screening" questionaire, where applicants have to answer some basic questions and solve certain scenarios and are scored with points. For bench techs, it was as simple as having the other techs sabatoge machines and having applicants diagnose the problem. They were happy to do it because they didn't want to work with someone they'd have to pick up the slack for.

So if I as an experianced IT professional was running into that problem hiring technology people, then I can only imagine a surveillance company without a strong IT base trying to hire someone who knows what they're doing to help bring the company into the 21st century IT world, and then hoping that person is smart enough to learn surveilance.

On the flip side though, what about Surveillance Engineers who know nothing about IT/Networking(from an integration/design standpoint)? Which is more of a disservice to a customer when it comes to designing a IP video system? I have an IT background and had zero surveillance experience when I came into the industry. Of course there was a learning curve but it wasn't nearly as steep as having to learn networking, server administration, and general IT troubleshooting from scratch. Luckily I was given access to this site on day one, which has been an extremely valuable resource.

I've felt since entering this industry that it is easier to transition an IT person into surveillance than an old school CCTV person into IT. In the various camera and vms classes I've attended, it seems that the people with the IT background get a better grasp on the information presented. Of course there are exceptions to everything, this is just the trend I've noticed. But this can be a problem in almost any field, one particular industry skilset may complement another industry it does not gurantee success. At the end of the day it really depends on the engineer and the quality of training available(which is a whole other issue).

Drew, I agree with you on both counts - the need for IT skills and the comparative ease for an IT person to get into surveillance vs the other way around.

The specific problem I found repeatedly is bringing someone in from the IT side at the senior management / leadership level of a surveillance company (manufacturer or integrator). Too much is expected too quickly in such a position that the risk of painful mistakes is high.

To the contrary, if I was hiring junior level people, everything else being equal, I would certainly prefer a person with IT vs low voltage tech background.

Good luck getting your 20 year alarm verteran to install a VMS and some IP cams. Sure he might know more about structure wiring and locating camera locations, but I bet you the IT guy can pick that up rather quickly. Try teaching that alarm guy about IP and network topologies. Ask him to open ports in a firewall for remote access. Ask him to define his IP scope or how to properly subnet a given IP range. Ask him what his default gateway is!

I come form a computer/IT background as well. I started installing camera systems for my own company out of necessity. People would ask who installed our cameras. When we told them we did our own, they asked how much to install some for them. That was back in 2001 and we decided to add it to our set of core offerings. We have come a long way in those 12 years. From a B&W Samsung all in one CRT/Multiplexer system with a VHS recorder, all the way up to 3MP IP domes.

I pity the alarm guy who has ZERO computer experience, with 20 years of analog CCTV experience, that has to install his first IP based system.

Reminds me of this Dilbert cartoon.