Monkeynoodle.Org

One of my early steps along the path from English major to product manager was a role in the late nineties at a value added reseller in Emeryville, California. Now only visible as ripples in old records and the Internet Archive, PCS Networks was a fairly typical boutique consultancy. This type of business has a few pillar technology partners, some deep masters in those technologies, and a bench of journeymen and apprentices. PCS sported a separate sales department, complete with boiler room, but most of the shops I know like this are able to thrive on word-of-mouth alone. I was hired as an apprentice (sorry, Systems Analyst) because I’d learned enough NetWare to be dangerous, and PCS is where I learned my way around Microsoft, Cisco, and a tiny bit of IBM.

So, you’ve got sales development representatives (SDRs) calling prospects, you’ve got some masters whom you do not bother, journeymen who are solidly booked, and apprentices who only know a bit about something… and you can’t put masters and journeymen in front of every prospect. PCS found a delightful solution to this: the systems audit as a sales tool. It made a small amount of money, it created opportunities for better money, and it exposed apprentices to tech and people skills that they needed. Pipeline generation plus on the job training for your newbies, winning.

Our SDR’s pitch was something like “look, your network has probably grown like crazy lately and consistent staffing is always a challenge, let us do a fixed rate visit where we’ll just take a look and tell you what’s there. You’ll get a complete inventory, we’ll make some recommendations, but if it’s not valuable to you? No commitments.”

Here’s how it would work if the prospect bit. An over-caffeinated young doofus with a pager and a Salvation Army tie would show up with a paper pad and some pencils. The late 90’s laptop did exist and wasn’t abjectly terrible, but it was an executive’s machine. PCS certainly wasn’t giving them out to Systems Analysts. So, as the doofus on site, I would get started. As an invited service provider, I was able to talk with the admins and ask questions as I went along. I’d start with the network closets and server rooms, then work up to server hardware and software, then finish with desktop hardware and software. Write it all down, draw diagrams, ask questions. I would shoulder-surf an admin’s console access whenever possible, to see naming conventions and addresses, and look for errors in logs. Sometimes the admin would take screenshots and email them to me, but maybe not. I’d spend half a day per location doing this on average, then take the mess of papers back to the Windows 95 PC at my desk in Emeryville. There I’d fire up Word and Visio, and spend a day turning this mess of notes and drawings into a consistent inventory and coherent narrative. We had fast internet in the office (a whole T1!), so I’d use Alta Vista, Yahoo!, and Google to research all the stuff I’d found that I didn’t understand. All together, the audit document would be a solid thirty pages of stuff, with a summary something like this:

• Company has 300 employees in the office in Pleasanton at something something. The MDF uses a 3Com router as hub on a four point fractional DS-1 frame relay network (using Adtran CSU/DSUs) and a Cisco Lightstream for the office’s switching backplane. There is a five-port NetGear hub between the 3Com and the Cisco and a Sun workstation running Check Point FireWall-1. There are also five 24-port Lantronix Ethernet hubs in an IDF closet, supporting the eastern side of the office (Accounting and HR). Building wiring is mixed Cat3 and Cat5.
• The server fleet is five recent model Compaq Pentium IIs, running NetWare 4.11. Most have sufficient RAM. The backup server (Seagate) is attached via SCSI to a DAT drive, serviced monthly by Iron Mountain.
• The desktop fleet is mostly Dell Optiplex Pentiums with 16MB RAM and 4800rpm 20gb disks, running Windows 95.
• &c &c &c

The summary would actually be a lot more in-depth than that, running to two or three pages… real networks were very complex, and full of history. “Mostly Dell Optiplex… but also three dozen Packard Bell 486s, yikes, and the wiring conduits also have wads of… unused? I think? thinnet coax in them, and one of those servers has a modem attached to the PSTN for I don’t know what.” The document of course included recommendations to rebalance load, fix bottlenecks, and upgrade systems. It would be delivered by an account manager and myself, in person, on paper in a three ring binder. Maybe we’d bring a box of donuts too.

For the customer, this was actually really useful, and we’d often be hired to do some of the suggested work. That was useful for us as well of course! As a consultant, we were welcomed to come in and provide an external, objective voice saying the obvious things that the admins were unable to get heard. “That Seagate backup software? It’s out of date, but more importantly the tape drive is reporting errors. Your backups haven’t reliably completed in at least a couple of weeks.” “One of your Adtrans has reset itself, so you’re only getting 64kbps of the 512 kbps to Scottsdale that you paid for.” “If you re-cable the eastern side of the office you can put accounting and HR onto unused switched ports in that expensive Cisco and retire those junky old hubs”. “Three of your servers are overloaded and two of them are underloaded — you could try to migrate and rebalance, or we could sell you some new beefier hardware and perform the cutover for you.”

It was fun work, and I learned a ton. PCS Networks also gave a small raise for every certification test you passed, so I crammed a bunch of textbooks and visited the proctored test facility at the Oakland airport at least once a month. It’s hard to imagine what this sort of work would look like today.