I have something to admit. I’m a recovering Voice Engineer. It’s been almost 10 years since my last installation. I occasionally experiment in the privacy of my home. But I’ve mostly broken the habit. It’s actually been so long that most of the people I work with have no idea that my CCIE is actually in Voice. I was actually one of the first 50 or so in the world which means I’ve been out of that world longer than most people have been in it. I try to stay current, but to be honest, my passion has moved to other things.
For someone reason, Voice Engineers are viewed as the bottom feeders of the networking world. But I never seem to be surprised that some of the best networking people I know seem to have a solid voice background. Just to call out a few of the twitter personalities
@networkingnerd – Yup. Tom used to be a voice engineer.
@amyengineer – Uh huh. Her too. She slips occasionally, but she’s getting better.
@treylayton – CTO over at that little VCE company? Before vBlocks and Netapp. He was one too.
and then tonight I just found out
@colinmcnamara has a great voice background from the early days as well. Yup. The DevOps/OpenStack/automation guy? He’s one too.
I’m not talking about the kind of voice engineers that we see today. One who reads one of the many Cisco Press purple books which are available. ( in my day they were teal darn it! ) Logs into a website which automatically puts together a complete Cisco Communication Manager Express ( #hursttoevenwritethat ) configuration based on your input into a webpage. People who think that SIP has always been here and that H.323 is a “legacy protocol”.
I spent some time reminiscing about AS5300s, MCS 3800s, MGCP inconsistencies, importing hundreds of MAC addresses with a Bar code reader and various other shenanigans that we had to do at that point of the industry. To be honest, it feels so good to know that we will never. ever. ever. have to do any of those things again.
But there were also some really great lessons I learned from that point in my career.
Be nice to everyone
I’m lucky that I’m Canadian and had my parents and country to thank for teaching me good manners. Unfortunately, I’ve seen this go very very wrong when I was paired with a sales person who didn’t have the same upbringing I did.
Situation: We walk into a potential customer. He’s immediately rude to the receptionist and tells ( not asks ) here to let the CIO know we’re here and to go get him a coffee. Not even a please. I don’t think he called her honey or sweetie, but it was definitely implied. I was speechless and young enough to not step up and defend her.
So the sale goes on. We get the buy in of the CIO, the CFO, the accountants ( they eventually became known as the IT department ), and basically nailed the sale. We had everyone’s buy in and the sale guy was looking forward to a big commission check. Then we were marched back to the front of the office and sat down in front of the receptionist that he had offended from the moment he walked in the office. She was shown the receptionist station phone and asked what she thought. Anyone want to guess at how this turned out?
This just reinforced what mom and dad taught me. Be nice to everyone. It’s important. You never know when a lack of manners is going to come back to haunt you.
It’s all about getting from point A to point B. The rest is just details.
For anyone who lived through the early days of Voice, you will all remember the media frenzy of the time telling everyone that the network team was going to absorb the comms team and that all the legacy voice people were going to lose their jobs. In fact, Cisco at the time was using the headcount reduction as one of the selling features. This setup for a huge war between the Voice and Networking teams. Never a good thing. The legacy comms teams were afraid of this new technology. They didn’t understand what IP, TCP, CME, CCM, SRST, H.323, SIP, etc… meant. And they didn’t even know where to start.
There was one particular account where I was dropped into and all of the information sat in the head of the legacy comms guy who was running a multi-site Nortel network with some Option 11s and various norstars ( nortel key switch ) in a fairly complicated voice network. I was the 3rd or 4th person to get dropped in and I was warned about him. He was feeling threatened and had been intentionally difficult. And rightly so. He was told that we were coming in to replace him and he had no path forward.
I remember sitting down with Dave and I spent about 2 hours with him explaining routing in voice engineer terms. Routing in terms of dial plans, etc… At the end of it he just looked at me and shook his head and laughed. Then he looked up and said “ That’s it?”
Apparently, the guys before me had never taken the time to explain any of what we were doing in terms that he could understand. Turns out the guy is a routing genius and understand the route summarization, advanced routing concepts, ACLs, and much much more. He was actually running a complicated voice network spanning 6 separate LATAs and doing Tail-End-Hop-Off ( TEHO ) while dealing with non-contiguous NSX codes.
The network ops teams came to me a couple of days later and wanted to know what kind of magic I had pulled with Dave because they had never seen him more cooperative or helpful. Plus, he suddenly was a lot more interested in what they were doing and seemed to have gained 10 years of network knowledge overnight.
This project taught me that when you have a good conceptual model and you really understand it. The rest is just implementation details.
Just because it’s a standard, doesn’t mean it’s a standard.
SOOOOOO many examples of this, but I think the first time I learned this was when SIP first came out. Wow. What a mess. Now we see non-standard implementations of protocols all the time. It’s sad that we’ve gotten to the point where we don’t even have outrage over it anymore. This brings me to the next lesson.
Trust but verify.
I worked a customer where we had ordered 2 PRIs ( ISDN Primary Rate interfaces ) for Voice service. We were clear that we HAD to have CallerID as part of the bundle. We received the sheet from the vendor ( Telco who doesn’t exist anymore ) who was actually subleasing the lines from another Telco. It had all the regular line information on there. Protocol DMS 100, etc… So we spun up the line and we didn’t have CallerID. Long Story short, the customer didn’t pay their bill for almost 2 years because the Telco could never get CallerID to work and every time we started getting somewhere, the account team changed and we had to start over from zero.
One night during an outage window, just for giggles, we changed the protocol on our end from DMS 100 to NI1 or NI2. For those of you who don’t know, they are all pretty similar as ISDN protocols and the one thing which I remember is that the place where the incoming CallerID was stored was different among the three implementations. The customer didn’t say a word to the vendor until for another few months. 🙂
The application is what’s important.
The most important thing I learned as a voice engineer is that the application is what’s important. Or more accurately, the value that the business derives from the application. In those days, if you said Callmanager had a minimum of features, it would have been an understatement. I remember Lucent ( now Avaya ) competing against us with the “ We have 250+ features! You might need them! You’ll want to make sure that you have them!”. The response was usually “Name 10 of those features”. I’ve never had a customer get past 6 or 7. Funny enough, I know see network vendors doing the same thing.
All that really matters is If the product you’re pitching has the right features and you can align the to what the business is doing or wants to be doing.
Funny enough. I find myself having a lot of the same conversations know as our industry does another paradigm shift into the world of SDN, APIs, and Orchestration. Hopefully, I learned the lessons well enough the first time to not repeat them this time around.
To all my other crusty old voice guys. Thanks for all the lessons you taught me.