Case Study: Disruption

Back in the 1980s I worked for a computer timesharing company. We had a large mainframe computer with a proprietary operating system and a corporate internet with nodes all over the world. Our customers used dumb terminals (a monitor with a connection to a mainframe) to do their computing work, and they paid by the minute. We had the world's largest (or second largest) corporate internet, and a large customer base of companies such as insurance companies who needed more processing power than was available elsewhere.

My division, Data Services, provided databases that users could access, and they paid based on usage (so much per data point). Data Services provided statistical software that ran on our mainframe and could be used for the timesharing fee. We provided enormous economic and financial databases, but really shone in the areas of energy and aviation.

My colleagues were extremely bright and forward-thinking and we were in a constant state of innovation, but in many ways we were always a few years behind the rest of the world. When I started there in the mid-80s PCs were already widely used in business, but my terminal had no monitor, just a wide paper feed: all input and output was recorded on paper. After a while we upgraded to dumb terminals and then to PCs. Our customers used acoustic couplers to connect (a kind of modem where you put the handset of your phone into connectors), and I worked on helping them move to faster modems. I attended endless meetings where we grappled with alternative ways to deliver data to customers, such as floppies, CDs, and quarterly downloads. We fretted over ways to modernize our pricing, and one of my jobs was to create pricing models to estimate the effect on revenue from alternatives such as subscriptions, or unlimited and report-based pricing. It was a bitch teaching our workforce the basics of PCs, and transitioning our developers from APL to C++.

As data storage and processing power exploded, the basic business of the company, computer timesharing, became anachronistic. Eventually the company was purchased, cherry-picked, and mostly shut down. But in a lot of ways the company was ahead of its time. We had software that changed traffic lights for emergency vehicles decades before others produced anything as sophisticated. My division, Data Services, was a leader in value-added data and statistical analysis software. We were achieving good profits and growth right to the end.

When I was eventually laid off I was traumatized. I had been so invested in my work that it was like slamming into a brick wall at 70 mph. That was 25 years ago but in some ways I haven’t recovered. I worked at RIM when it became clear it was failing, back in 2012, and couldn't stand the idea of suffering through another slow death: I jumped ship as quickly as I could, but for a year I maintained an almost obsessive watch on the company, checking the stock price and reading the analysts and pundits daily.

My experience with a failing company led me to pick up Clayton Christensen’s The Innovator’s Dilemma some years ago. It seemed that we fit his thesis (PCs disrupted the timesharing business). It was (and is) important to me to understand why bright people - who realized their predicament, had the will, and had the resources to change – couldn't make it. Christensen’s contention that you can’t make substantive change from within, but need to start a new subsidiary, is pretty compelling.

Despite its strengths, the book didn't pass the smell test for me. It is too simplistic, too dogmatic, too anecdotal, and inappropriately universal. Christensen seemed most intent on proving that we have to throw out old values and instincts, that we have to adopt a new way of doing business that is even more ruthless and cut-throat than before. It seemed more like propaganda than theory: another phase in the right-wing attack on civilization, a new libertarianism for the private sector. The smartypants premise is that the best and the brightest must admit defeat to the small and the weak. The innovator’s dilemma is that “doing the right thing is the wrong thing.”

I don’t have a copy of the book and I don’t want to critique it, but I am energized by Jill Lepore's fantastic piece in the New Yorker (link). This is the first in a planned series of articles about what Lepore calls the disruption machine.

On indexes

I love indexes. I love using a good index and I love creating a good index. All this dates back to my childhood and cookbooks. The Joy of Cooking, in those days, had an index that was truly a joy. The person who created it (perhaps Mrs. Rombauer herself) knew cooks well enough to know what they would be looking for, and gave us a long, redundant, gloriously usable index.

Mastering the Art of French Cooking, on the other hand, had an index created by a moron. Although Mastering the Art was published in two volumes, Volume II had a combined, color-coded index that always threw me. Worse, there was a confusing use of French and English terms. Look up mustard and you found some entries; look up moutarde and you found others. I bet that Julia Child passed off the indexing responsibility to a flunky.

Every couple of years Mrs Rombauer published a new edition of The Joy and she revised the recipe selection, the recipes, and the index. It was a true process of continuous excellence. Mastering the Art, on the other hand, has not been revised, except to update for new equipment (such as food processors) and changes to ingredients.

It is not uncommon for doc managers to task junior writers to index the works of senior writers. It's not just that you need to understand content to do a good job indexing it; it's also that indexing is a good exercise for a writer to do as part of their content creation. It's a second level check of your content organization. It's also a way to implement reader issues you might be aware of. For example, if you're documenting MS SQL Server and you know that some readers will be more familiar with Oracle, you can index some Oracle terms such as System ID for Database Name.

There is a growing movement in the tech writing biz that indexes are unnecessary. I see the point for online help; numerous studies (including my own) have shown that readers prefer to use Search (and in fact, they often prefer to use Search in Google rather than within the doc). But if you publish PDFs that your readers will print, then you need an index. And if you're going to have an index, you should make a good one.

At a conference years ago I attended a lecture on indexes given by an academic. His theory was that indexes should train the reader to use correct (his idea of correct) terminology. The example he gave was of a home first aid guide he had once worked on. He declared proudly that he had changed the index entry for "collar bone" to "collar bone: see clavicle". I don't know what he said after that because I walked out.