Avoiding dot-bomb 2.0

[Submit your own tales of IT woe! Email them to offtherecord@infoworld.com and receive a $50 American Express gift cheque for your trouble.]

I was a VP of development at a site trying to attract a specific demographic slice, one that we all thought would be highly valued by advertisers and individuals alike. With several tens of millions of dollars from investors, we had a huge staff, lots of partner contracts, and a completely unscalable architecture. And calling it architecture is kind; it was a hodgepodge of tools and hand-coding that meant implementing anything took inordinate time and human resources.

I came in after launch and, having worked at more traditional companies, tried to bring some process order to the chaos. The young wunderkinds who largely staffed the company believed in the popular Silicon Valley mantra that the old rules didn’t apply on the Web, and they were determined to do the opposite of “established” technology and business practice. Little things such as budget approval processes, project management planning, requirements scoping, contingency planning, and the like were too 20th century for this crew.

With executive backing, I started to rationalize the processes and encourage the technology group to do the same for its tools. But it was too late. The Internet mania of the time meant that the context was constantly shifting, so with such a hodgepodge business and technology environment, we could not be agile as was necessary.

For example, when it became clear that the content that our advertisers (and investors) wanted us to deliver was ignored by our actual audience, we couldn’t change our Web site quickly enough to try a different mix that would work for both the audience and advertising needs.

And when AOL began insisting that we redesign our Web site to conform to its standards instead of the Internet’s, we had to duplicate all our processes and manually rework our tools to accommodate their increasingly difficult requirements. (Remember that at the time, in the late 1990s, AOL had constructed a successful walled garden and was intent on building those walls even higher; its huge traffic led many companies to go along with their dictates, even pay AOL to carry their pages on its site.)

The product wasn’t right, and the tools and processes to change it were just not up to the task. On top of it, we had the AOL requirements that sucked up even more time. Twelve-hour days were the norm, and they weren’t enough. We had two rounds of layoffs in three months as the investors got scared.

After those three months, the company brought in a new VP who would solve our problems, with a reworked technology platform and wiser content strategy. She was clearly there to replace me, although that, of course, was never said. I left, after working up my recommendations and providing a detailed status on where everything stood. She was surprised, expecting a fight, but she wasn’t the problem, so I didn’t see the point of blaming her.

Two months latter, she was gone, having realized that the technology underpinnings and unbaked processes would require a year to change — and the management and investors were not going to wait for that, never mind invest more money. They had already squandered a year rushing pell-mell into the business with no real plan; the bad business and technology platform had sucked up most of the investors’ money, and the end of the dot-com boom was beginning to be visible, so there was no more money to be gotten.

The site limped on for a few more years, with an ever-shrinking staff count. But it never had a chance.