Case Study: Enabling Change at AOL

Related link: AOL in HTML

Telling your editors they will have to trash everything they’ve been doing to publish articles - and every trick they’ve learned to speed the process - isn’t usually what earns an ovation. But that’s what happened 10 months later when AOL News editors saw the first demonstration of their new publishing system.

Even if your publishing system is the clunkiest thing in the world, editors and their habits are difficult to separate. With a new publishing tool, editors can’t work on autopilot. That sort of change is naturally unsettling.

How do you move your newsroom from grumbling about change to embracing it?

Involvement, transparency and over-communication.

Absolutely crucial to the success of creating a new publishing system for AOL News was the involvement of the editors who really liked their current publishing system. They were the ones who helped guide the process of abandoning it for a new system. That meant they made sure that all the qualities they loved about the previous system were in the new publishing tool, too. They didn’t feel as if they had to give up advantages by switching. Instead, they switched the advantages to a more powerful and flexible publishing system.

Advantages of publishing with 'Rainman'

AOL still publishes most of its pages on a proprietary publishing system called Rainman, short for Remote Automated Information Manager. It’s really a wonderful publishing system – but more wonderful and more suited for the world of 14.4 and 28.8 modems.

Rainman publishes physically small and digitally light pages that download surprisingly fast on a 28.8 modem. Where a Web page might be 80-100k large, a Rainman page is 5-10k. This is accomplished in a highly templated environment where the only things allowed on a page are the text of an article, a small photo and hyperlinks.

Rainman pages are published through the use of scripts that define what template to use and what part of the template you wish to publish. It’s easy to learn, and once you’ve written these scripts for the various pages you publish, you save the scripts and just insert the new text or the new jpg.

Competitive editors in the highly charged online news environment like Rainman because it has a speed to market of 1-2 minutes for a breaking news story. Rainman makes it easy to beat the competition.

Other benefits of Rainman are that after using it for about a decade to publish news, AOL has built a “server farm” that easily handles the 23-25 million unique users who read AOL News each month. This infrastructure easily handles more than 3 million simultaneous users so that for major events like Sept. 11, 2001, or presidential election nights, AOL News doesn’t crash.

When you tell your newsroom that this system is being chucked for something new and untested, editors rightly have many questions and immediately fear that they will lose their competitive advantage.

Involvement

The way to make a paradigm shift like this is to involve your editors constantly in the process of change. Change of this magnitude cannot be dictated from above. It has to bubble up.

For all its significant competitive benefits, Rainman also has significant drawbacks. It’s not a databased solution that allows dynamic publishing of pages or personalization. It does not allow editors to create interactive, multimedia environments on each news page because it does not allow embedded content objects within the text. It does not allow a lot of content on a page because the pages do not scroll.

Knowing that the AOL Newsroom really liked the Rainman publishing system -- mainly because it was easy to use, had a great speed to market, scaled wonderfully and did not crash on big days, I tried to help the process of change bubble up from the newsroom.

I started in September 2002 by calling a brainstorming meeting and asking the staff to offer up ideas for their ideal publishing tool and system. What would that tool do? This process was made easier by the fact that AOL had too many publishing tools and editors were being driven crazy by all the different applications they had to use. They wanted one publishing system that they could use for all the facets of their job.

Transparency

The editors’ list really was a litany of the shortcomings of their current publishing tools and was incorporated into the first pages of the product requirements document for the new publishing tool. In other words, we made the statement that if the new publishing tool can’t do what we need, we don’t want it. Such a statement empowered the newsroom and told them that this tool will meet their needs or will be rejected. I showed the newsroom the requirements document and showed them that all of their ideas were the basis for the new publishing system we were creating.

The requirements were written by the editors who would be using the publishing tool and by the engineers who would be creating it. Rather than have each group work in isolation, we closeted the editors and engineers for three weeks so that they each could have a clear understanding of what is desired, why it’s needed and why it can or cannot be created in the desired timeframe.

Engineers and editors – two groups who don’t usually speak each other’s language – came to understand each other’s point of view. Both ended up invested in the success of this new publishing system.

The success of this partnership is evidenced by the fact that it’s not uncommon for me to get an e-mail from any of the three engineers who developed our new system that says something like: I’ve been checking out the pages you’ve been publishing, and I see that you’ve started to do things we didn’t anticipate, so I’ve modified the code in the publishing tool to make it a lot easier for you to create this or that content module.

Over-communication

In working with the editors, I over-communicated what was happening each week during the News Channel redesign and the publishing system creation. I frequently sought editors’ opinions and ideas. At each weekly staff meeting, I reported the progress – or lack of it -- on the tool development. These meetings often caused the editors to think of new things they would like in the publishing tool and started a discussion around tool features and work processes. I regularly told them what would be in the first version of the publishing tool, what would be in Rev. 2.0 and why.

At every milestone review, in which we saw a piece of the new tool in action, I brought different editors to comment, analyze and give feedback to the engineers while they were still coding, so that the editors actually could see their ideas take shape in the publishing tool.

We had meetings specifically to talk about how our work processes would change and what the day would be like using the new publishing tool.

I held a contest to name the new tool, with the winner getting dinner for two in Washington, D.C. The staff submitted about 25 names, then voted. They chose “Wheeler” in honor of Dean Wheeler, the founding managing editor of AOL News who died last summer of cancer.

Once the publishing tool was delivered, we had an excellent training manual and training classes designed by the group that built the new publishing system. Editors went through two days of training on the new tool, and then had three weeks to play with it to populate their areas of responsibility in the new site. Training was conducted jointly by the engineering group that created the tool and myself so that there always was someone in the room who could answer the editorial questions, process questions or technological questions.

When the editors saw how easy and intuitive the new tool was to use, (mainly because it matched their current workflow) and how it allowed them to do so much more and do it fast, they became believers. It took them no time to see that the new publishing tool allowed them to be multimedia producers and much more creative editors.

I measure the success of this process from comments I received from the editors. They told me they can do the rote part of their job noticeably faster and can use the extra time to build out story packages with more relevant multimedia and community content modules. One editor said, “What am I going to do with all my free time, now?”

Believe me, I had an answer.