work Archives - Page 3 of 5 -

Computer Analyst: William Mercer, 1994-1995

A headhunter I knew called me while I was at Abbott Labs, encouraging me to check out a new job. Although I was happy at Abbott, the challenge sounded interesting, so I went on the interview.

William Mercer, a large New York based insurance company was launching a new venture which they called the Mercer Administration Center (MAC). This was to be a service to outsource employee medical insurance management for large corporations. They had been at it for a year, but were facing some major challenges, many of them, it seemed, HP computer related.

The idea of being involved from the ground up in a new venture sounded good, and they wanted me to take over total ownership of the computing requirements, including showing them how to properly separate the phases of the software development lifecycle (Development, Test, Production.) In addition, they were offering a significant increase over what I was getting from Abbott, and the drive from home was less than half the distance. So I accepted.

After a few weeks I started to understand what had happened there. Seems that the “subject experts” — the ones responsible for figuring our all the ins and outs of a medical insurance management system — didn’t really understand the business. As a result, the company failed to deliver as promised to their first big customer, Pepsi. They had quoted a one year development time, but then failed to tell the customer until after 11 months that they were not going to meet their own deadline. When Pepsi asked how much longer they needed, they said “another year!” Remarkably, Pepsi agreed…

I did my job and established a proper software life cycle computing environment, and trained the programmers on how to properly use it. Over the months that followed, I became very uneasy because it was apparent to me when attending business meetings that they still seemed to have the same problems. Soon, it became clear that one upper level manager based in Louisville was actually lying about the project to the Mercer Insurance parent company! He was (again) re-assuring management that they were on track, when in fact everyone knew they were a mess.

I could clearly see that they were going to miss delivery, probably by another year! So I jumped in (because I’m not the type to silently watch something like that), and at a company meeting where that manager and others were re-assuring all the staff that everything was on schedule, I stood up and asked how they expected us to believe that when we could see that things were still a mess. There was a bit of a tense exchange, and I stated that Pepsi was highly unlikely to grant us another year to complete the project. The meeting, needless to say, became quite noisy, and was quickly ended. Afterwards I was approached by many employees, thanking me for having the guts to state publicly what we all knew was true.

However, I could see the writing on the wall, so I called up my friendly headhunter and said I was ready to move on. Luckily, he found me a great position — because a few months later, William Mercer found out the truth and pulled the plug on the MAC, shutting it down permanently.

I.T. Manager: VP Unix Systems, Information Resources Inc, 1996-2001

When I wanted out of my job at Mercer, my headhunter quickly found me a position at Information Resources in downtown Chicago. I already had a reputation as being a very good problem solver, and IRI was having some problems. But what convinced me even more was that this position carried a vice president title, and paid a lot more that I was making.

My first interview was with a consultant who worked long-term at IRI. He was older, and quite technical. In the interview I got the idea that he wasn’t telling me the whole story, so I pressed him about the problems. He then pulled out a paper from his desk and explained what was going on. Even during the interview, I had some suggestions, which he got excited by. A few days later I was called in for a second interview with one of the “Group Presidents”. The one pressing question that was concerning him was “What if we have a major failure on a Friday night or Saturday, and you can’t be reached?” — To which I looked him in the eye and said “If I am the only person in my organization that can fix the problem, then I’m not doing my job.” He loved that answer, and I got the job offer.

By the way, although I was impressed by the “vice president” title, this was a very large company, and they had about a dozen VPs!

When I came on board, I found out that the Unix servers were repeatedly crashing for all sorts of reasons, disrupting work for clients, and severely affecting data delivery times. (IRI processed scan data from retailer sales, both providing analysis and raw data back to the product manufacturers and distributors. Getting the data in a very timely manner was critical to keeping up to or ahead of competition in the retail space.)

In my third week, while I was still getting to know people and evaluating the situation technically, I was asked to participate in a video conference with Proctor and Gamble. In those days a video conference was a big deal — required a special room with thousands of dollars of equipment and a dedicated high speed line. What I discovered was that P&G was IRI’s biggest customer (millions per year), and they had almost 1000 people whose job it was to analyze the data we supplied. If we were late by even a day, that was 1000 people being paid to sit on their hands!

Although they understood that I was new, they pressed for a fix to their problems. Without really knowing yet what was going on, I promised them a short-term fix within two weeks, and a longer-term fix within 3 months. I basically went out on a limb, just trusting my technical instincts, knowing that these systems should be stable.

Long story short, I found out that the people managing the servers had not applied system software patches for over two years — because, in their words, they were “too busy fighting fires”. Well, those fires were mostly due to the missing software patches! I brought in HP themselves to quickly bring the systems up to the latest patch levels (dozens of software patches were missing), and in a week we suddenly had almost no outages!

I made quite an impression in the first year, solving many similar issues. Some problems were much more complex, but I was not only technically proficient, I was very good at bridging the gap between the technical staff and the business staff, so I was able to get both sides to understand each other better and work out difficulties.

I’ve posted a few interesting emails from the first year. One of the major products at the time was called “Timeshare”, and was basically a portal into our servers that our clients could use to access our analysis programs. The actual packages of analyzed data were called “InfoViews”. Some of these terms may appear in the posted emails.

I will create a couple of separate posts covering specific episodes of my tenure at IRI.

My Timeshare Letter Download

The above letter was written immediately after I returned to my office after a company meeting. It was to my staff but of course I copied senior management.

The snippets below are some of the replies I got to that letter, which management forwarded to many departments, and to the events of the meeting in general.

I.T. Manager: First in Chicago to adopt Blackberry pagers, 1997

As a technology manager, one of the most critical needs is for easy and accurate communications. Cellphones were not yet in general use, and until the late 1990’s, every IT group carried pagers. Those pagers simply beeped to tell you that someone needed a call back, and displayed the callback number; then you had to get to a wired phone to call in.

In 1997 a Canadian company called Research In Motion (RIM), and also an American company, Motorola, each came out with an interactive pager with a keyboard. Being always interested in new technologies, and in a position that allowed me flexibility within my own budget, I immediately requested samples of each one to test them.

What I found, was that the RIM pager was far and away the better device. It was clearly designed by people who actually needed such devices and used them personally. Just as one example: When the Motorola pager received a message, you took it off its holster, flipped open a cover, and pressed a button to open your message. When the RIM pager received a message, you took it off its holster and looked at the screen — a tiny magnet in the holster signaled to the pager that it had been removed, and triggered the message to be displayed. This small difference was huge in situations like board meetings, where it was possible to discreetly slip out the pager and glance down at the message.

There were many other advantages, which I detailed in a comparison chart, feature by feature. When I showed my little chart to the RIM salesperson, he practically begged me for a copy, saying it was better than the sales materials the company had provided!

In any case, having done my evaluation, I ordered these RIM pagers for everyone on my team. Although the company was RIM, these devices were known by what I presume had been a development code name and then became identified as this device — the Blackberry pager. [Many years later, RIM actually re-branded their company as Blackberry.]

These devices could run numerous “apps”, including email, note-taking, instant messaging, etc. The instant messaging was quite unique, and was the first instance of BBM (BlackBerry Messenger). It pioneered many of the features that we today associate with Whatsapp and the like — a notification that you message was sent, a further notification that your message arrived on the recipient’s pager, and yet a further notification that the recipient had read the message. Seeing that little “R” show up was very comforting, knowing that your message had been seen!

A few months after we started using these Blackberry pagers, I was on vacation in Florida, on a beach with the family. My pager alerted me, and it was a critical situation that I had to quickly mobilize several team members and tell them exactly how to proceed. A few months prior and I would have had to leave the beach and find a phone. But I was able to use BBM to quickly reach the needed people and explain what they had to do. The “R” notification gave me the assurance that they got the messages (no possibility of someone saying they never got the message!) and they were able to chat with me in real time with any questions. The situation was resolved quickly without me having to disrupt the family beach time! I was very impressed; it was clear to be that Blackberry was going to be a corporate fixture!

One of my original Blackberry pagers, turned on in about 2015, with some old 2003 email messages still in the inbox!

I.T. Manager: IRI Y2K project, 1999-2000

Anyone who had anything to do with computers towards the end of 1999 will remember the industry panic over the “Y2K problem.”

For those who may not, here’s the situation in a nutshell: Since commercial computer programs were created from the 1960’s on, programmers needed a way to signal to the program that processing was complete; that there was no additional data to be processed. Back then, the assumption was that those programs would certainly be replaced within a decade, so it became a convention to use the year “00” to signify “the end”. No one ever thought about more than a 2-digit year until the 90’s.

Suddenly, in the 1990’s it became clear that there were tens of thousands old computer programs still running everything from payrolls, to elevators, to air traffic control… and many of them were programmed to stop working if they encountered “00” as the 2-digit year!

Lots of experts sounded the alarm that every company worldwide would have to embark on a huge “Y2K (year 2000) project” — to test, certify, and possibly re-program systems to ensure that they would keep working when the date flipped to 01/01/2000.

Like companies everywhere we at IRI also had to re-certify every piece of software that we used. This was a bigger effort than it sounds like. We had to find times off-hours when systems were less busy, to simulate the change of date and test each program’s operation. Code that failed had to be examined re-coded, and re-tested. I had a team devoted to this testing. Luckily in our case, most of our software was not so old as to have used that old “end processing” convention, so there were few failures. Still, everyone held their breath when 01/01/2000 actually arrived. I had team members out at the data center at midnight just in case something slipped though testing.

After the successful date transition, I presented a small gift to each of my Y2K team members. It was the latest gizmo: a digital music player. No, the iPod didn’t exist yet for another 10 years! This was a unit called the Diamond by Rio. Although the appearance inspired the Apple iPod, the “wheel” was just a series of buttons.

This device came out in 1998, sold for about $200 with 32 MB memory for about 30 minutes of music! But wait! For another $200 you could pop in a whopping 64MB card and then hold a full 90 minutes of music. The team loved them!

I.T. Manager: IRI, the EDT project, circa 1997-2001

One of the difficulties of IRI’s data delivery to its customers was that many of the monthly files were very large. In those days most electronic transfers were slow and often unreliable, especially with very large files. So most of our deliveries were on tape cartridges, send to our customers.

Although this had been working for some years, it was fraught with problems. The tape creation process was finicky, and often had to be restarted. Sometimes delivered tapes couldn’t be read by the customer and we had to create a new set, resulting in an additional 2-day delivery delay.

In particular, we have very large monthly deliveries to our offices overseas — the U.K., Italy, France, etc. These had become especially problematic. No one understood why, but most of the time one or more tapes in a delivery set couldn’t be read. They suspected airport x-ray screenings, so they actually started having someone hand-carry them to Europe! However this didn’t solve the problem.

Much effort had been spent on the mainframe side (where the tapes were generated), yet they could not determine the cause of the problems. So they next tried using FTP to electronically move the files. However, in those days, FTP had file size restrictions, and it was also unreliable and non-recoverable — meaning that if the transfer failed 2 hours into a 3 hour transfer, it had to be started over from the beginning.

I was approached to see if I could help. After some thought, I proposed a software solution that I would engineer and program with the help of one of my staff. There was some skepticism (especially from the mainframe folks), but I was given the green light to try.

I had three main objectives: (1) Transfer any size file 100% reliably, (2) maintain security (data lines were not very secure, and much of the data was considered proprietary), and (3) engineer a solution that our client IT departments would be willing to install on their systems.

The third of those requirements steered me towards developing the entire system using only Unix scripting rather than any compiled language, and in a way that did not require special system privileges. As an IT manager, I knew that would be the only way to overcome any client objections.

I designed a system based loosely on package deliveries by the likes of FedEx. I defined each delivery as a package, with an accompanying manifest. Much like when you ship a lot of goods, you divide your shipment into smaller packages, my large files would be split into “chunks”, each of which would be sent separately, re-assembled at the receiving end based on the manifest. For reliability, if any “chunk” failed to deliver (verified by a mathematical checksum), the system would proceed with the other chunks and only later re-deliver those chunks that got missed. In that way, an unreliable line would never force a restart, simply require one or two small chunks of the delivery to be resent.

Obviously there was a lot more to this, but that’s the nutshell version. The EDT system (as I called it) became quite a success story. Clients were thrilled because it cut a day or more off their delivery times; the European offices saw a 4-5 day reduction. Even more importantly, once in place there were zero errors!

I’ve attached a number of email images, and a full slide show that I presented live to Frito-Lay in Plano, Texas.

EDTSlideShow CLICK OR SCROLL TO SEE ALL PAGES

A partial client list of companies that I got onto the EDT platform

The following are clips from emails ( bragging rights 🙂 )

Consultant: IRI lead-up to exit, 2001-2002

After 911 (Sept 2001) many businesses suffered as the economy sank. IRI was already in some business trouble versus its competitors before that, but this made it much worse. Everyone could see that we were in for some significant layoff, although we didn’t know exactly when or how bad it might be.

In mid-2001 I was “offered” a different role in IRI — still a VP, but as an “Internal technical consultant.” There were two reasons for this — 1) The poor business results caused the board of directors to toss out some senior management (including the brilliant founder, Gian Fulgoni) and replace them with their old cronies. To some of these stodgy managers, I was a “threat” because I was outspoken and known to be very innovative. 2) Although never confirmed, I believe that they were preparing for the layoffs that they knew would be coming, and it would be easier to retain a lower-paid younger worker in charge of the Unix groups, and would be easier to “justify” laying off an older manager in a “consultant” role.

Be that as it may, I accepted the change, because it actually allowed me to do more of the sorts of things I was interested in. I spent more time expanding and enhancing the EDT product, and also took a lead role in charting a course for replacing IRI’s “Load balancer” — software to move batch jobs around to various servers to make best use of the total computing power. We had a legacy load balancer that was no longer supported and did a poor job. I was charged with finding a new product and working out the migration path. After sourcing the best product, I worked with the software vendor to make a number of changes that I was able to demonstrate would vastly improve their product, changes that they actually implemented.

Small anecdote: When we were still about two months away from making the load balancer move, we suddenly had a serious failure of the old existing product, and it was significantly hurting the business. Since a young guy was now in charge of the Unix systems, I left it to him to solve the problem. He poked around a bit and declared that it was not able to be fixed, and that we needed to move to the new system. Senior management asked me if we could switch, and I told them we were not ready to make that move yet, still waiting on some of the software vendor’s changes and full testing. So there was a meeting with the group president (the same one who did my second interview and hired me). At the meeting, when it was strongly stated that the current system couldn’t be fixed, he looked at me and asked me directly if I agreed with that opinion. I said I did not; it seemed to me that whatever the problem was could be discovered and corrected, allowing us the time to get the new system ready. My answer infuriated the new guys, but the president simply asked me “How long do you think it would take to get it fixed?” Not knowing anything about the problems, I replied “48 hours.” I remember there were chuckles and a few gasps — they had already been dealing with it for over a week. I simply trusted my diagnostic skills and felt that I could do it. They gave me the green light to take over, and I locked myself away in my office and started examining the system, logs, files… anything that might give me a clue. I got to a point where my intuition told me that there must be corruption in a certain key file, and further, that if I removed it, the software should re-build it. I had no proof of this, just a strong technical intuition. So I removed the file and fired up the system — and we were back in business. Total time: about 12 hours, much to the astonishment of many (and the chagrin of those who said it couldn’t be done.)

By January 2022 the company did its first massive round of layoffs — between 150-200 people, many middle managers. I was one of them. Over the next year, they laid off many more, and outsourced all the computer work to India. They then took the company private (had been traded), and within another year they were a shadow of what they had been. When I joined IRI they had about 55% of their market; that steadily dwindled staring in 2001, and today they are less that 15%.

I’ve attached a couple of documents just as an example of the complexity of the projects I was leading, and maybe to show off my communications skills (I was known at IRI to be excellent in both written and verbal presentation skills. Several times I addressed groups of 20-50 people to present and explain a new technology project… the teacher in me I guess.)

Load Balancer Replacement – Product Selection CLICK OR SCROLL TO SEE ALL PAGES

LSF Discrete job flow steps slideshow CLICK OR SCROLL TO SEE ALL PAGES

Entrepreneur: Best Value Guide, circa 2003

After the layoffs in 2002, I figured I’d land a new job pretty quickly, as I had always been able to do. What I hadn’t counted on was the massive number of people looking for work after the economic downturn post 9-11. Although I applied to lots of places, there were dozens of applicants for every job, and many were young, lower-paid yet skilled people. I found out pretty quickly that a 50-year old former VP who had been earning 6-figures was not in demand when companies could get someone in their 30’s who would work for way less. Even my long-time headhunter told me to forget it — at least for a few years.

After trying hard to find something for a few months, I figured I’d try some other avenues on my own, while I waited to find “real” work. Luckily I had a decent settlement from IRI, and also a chunk of IRI share options that I was able to exercise (I flipped them when the stock price was at about $12; less than a year later their stock was under $2)

I had an idea to create a site oriented around the rather new concept of “affiliate links” (common today) in which you got a commission on sales companies made by customers who got to them via links on your web page. There were a few such sites already, but they were unabashedly just tons of links — basically advertising. I wanted to create something that people could have some trust in.

I purchased the URL “BestValueGuide.com”, and proceeded to design my site. Since my concept was trusted referrals only, I created a set of criteria that I could use to rate vendor sites. These included things like how easy it was to navigate their site, how long it took me to find a support phone number, whether they disclosed their actual address, and a lot more that I no longer remember. I created a survey form, and personally evaluated each potential site before I would list their link. Further, I would write a brief paragraph about what I felt were the vendor’s strengths or best products. And if a site failed my evaluation threshold, I did not list it even if it paid good commissions. I wanted to have the only “honest” affiliate link web site out there.

For its time, I think I did a good job of the design and presentation of the site. Where I failed was in actually marketing MY site. So although I did make some money through the links, it was not much, and I slowly lost interest. Too bad I didn’t pursue it harder, because it could have become big. Once again, I was a bit ahead of the times.

I found a few site snapshots on an internet archive site. Just before I abandoned the effort, I had added a parallel “layer” that I intended to be targeted to professionals rather than consumers. So I planned that my Best Value Guide would have a consumer face, and a B2B/Professional face.

Here are the few screenshots I found, including a sample page of actual store listings…

Photographer: Hershel Belkin Photography (take one: kids), 2001-2006

While I was dabbling with web-based income possibilities, I decided to try to go back to one of my main passions — photography. I had been going out and doing landscape photography for my own enjoyment for a few years, but in order to make money I had to change my focus (pardon the pun!)

Combining my passion for photography with my love of kids, I decided to try my hand at kids portraiture. Starting with word-of-mouth, I got a couple of bites, and was immediately successful — my first client spent several hundred dollars on portraits of their kids!

I created a very simply web site, then over the next few years, re-invented to website a few times to improve on it. I found a few screen shots on an Internet archive site, included below. Although I called myself “Hershel Belkin Photography”, I took the URL “belkinder.com”, which I thought was cute, combining “belkin” and “kinder”.

I posted the first few business cards that I created (starting with a really horrible one!), and I found a few sample of my early work, posted here as well.

On the first web page I actually had a GIF that demonstrated the merging of “belkin” and “kinder”:

Found this archive of my very first photography web site. Featured image is missing…

Next generation site:

A few early samples:

Teacher: Bnos Rabbeinu Girls High School, 2006-2017

When the new girls’ high school was started, I felt obligated to help with it. So I got as involved as I could on a very part-time basis. In the very early years, I would have all email that was sent to the students directed to my computer and automatically printer so I could drop it off at the school each morning. (Students didn’t have email of internet access, and phones were still pretty rudimentary and were not allowed to have data plans)

I also took on the role of helping with the physical aspects of the student dorm — mostly safety, including locks, keycode entry system, stove gas line shutoff lock boxes, light bulb changing, electrical, air conditioners, laundry equipment, … you name it! Given that these kids were away from home with no one really looking after their day-to-day needs, and knowing that I’d want such care if my own kids were out of town, it felt right to provide this needed help.

Eventually I also started teaching one course per week to grades 11&12 — at first photography, then later a physics course that I really enjoyed. I found a great book call ” How Things Work” that was used as a basic physics course in some university arts streams, but I wanted it to be even simpler. In consultation with the author, I modified the course to remove all the math — creating a “conceptual” physics course. Wherever I could I’d merge Torah concepts or at least the amazing symmetries and workings of physics that could not be considered accidental.

I thoroughly enjoyed teaching (as I had enjoyed teaching in University), and got special satisfaction from interacting with these young people and feeling like I was perhaps making a bit of a difference in their lives. Many of these kids were from difficult family situations, including broken homes, abusive homes, poverty, etc.

Teaching — even though it required a lot of preparation (I used to go to Starbucks for a few hours on Sunday to prepare my upcoming classes) — was a great source of satisfaction for me at a time when my career had taken a back seat due to being laid off and unable to get back into my field due to my age.

In the last few years, I taught a basic computer course, introducing such things as Word, Excel, and basic computer literacy in Microsoft Windows. I also gave a several-part seminar in internet and connectivity (cell phone) safety. My belief was that kids should be aware of all the dangers (spoofed emails, viruses, online bullying, dangers of chat rooms and groups, etc.) rather than simply being forbidden to use these services, because all kids will find a way to access them even if they are forbidden. For that class, I arranged for the school to get a number of refurbished laptops, which I then configured for safe classroom use.

Being the only technical person directly involved with this tiny school, I took on the role of technician for the annual production (after first getting approval from a Rav because of singing). I ran a laptop control of projected images and videos, and also helped set up all the rented audio equipment.

During a photography class exercise taking “advertising” shots, someone snapped a photo of me at my desk…