We’ve moved into a wireless world, which is too bad for me because I love, more than anything, wiring.  I miss the days of good old Cat 3 cable, T1 lines, and ISDN BRIs.  I miss 66 blocks, punch down tools, cross-connect wire, and tone/probe kits.  And butt sets.  Especially butt sets.  Now I just have to add random wall receptacles around my house since, thank goodness, 120 volts cannot be delivered wirelessly.  But phone and network wiring was much more fun.

I first got interested in wiring when I was working at a small museum exhibit design and fabrication company in Marin, California.  One day, I had to have a new phone line installed, and I called in Pacific Bell to do the work.  Under the receptionist’s desk was a wall plate with two RJ-11 jacks, already in use.  “There aren’t any free jacks,” I told the phone guy.

“It doesn’t matter, as long as there is enough wire,” was his cryptic response.  I let him do his work, and when he was done I saw a little surface-mount RJ11 jack on the wall.  It had two blue and yellow wires running from it, going underneath the existing faceplate and somehow into the wall.  How on earth did he do that?  I remember thinking.

I waited until everyone went home.  I unscrewed the faceplate and found that the blue/yellow wire pair was spliced to the brown pair of wires in the cable that serviced the existing jacks.  The splice was a 3M UR-type, which looked like a piece of candy.  I was captivated.  How did he know where the brown wires went?  Where did the incoming phone line enter the building?  How did he connect them up?

The fun thing about the days before ubiquitous Internet was that you couldn’t get answers immediately.  When I found the 66-type punchdown blocks that formed our little MDF, I couldn’t Google the part number to figure out what they were.  Google didn’t exist.  I had no idea how to terminate a wire on one of them.  While thumbing through a Jensen Tools catalog our purchasing agent had I got an idea of how it worked.  There, I saw listed a “66 punch-down tool” and I had noticed the numbers “66” on the block.  OK, so they go together and the wire gets in the clip by “punching down.”

I didn’t have the money to afford a punch-down tool.  So I got a pair of pliers and a pair of forceps and started doing terminations myself, guiding the wire into the clip.  Sure, sparks were flying, but phone systems are robust, aren’t they?

It turns out not as robust as you might think.  Back in the day, phone lines provided by the phone company (POTS service) were indeed robust and could handle quite a bit of sparking and shorting.  But the Nitsuko (emphasis on the “suk”) system we used did not take kindly to my laissez-faire approach to wiring.  One day, while doing a move, I shorted out a couple terminals and all the phones in the building went out.  I came out of the closet with pliers in hand and everyone knew what happened.  This being before cell phones, business was done for the day.  Luckily we got our phone company out to replace the bad part, and they did it under warranty.  It was at this point I invested in a proper punch-down tool and learned how to wire correctly.

The author’s tools: Butt set, punch down tools, tone/probe set, and connectors

I saved up a lot of money and eventually got a test set, otherwise known as a “butt set”.  The butt set looks like an oversized telephone handset, and is the official sign of a telco wiring guy.  It also was my passport into telephone wiring closets–when a security guard sees you have a butt set, they just assume you’re a real phone guy.

I practiced my technique in my father’s 1910-era house.  The decades brought with them layers of phone wiring, including two 50-pair feeder cables and a 66-style punch-down block.  Why and how the feeder cables ended up in a house with 3 phone lines is a mystery to this day.  But I used the 66-block for practice and dissected the criss-crossing wires in his house, tracing them out with my trusty tone/probe set.

Wiring skills came in handy many times in my career as a network engineer.  I remember one customer I had in the late nineties who had ordered 8 Centrex lines from Pacific Bell.  The technician showed up to do the cross-connects, but he was not the sharpest knife in the drawer, did two of them, and left.  Using my butt set passport, I got access to the MDF, figured out the right punch-down block that fed to the customer’s suite, and ran the cross-connects myself.

When I worked for the San Francisco Chronicle, we actually had an in-house wiring tech.  Her name was Mona Lesa.  She couldn’t care less if I did my own wiring, as long as I adhered to her standards.  One day I had a frame relay T1 installed in our Sacramento bureau office, and once again, Pac Bell forgot to connect it to the suite.  The bureau was located in the Old Senator Office Building across from the state capitol.  I got the security guard to let me in to the MDF in the bowels of this historic building.  I figured out that one of the interconnects was in the office of a lobbying firm, and the receptionist dutifully let me in to do the wiring.  With my butt set I could clip into any of their phone lines and listen to their conversations without them knowing.  I didn’t but I was amazed that I could go anywhere to do cross-connects.

On another occasion, a customer of mine had two phone lines installed and had a weird problem.  If she picked up one line and dialed the other, she’d hear both ringing and a busy signal at the same time.  I found where the Pacific Bell guy had done the cross-connect, and realized he mixed the tip and ring wires for the two phone lines.  A couple punches and all fixed.

Phone wiring was always the perfect blend of mind and body to me.  To do it you need to work with your hands, but you also need to use your mind.  Some wiring closets were rats nests of 24-gauge wires color-coded with more colors than a tie-died shirt.  Finding that one pair you needed, and marrying it up to the other end was always a nice diversion from staring at a screen.

Alas, my tools mostly sit unused.  Regular POTS lines rarely exist now, and even they aren’t delivered on single copper pairs from the CO switch.  PBXs and key systems have gone the way of the dinosaur, replaced by voice-over-IP and now by cellular phones.  Nobody wants to be tied to wires anymore, and yet by un-encumbering ourselves in the name of freedom, we’ve paradoxically lost our freedom.  When you don’t need to be physically tied to a location for connectivity, you can never escape connectivity.  And that’s not entirely a good thing.

I mentioned several weeks ago I would be playing with the themes on this blog as my old one is broken and I don’t have time to fix it.  Pardon the changes in appearance while I play around.  I was getting tired of the tiles anyways, so maybe going back to a linear format will be more readable.

Incidentally, the new themes all lack the star ratings of the previous theme.  Frankly, they didn’t do much for me other than let me know someone was reading.  Feel free to comment if you like/dislike the theme I’m trying.

When I first started at Cisco (the second time), I remember being in a customer meeting where I had no idea what was going on.  As is typical for vendor meetings, Cisco employees outnumbered the customer by 3 to 1.  Someone from our side was presenting, though I don’t really remember about what.  I didn’t say anything because I was still pretty new, and frankly didn’t have much to say.  A Distinguished engineer, whom I know opposed my hiring, pulled me aside after the meeting and said to me with a smile:  “You know at Cisco we judge people on how much they speak in meetings.”  He was obviously implying that by keeping my mouth shut, I was proving my lack of value to the company.  I never really held it against that engineer, who wasn’t a bad guy.  But he reminded me of a problem in the corporate world, this belief that you have to always be talking.

I default to keeping my mouth shut when I don’t have anything important to say.  This probably is the result of being a child of divorce, but regardless I’ve always hated how much noise and talk are valued in our society.  Twitter is just a permanent gripe session, talk radio (whether the in-your-face conservative or sedate NPR variety) is just ceaseless hot air, and the more channels of communication we open up, the worse it becomes.  In the corporate world, decisions are often made in meetings based on the opinions of the most verbally aggressive in the room.  There is an underlying assumption to this approach to decision making:  that the loudest have the most valuable opinions, and the quietest the least.  But isn’t the opposite the case?  How many loudmouths have you known who spout nonsense, and how many super-intelligent quiet people do you know?  Some of the smartest people I’ve met are introverts.  And yet we seem to think if you’re willing to express an opinion loudly, then you’re worth following.

The problem with meeting culture in particular is that it doesn’t value thought.  I once had a VP complain to me that someone couldn’t “think on his feet”.  Most of the time, thinking on your feet doesn’t mean thinking at all.  It is simply reaction.  Thought takes time.  It requires reflection.  In corporate culture, we often prize how quickly you react, not how deeply you think.

This is not to say introverts should never try to overcome their shyness, nor that vocal people are always less intelligent.  However, I think as leaders in the corporate community, we can take steps to improve our meeting culture so that unheard but important voices have their chance to contribute.  This can be done a few ways:

  • Ensuring equal air time for participants in meetings.  If someone is talking too much, limit his time.  Call on the quiet folks and introverts explicitly to get their opinions.
  • Don’t make major decisions in meetings unless there is legitimate time pressure to do so.  At the end of a meeting, allow people to go back and reflect on what was discussed, possibly run through it in a chat room, and reconvene later when people have had time to think about the subject at hand.
  • Stop evaluating people simply on how much they speak in meetings.  Realize, particularly if you are a vocal-type, that people contribute in different ways.
  • Try to minimize interruptions in presentations and to save questions for the end.  I like to hear a presenter lay out a story in a logical fashion, and when presenters are constantly interrupted, it disturbs my ability to follow.  For those of us who are more contemplative thinkers, our ability to participate is hampered when presenters can never finish a thought.

Part of the problem is that many, if not most, who rise to leadership positions in the corporate world are the verbally aggressive and highly vocal type.  They often cannot understand how anyone could possibly approach things in a different way, and take quietness as a sign of weakness, indecision, or unintelligence.  For those leaders, recognizing the value of quieter individual contributors and leaders will help them and their organization.

Now that I’m done spouting off it’s time to log off for some silence of my own.

I’ve written before about my years at the San Francisco Chronicle, my first job which was exclusively network engineering.  It was an interesting environment, as this was back in the years before the Internet totally displaced newspapers.  We had printing plants to support, active newsrooms with reporters and photographers, and a massive circulation operation.

When I first arrived, our Internet was provided by a T1.  At the time, the 1.5 Mbps was considered pretty fast, but with over 1000 users depending on the T1, it was slowing to a crawl.  The T1 was terminated on a good old-fashioned Cisco 2500-series router.  Later I upgraded our service to a T3 and terminated it on a 7204VXR, which led to a dramatic speed improvement.  The 2500 sat in an open, free-standing rack in the corner of our data center.

One day I noticed that the Internet was down.  Even though this was the early 2000’s, Internet connectivity was already critical, especially at a newspaper.  The problem quickly escalated to the CIO and I scrambled into action.  I could reach as far as the firewall, but there was no connectivity beyond that.

Sometimes the best thing to do is to physically check on a problem.  The networking team was in the basement and our data center was on the second floor.  I sprinted up the stairs and badged in to the data center.  One of our mainframe operators, who worked in the data center grabbed me and asked “hey, do you know the Internet is…?”

“Yeah, yeah,” I said and ran to the rack with our T1 router and DMZ switches.

I saw a gentleman in white painters clothes with a paint roller in the corner.  He was painting the wall right along side the rack.  There was only a few inches of clearance between the rack and the wall where he was rolling paint.  On the side of the rack, held in place with plastic zip ties, was a power strip with all the rack’s hardware plugged in.  He’d hit it with the roller and knocked out the power.

Network engineers love to solve complex problems, but when people are yelling at you it’s a relief when the problem is simple.  I flipped the switch on the power strip and Internet was restored as soon as the router booted up.  Someone had obviously placed the power strip on the wall-side of the rack figuring it would minimize the chance of it getting bumped.  They had inadvertently created the problem they were trying to solve.  I told the painter to stay away from my rack.

Networks are complex entities, but often the problems we face involve bad splices in holes in the ground, physical obstructions to WiFi signals, loose connections, and rogue paint rollers.

 

We all have weaknesses, and one of mine is that I’m good at starting things and bad at finishing them.  Two years ago (gasp) I had started writing a series about technical interviewing.  I wrote two posts (here and here) on the subject and never finished.  A recent commenter asked for me to keep writing on the subject, so here goes.

Whenever we, as hiring managers, post a job, we have a specific idea in mind of what the ideal candidate would look like.  We are looking for a combination of skills, personality, experience, and credentials.  The fact of the matter is, we can create an ideal candidate in our head, but that person does not exist.  We will never hire this fictional person, so we have to look for the closest match.  We need to decide which of these skills, credentials, etc., we are willing to compromise on, and which are non-negotiable.  Historically, the process for deciding the match used two pieces of input:  the resume (or CV) and the interview.  The resume provides a rough view of how close the candidate is to the ideal, whereas the interview allows the hiring team to explore more deeply the closeness of the match.  I said “historically” because I’ve seen some companies using newer techniques, such as administering programming tests.  I’ll leave these newer techniques aside to focus on the interview.

The interview is an attempt to evaluate the candidate’s “fit” by asking questions of the candidate.  The largest part of this effort is trying to understand if the candidate’s skills fit with the skills we believe are required for the job.  A secondary part of the interview is assessing the candidate’s personality and “soft” skills.

How do we assess technical skill?  Let’s say the job we are hiring for is a low-level network engineer.  We need someone who has basic skills in configuring Cisco switches, routers, and wireless.  We want someone with a basic understanding of TCP/IP, IOS-XE, NX-OS, routing protocols like EIGRP and OSPF.  Often all these will be listed at the top of the candidate’s resume.  But anyone can put anything in the alphabet soup.  The interview is our chance to determine whether the alphabet soup is true.  (Hint:  DO NOT put anything in your resume you are not comfortable talking about.)  There are generally two ways of doing this.  First, we can assess the candidate’s hands-on experience with these technologies.  We can use questions like:

  • Did you work with EIGRP in your last job?  If so what did you do with it?
  • How much hands-on experience do you have with NXOS?  Tell me the environment where you configured it and what specifically you did.

In this case, I’m trying to understand whether you’ve worked with the technologies and how much you have worked with them.  You might claim experience with NXOS, but you only looked at “show interface” outputs in your last job.

The other way I can assess technical skill is by asking theoretical questions about the technologies in question.  For EIGRP, for example:

  • Can you tell me all the different components of the EIGRP metric and which are the defaults?
  • What is an EIGRP SIA condition and how would you go about resolving it?

Any skill is a combination of theory and practice.  If you don’t understand the theory behind a wing stall in an airplane, you won’t be able to resolve it, but if you don’t go out and do stall practice in the airplane, you also won’t be able to resolve it.  Most interviewers will use a combination of these techniques to assess your competency.

Another technique is to provide a theoretical scenario.  I can get up on the whiteboard and draw a bunch of OSPF areas with different types and ask you how routing would work between them.

As an interviewer, I now need to think about your answers and how they align with what I’m expecting.  What if you know a lot of EIGRP theory, but you’ve never configured it in the real world?  What if you know a lot about switching and routing but nothing about wireless?  And, most importantly, how do you compare to the other candidates I’ve interviewed?  The other strong candidate might know a ton about wireless and nothing about routing.  I also have to consider whether I want a “ready-made” engineer who can just walk in and start working, and how willing I am to provide ramp time to the hire.  If you know you’re stuff in routing and switching, but don’t understand wireless, I might assume your overall technical competency will enable you to learn wireless with relative ease.

How effective are these techniques?  Well, if I remember to continue with this series, I’ll discuss it in the next article.

I started this blog in February 2013.  Amazingly, I’m closing in on ten years.  It’s certainly turned out differently than I expected, and I haven’t written as much as I’d liked.

In 2016, I hired a company to update the blog and design a new theme.  Maintaining your own WordPress blog is a lot of work, and it was worthwhile to have an expert fix things up.  I was fairly happy with the results, although there are a few glitches in the theme that annoy me.  The tile layout was never my favorite, and it gets really uneven depending on whether I choose a featured photo or not.

Anyways, with the WP updates over the years, my theme is breaking down.  On the editing page, many buttons don’t work at all.  I contacted the original company, which still exists, but I haven’t been able to get a response.

Over the next few weeks, I’m going to experiment with the built-in WP themes to see if there is one I like.  Expect the look and feel to change from time to time as I explore options.  Hopefully it won’t throw off the spambots that seem to be my primary readership!

I thought I’d take  break from Cisco Live to relive some memories in another Netstalgia.

Working in product management at a Cisco business unit, we are constantly talking about the latest and greatest, the cutting edge of technology.  It’s easy to forget how many customers out there are nowhere near the cutting edge.  They’re not near any edge at all.  When I worked at a Gold partner, I got to see all sorts of customer networks in a variety of states.

I remember one customer who ended up spending a lot of money with my company.  They were (and are) a major grocery chain in the United States.  They had reached a point when their network was grinding to a halt, and they needed help.  They had two overworked network engineers running things, and I remember being amused that their company policy required them to wear ties in the office.  This was not a financial company in San Francisco, but a discount grocery chain in a very relaxed part of the East Bay.  Anyways, they had hosts dropping off the network, performance problems, and their mainframe kept losing contact with its default gateway.

Walking in to these kinds of situations, you’re never sure what you might find.  Oftentimes the problems aren’t clear and the customer gets frustrated with their hired gun.  In this case, the very affable in-house engineers were thrilled to have experienced help.  They explained to me that the entire network, a large corporate office and countless stores, were on a single /8 network.  Only the on-site data center had a separate subnet.  Even the remote sites were in the /8!!

It got worse.  The stores were connected to HQ with IPSec VPN, but the hardware VPN devices they were made by a company that no longer existed.  The devices kept failing, and one of the network engineers had a stock of them he had purchased on eBay.  He amazingly was using his electronics skills to perform component-level repairs on the devices, cannibalizing parts from the eBay stash, which enabled him to stretch the stash longer than if he had simply swapped them.

My favorite was the data center.  The mainframe was sending constant pings to its default gateway, which would occasionally drop packets, in which case the mainframe would declare the gateway dead.  I found out that the default gateway was none other than a 2500-series router.

An old 2503 router

Even in 2009, this router was ancient history.  It had an old AUI connector on it which was nearly falling out.  In their 100 Mbps environment, they were limited to 10 Mbps.  I seem to recall it was doing router-on-a-stick on that interface, hairpinning traffic, but I don’t think the 2500 could do subinterfaces, so I may be wrong.  Anyways, the poor little 2500 was being slammed by traffic and dropping packets from time-to-time.

The ubiquitous CentreCOM AUI 10Base-T transceiver

I spent months at the client.  We designed a subnet scheme, renumbered their network, installed ASAs for IPSec, cut over all the stores, and put some high-end switches in the data center.  They were a grateful client, never complained, and I was able to make a genuine improvement in the lives of their users.  Unlike that other client I wrote about before.

I have a lot of bad memories of working for that partner, but one of the most interesting things was walking into so many different customers’ worlds, seeing what they dealt with every day, the mistakes they had made in building their networks, and helping them out by fixing those mistakes.

Getting a session at Cisco Live is not a given, even for a Principal TME.  I started at Cisco in October 2015, and I certainly didn’t expect to present at, or even go to, Cisco Live Berlin in January 2016.  Normally, there are three ways to secure a session at CL:

  1. Submit an idea during the “Call for papers” process about six months before a given event.  The Session Group Managers (SGMs) who manage individual tracks (e.g., security, data center) then must approve it.  It can be hard to get that approval.  SGMs need to have faith in your ability as a presenter, as well as believe your topic is relevant and unique.
  2. Carry over a session from the previous CL.  If you’ve presented a session, you can check a box in the Cisco Live management tool to ask for it to be carried over to the next CL.  Again, this is dependent on the SGMs approving it.
  3. Be handed a session by somebody who had it approved, but is not going to present it.  Perhaps they are leaving, taking a new job, or just don’t want to do it any more.  Usually the SGMs need to approve any re-assignments as well.  (You can see the SGMs are rather powerful for CL.  It helps to know them well, and it hurts when they turn over!)

When I joined Cisco, I was assigned to a wonderful and humble team working on programmability.  We met and discussed the various assignments and approvals we had for Cisco Live, and they kindly offered my two:  booth duty for an Ansible with Nexus demo, and a session at DevNet called “Automation with NXOS:  Let’s get started!”

A Principal TME is a director-level position, and normally a PTME would not be expected to spend all day at a booth.  However, since I was new to the company, position, and team, I decided it would be a good idea to do some of the grunt work a normal TME does, and experience booth duty.

My 2016 Berlin CL Booth before opening

As for the DevNet session:  DevNet, Cisco’s developer enablement team, runs a large section of the Cisco Live show floor.  DevNet has theaters which are open-seating and divided from the rest of the show floor.  A typical CL breakout takes place in a room, whereas DevNet sessions are out in the open.  In 2016, it was pretty easy to get DevNet sessions, and nobody cared when the team re-assigned it to me.  I had a free trip to Europe and plenty to do when I got there.

What you see at Cisco Live is the fruit of months of preparation.  I had to develop the entire booth demo from scratch–I was supposed to have help from another TME from a different team, but he was totally worthless.  I set up the lab and wrote the demo script myself.  For the DevNet session, I pulled together slides from my colleagues and did my best to master them.  Keep in mind, I came to Cisco after six years at Juniper.  I didn’t know a thing about Nexus, and programmability was new to me.

Every new speaker at CL is required to undergo speaker training, so I signed up for mine.  In 1 hour the non-technical trainer gave me a few pointers.  I’ve been through enough speaker training in the past that it wasn’t terribly helpful, but the box was checked.

Arriving in Berlin, I registered at CL and as a speaker and staffer was given an “all-access” pass.  I could go anywhere at the show.  Personally, I’ve always loved having backstage access to anything, and so I headed to the World of Solutions (WoS, the show floor) and spent a long time trying to find my booth.  WoS before it opens is a genuine mess–people running cherry-pickers and forklifts, laying down carpet, and well-dressed booth people all contending for space.  There are usually challenges getting the demo computers up and running, connected to demos back home, etc.

WoS is a mess when we arrive

Working a booth can be frenetic or boring.  The positioning of my booth and the content of the demo (Ansible automation of NXOS) did not generate a lot of traffic.  I spent hours standing at the booth with nothing to do.  For the occasional customer who would show an interest, I’d run the demo, and possibly do a little white boarding.  Then, reset the demo and wait for the next guy. It wasn’t a lot of fun.

Eventually, the time came for the DevNet session.  I was really nervous for my first time in front of a CL audience. Would I mess up?  Would I choke up due to nerves?  Would my audience ask questions I couldn’t answer?

Seeing your own name on the board is exciting and nerve-wracking

As I said, the DevNet sessions are presented out on the show floor, and it’s a terrible speaking environment.  It’s noisy, you cannot hear yourself, and the participants were given headphones so they could hear.  It was like speaking into a void.  I remember one gentleman bouncing between sleep and wakefulness, his head nodding down and then coming alive again.  The presentation was not one of my best, but I got the job done acceptably and the participants filled out their paper score sheets at the end.  I mostly had 5’s, and a few 4’s.  At that point DevNet sessions did not receive an official score, so my numbers didn’t “count”, but I could show them to my boss and get some credit, at least.

My wife had traveled with me and we took a few sightseeing trips.  We saw the amazing museums on Berlin’s “museum island” and also hired a driver to give us a tour.  We had several team events around the city–Cisco Live is famous for parties–and ate some very good German food.  One of my colleagues was well known for arranging parties that went until four or five AM, and many TMEs would show up to their 8am session with only a couple hours of sleep.  In fact, one of the other Hall of Fame Distinguished Speakers claims this was his secret to success!  I myself, avoid parties like that and spend hours in my room practicing my presentation before giving it.  To each his own, I suppose.

Ah, the perks of Cisco Live!

Network engineers are a breed unto ourselves, and I think we have a distinct feeling of community.  Our field is highly specialized, and because we often have to defend our domain from those who do not understand it (“it’s not the network, ok?!”), we have a camaraderie that’s hard to match.  I left Berlin on a real high, feeling more a part of that community than ever having been there in a Cisco uniform, and having gotten up in front of an audience.  I didn’t know what my future held at Cisco, but it was the first of many such experiences to come.

The last Cisco Live I attended was in Barcelona in January 2020.  As I was in the airport heading home, I was reading news of a new virus emerging from China.  I looked with bemusement at a troop of high-school-age girls who all had surgical masks on.  Various authorities told us not to wear masks, saying they don’t do much to prevent viral spread at a large scale.  The girls kept pulling the masks on and off.  I thought back on my performance at Cisco Live, and looked forward to Cisco Live in Las Vegas in the summer.  Who knew that, a few months hence, everyone would be wearing masks and Cisco Live,  physically, would be indefinitely postponed.

For Technical Marketing Engineers (TMEs), Cisco Live (technically Cisco Live!) measures the seasons of our year like the crop cycle measures the seasons of a farmer’s year.  Four times annually a large portion of our team would hop on an airplane and depart for Europe, Cancun, Melbourne, or a US city.  Cancun and Melbourne were constant, but the European and US cities would change every couple of years.  In my time with Cisco, I have traveled to Cancun and Melbourne, Berlin, Barcelona, Las Vegas, Orlando, and San Diego to present and staff Cisco Live.

A trade show may just be a corporate event, but for those of us who devoted our career to that corporation’s products, it’s far more than a chance for a company to hawk its products.  The breakout sessions and labs are critical for staying up-to-date on a fast-moving industry, the keynotes are always too high-level but with entertaining productions, and the parties are a great chance to connect with other network engineers.  CL was fun for participants, exhausting for those of us staffing it, but still my favorite part of the job.

Cisco Live was originally called Networkers, and started in 1990.  For many years I badly wanted to go to this temporary Mecca of networking technology, but I worked for companies that would not pay the cost of a badge and the travel fees, a total of thousands of dollars.  Even when I first worked at Cisco, from 2005-2007, as a lowly TAC engineer I never had the opportunity to attend.  My first trip to CL came in 2007, when I was working for a Gold partner.  They sent several of us to the Anaheim show, and I remember well the thrill of walking into a CL for the first time.  I walked the show floor, talked to the booth staffers, and attended a lot of breakout sessions of varying quality.  I was quite excited to go to the CCIE party, but I’m not sure why I thought a party full of CCIEs would really be all that exciting.  I remember hanging out by myself for an hour or so before I gave up because I didn’t know anyone there.

The same partner sent me to Orlando in 2008 as well, just barely.  The recession was starting and we were short on cash.  My boss wanted me to share a badge with a colleague, and I didn’t like the idea of having to juggle time slots nor or trying to explain to security how my name could be “Nguyen”.  Thankfully, they ponied up the cash for a second badge.  I’m not a fan of loud music, so I generally don’t go to the CL party, but for Orlando they opened up Universal Studios for us and the aforementioned Nguyen and I, along with a couple others, had a great time on the rides and attending the Blue Man Group.  (OK, some loud music there, but it is an entertaining show.)

I attended CL once more before I came back to Cisco–in 2014, ironically, as an employee of Juniper.  Somehow I convinced my boss to give me a pass on the grounds of researching what Cisco IT was doing.  (They do present at Cisco Live.)  I remember sitting in just a few rows back at the keynote as John Chambers presented, amused I’d be bringing a report back to Juniper about what I’d heard.

 

My view of Chambers at CL 2014

It was actually at Cisco Live when I first got the idea to be a technical marketing engineer.  It’s a bit embarrassing, but I sat in a presentation given by a TME and thought, “I could do better than this guy.”  It took a few years, but I finally managed to get into tech marketing.

I became a Principal TME at Cisco in late 2015 and was told I’d be presenting at Cisco Live in Berlin in January, 2016!  Needless to say, I was thrilled to be given the opportunity, humbled, and more than a little nervous about standing up in front of an audience at the fabled event.

It’s been a sad year in so many ways.  After I came home from Barcelona in January 2020, I received another Distinguished Speaker award and knew I would be inducted into the Hall of Fame.  This was a dream of mine for years, but instead of standing up in front of my peers at Cisco Live Vegas to receive the award, it was mailed to me.  There would be no show floor, no breakouts, no CCIE parties.  The event would go virtual.  I must say, I am impressed with the CL team’s ability to pivot to a virtual format in so short a time.  Still, it was a sad year for those of us who organize the event, and those who were hoping to attend.

In the next couple posts, I thought I would offer a little behind-the-scenes look at how we put on CL, and look at a few events from the past.

My first IT job was at a small company in Novato, California, that designed and built museum exhibits.  At the time most companies either designed the exhibits or built them, but ours was the only one that did both.  You could separate the services, and just do one or the other, but our end-to-end model was the best offering because the fabricators and designers were in the same building and could collaborate easily.  The odd thing about separating the functions was that we could lose a bid to design a project, but win the bid to build it, and hence end up having to work closely with a competitor to deliver their vision.

A museum exhibit we designed and built

The company was small–only 60 employees.  Half of them were fabricators who did not have computers, whereas the other half were designers and office staff who did.  My original job was to be a “gopher” (or go-fer), who goes for stuff.  If someone needed paint, screws, a nail gun, fumigation of a stuffed tiger, whatever, I’d get in the truck and take care of it.  However, they quickly realized I was skilled with computers and they asked me to take over as their IT guy.  (Note to newbies:  When this happens, especially at a small company, people often don’t forget you had the old job.  One day I might be fixing a computer, then the next day I’d be hauling the stuffed tiger.)

This was in the mid-1990’s, so let me give you an idea of how Internet connectivity worked:  it didn’t.  We had none when I started.  We had a company-internal network using LocalTalk (which I described in a previous post), so users could share files, but they had no way to access the Internet at all.  We had an internal-only email system called SnapMail, but it had no ability to do SNMP or connect beyond our little company.

The users started complaining about this, and I had to brainstorm what to do when we had virtually no operating budget at all.  I pulled out the yellow pages and looked under “I”, and found a local ISP.  I called them, and the told me I could use Frame Relay, a T1, or ISDN.  I had no idea what they were talking about.  The sales person faxed me a technical description of these technologies, and I still had no idea what they were talking about.  At this point I didn’t know the phone company could deliver anything other than, well, a phone line.  I wasn’t at the point where I needed to hear about framing formats and B8ZS line encoding.

We decided we could afford neither the ongoing expense, nor the hardware, so we came up with a really bad solution.  We ordered modems for three of the computers in the office:  the receptionist, the CEO, and the science researcher.  For those of you too young to remember, modems allow you to interface computers using an ordinary phone line.  We ordered a single phone line (all we could afford).  When one of them wanted to use the Internet, they would run around the office to check with the other two if the line was free.

A circa-1990’s Global Village modem

The reason we gave the receptionist a modem is amusing.  Our dial-up ISP allowed us to create public email addresses for all of our employees.  However, they all dumped into one mailbox.  The receptionist would dial in in the morning, download all the emails, and copy and paste them into the internal email system.  If somebody wanted to reply, the would send it to the receptionist via SnapMail and she would dial up, paste it into the administrator account, and send it.  Brilliant.

Needless to say, customer satisfaction was not high, even in those days.  Sick of trying to run IT with no money, I bailed for a computer consulting company in San Francisco and started installing the aforementioned T1s and ISDN lines for customers, with actual routers.

If ever you’re annoyed with slow Wi-Fi, be glad you aren’t living in the 1990’s.