“Include Kodak in this room.” That’s the line in the client’s system review memo which confused me, and one with which I eventually opened an internal training seminar at SMW. What were they talking about? And what was the bigger message? Read on!

The memo in question came in a fairly late design phase of a project I’d inherited from one of my departed colleagues. It’s one with which I was familiar, having assisted with the design, but I’d not yet met any of the users and was quite honestly confused by this line. Was it some kind of legacy device from the Eastman Kodak company? A zombie-brand that was somehow leasing the Kodak name? Something to do with film, or old-school photography?

After a brief chat, it became clear that what they wanted was a video-teleconference appliance. My colleague had referred to it as a codec and the client, with no context for this word, heard it as “Kodak.” Mystery solved. This was a very much engaged client who understood what they wanted but appeared more ignorant than they were because nobody had taken the time to share the correct language with them. Using words correctly is not solely a matter of being understood, but of positioning oneself as someone who knows what they’re talking about. In the case of a client it’s not a serious issue; it’s our job as professionals to help give them the tools to navigate technical choices. When a client doesn’t know – when they say “Kodak” because someone else didn’t do a good job of educating — we have the opportunity to help guide them towards greater understanding.

The problem comes when we in the AV industry try to talk about IT matters. Too often we use words imprecisely and without understanding them. In a discussion of network-based AV systems we need to position ourselves as experts. We cannot afford to be the ones who say “Kodak” and wait for someone else to educate us; it’s our job to do the educating. Which means that first we need to educate ourselves.

Network has become a basic requirement. When I’m asked how to protect a system against complete network failure, my answer is that it’s the same as protecting against a complete power failure; the network is as much a basic requirement for a modern AV system as electricity. To carry the analogy a step farther, think about you we specify electricity. We might ask for technical power on a common phase. We might ask for it to come from a common breaker panel. In some cases, we might even ask for an isolated ground. These choices may impact the performance of an AV system and they’ll also cost somebody a measure of money and effort. It’s incumbent on us to understand these things so we can make reasonable choices which meet AV design requirements without wasting resources on over-design. How much bandwidth do we need? How many networks will we need? How many hosts will each of those networks need?

What do those last statements mean?

Another wake-up call came in submittal review. I’d find submittal items that look like this:

Working for a multidisciplinary firm, it’s quite easy for me to walk down the hall and show this sort of thing to an IT designer who can both translate it into English for me and confirm that it meets the project requirements. In the longer term, however, we all need to be able to present ourselves as experts which, increasingly, means at the very least speaking the language of networks and IT. If you are reading this and do NOT understand CIDR notation then you need to educate yourself before you end up being embarrassed with a question you not only can’t answer but that you also don’t even understand.

I’m fortunate in that I work for a firm which has a strong commitment to education and development. As part of our internal training program, I prepared an introductory “IT for AV Designers” session focusing on broad concepts and — in what should be no surprise to anyone here — on language. Why those of us in the habit of saying “TCP/IP” when we mean “network” sound ignorant. What “reliable” and “unreliable” transport means in the context of transport protocols. What this thing called “AVB” actually is. What QoS is and — in general — how it works.

There’s a great deal to learn — a great deal which we need to know.

I’ll aside that the Wednesday afternoon training and education program is one of the fun things about working where I do. We’re treated to a wide variety of viewpoints, of teaching styles, and of subject matter. Some presenters sit at a teaching desk. Some stand. I tend to pace about the room, while others pace across the front of the room, waving the power-point clicker casually about. Those who know me can likely guess into which category my presentation style falls. What’s best as a presenter is that it gives me the opportunity to refine my knowledge and understanding; I can take various sources — the notes I took from Paul Ziele’s QoS presentation at InfoComm 2014, my study material for my aborted attempted to get an entry-level Cisco certification (that’s another post!), and whatever else I’ve learned and distill it into a coherent story. By teaching we also learn, and by learning we learn.

This started the ball rolling, and was — I hope — a step towards having more of my fellow AV designers start to think like AV/IT designers. The next step is to drill down more deeply and put our newfound language to use.  I already have a second session planned in which we walk through more details of basic network design, subnetting, etc. What’s important for now is that we all know the broad concepts and that we all have the correct language.

After all, if you’re reading this you are most likely an AV professional. We are the experts, we are the ones counted on to offer guidance and direction. We can’t be the ones saying “Kodak” and still keep our position of expertise.