(This is chapter 25 of my ongoing memoir of the Internet industry.)

Monday morning, February 15, 1999, first day at my new job. I stand outside a slender homey townhouse on the corner of 22nd Street and Fifth Avenue in the tony section of lower midtown Manhattan that likes to call itself Chelsea even though Chelsea is two blocks west.

I’m looking up at the iVillage main office, a converted residential space with a gilded dome and a bright yellow flag hanging over Fifth Avenue: “iVillage.com: the #1 Women’s Network”. Across the street, the breathtaking Flatiron building looms over Madison Square, harmonizing with the faux-Venetian Metropolitan Life tower on the far side of the park.

IVillage.com awaits me, but I like it better out here, because I know I’m in for a crazy first day once I walk in this door and report for duty. I let the Nas track on my Sony Walkman play to the very end. Squeeze out every last second of freedom before I start meeting people and getting drawn into the drama.

I had been hired to take over a technology team in total disarray. As Chief Financial Officer (and my new boss) Craig Monaghan explained during my interview, a near mutiny had taken place among the system administrators, the team that managed the web server infrastructure. They were furious about the hours they worked, their low pay, the shabby way they were often treated, the fact that the company was about to make a killing on the stock market and none of them had big options deals.

Communication had broken down completely, Craig told me. They were refusing to go to meetings, refusing to answer emails, refusing to take on any project work beyond the minimal effort required to keep the website alive. They had rejected their last manager the way a body rejects a kidney transplant.

The company’s Wall Street underwriters had been appraised of the emergency, and there was a serious risk that this problem could harm the upcoming IPO. Craig was scrambling to find a new Chief Technology Officer with serious crisis-management experience. In the meantime, they needed somebody like me, a hands-on techie and seasoned middle-manager, to go in there and calm things down. My job was simple: talk to the disgruntled employees, earn their trust, get the wheels moving again until a new CTO shows up to provide long-term direction.

In a phone call the week before my first day, Craig filled me in on the cast of characters I would meet. The lead sys-admin and ringleader of the mutiny was a woman named Camille. Based on Craig’s description, I imagined her as some sort of otherworldly angry goth. “Ring in her nose, crazy hair, I can’t understand anything she says”. She was the one causing all the trouble, Craig said. If she called off the mutiny, everything would go back to normal.

He then filled me in on her team of three. Ted, a happy-go-lucky hippie, knew the most about the Apache web servers and Cisco routers. Mikey, smart but “just plain mean”, was the expert on the Vignette-based content management system. Mozam was a shy database administrator who never said a word. This gang, Craig told me with a solemn stare, was completely devoted to Camille, and Camille was completely devoted to them. The four techies had the entire fate of iVillage in their hands. They had “root”, the ultra-secret primary passwords to all the machines. Even beyond the root passwords, they were the only ones who knew how everything worked.

I was excited to face the challenge of working with this group, though after struggling for years with my own feelings of anger and frustration at my last job it felt surreal that I would be playing the role of mediator between other frustrated and angry people. This, I figured, was something I ought to be good at. Grievances? I could relate. Heavy emotional conflicts running rampant in the workplace? I knew all about that.

In fact, I’d been developing a theory that better use of psychology could work miracles in the modern technology-minded workplace. Everybody had seen projects go sour, and often sought out rational or logical explanations for what went wrong. In fact, despite the veneer of business-like behavior, I was pretty sure the conflicts that tore technology projects apart were often rooted in raw emotions.

It was worth looking at these conflicts more closely, I thought as I pondered the responsibilities that awaited me, and trying to identify patterns that repeated. The problems were sometimes so familiar, the players may as well have been following a script.

The script begins when a businessperson and a techie at some company are introduced and given a task to carry out. They don’t know each other, so this is their first meeting. They go over the requirements, and this initial encounter is very happy, high hopes, all smiles. Maybe the techie and the businessperson go to lunch together, or go to Starbucks, because they want to take the time to get to know each other.

This project, they pledge together, will be a success. They will avoid the pitfalls that doomed so many other tech projects before. They will plan, they will communicate, they will leave plenty of time for testing and for “the unexpected”. For once, they both deeply believe, everything will go smoothly.

The techie then retreats for a couple of days to produces a detailed schedule, say, a three month schedule, which includes two months of development time and one month of testing. If they are working for a large company, maybe a third person is brought in, a project manager to review the plans and make absolutely sure the plan is rock solid. The techie, the businessperson and the project manager all sign off on the plan and agree that this project is bound to be a success. Emails full of exclamations like “Great!” and “Thanks!” are exchanged. The three month schedule begins.

The techie is excited to finally get busy, because this is a type of work he’s never done before (in our fast-moving times, software development trends change so fast that almost every project requires a techie to learn something new). He sits there thinking, preparing to jump in, the entire system a wide-open vacant space before his eyes. Where will he begin?

Any good techie knows the answer: he will do the hardest parts first, because that’s where the uncertainty lies. He sets up his environment and his database and begins coding whatever part of the system he is most unsure about or unfamiliar with.

It starts off badly. The documentation for the open source tools he plans to use is horrible, and all the code examples are for a different environment. The first few days are frustrating, disappointing, because he has to surpass several annoying environmental barriers before he can even begin to address the key requirements. He plugs ahead and finally he’s there, at the core of it, plugging directly into the data objects and the algorithms that will form the building blocks of the system he plans to build.

Now he’s putting the pieces together, seeing the components work, prototyping different events and use cases, putting the software through its paces. He marvels at how beautiful it looks when his prototype starts to resemble his wireframes. He works and works. Weeks pass. He begins to feel mastery over the software. Just a few weeks ago he’d begged for advice on how to use these unfamiliar software tools on public message boards. Now, he’s learned so much that he can go to these same message boards and answer questions that other newbies ask. He feels the thrill that always accompanies the achievement of expertise. He gets it.

At this point, the techie loves coming to work every day. He couldn’t be happier. He’s working nights and weekends, not just because he’s still behind schedule but because, secretly, he’s enjoying it. He goes on a date and sits there thinking about his software. He goes to a movie and realizes afterward he doesn’t know what the movie was about because he was thinking about his software.

But he worries when he looks at his schedule, because he realizes now that he’d neglected to think about some of the trickier problems he would encounter, details that looked simple on paper but turn out to require immense amounts of complex code. Improvisational hacks become necessary. Rickety bridges between incompatible data sources must be built. Then, three weeks before the day testing is supposed to begin, he discovers a serious flaw, a major misunderstanding about how the pieces will fit together, an oversight so obvious that he’d be embarrassed to have anyone find out he hadn’t anticipated it.

So he goes into overdrive to find a solution to this problem. He’d hoped to be ahead of the game by this point in the schedule, but he’s not. He tried to work on the hardest problems first, but now he realizes that the problems he thought would be the hardest weren’t. He starts to panic about the fact that he might blow the deadline. He’s now working nights, weekends, holidays, nonstop. He can’t fall asleep at night, and when he does he wakes up at 4 in the morning haunted by visions of project failure.

He plugs away, tries one workaround and then another and then another. Finally, two days before the deadline, after several feats of engineering so beautiful and original the techie secretly believes they belong in the Coder’s Hall of Fame, he realizes that the pieces fit together. He’s there. He did it. The system works. He made it to the other side.

And here’s where the switch happens, the break. The techie is now exhilarated, delirious, full of himself. He may even rush into the businessperson’s office the next day at work: “It’s done!” He’d managed to solve every major problem. He’d met the deadline. Spent, limp, there’s nothing he wants to do more now than rest, recoup, bask in the praise.

The businessperson, however, is in a different state of mind. He’s barely thought about this project in the last two months, because he has plenty of other aggravations to deal with. When the techie rushed into his office yelling “it’s done!” the businessperson had barely been aware that the deadline had arrived.

The businessperson is also a little confused by the techie’s strange exhilaration. While the techie had spent the last two months riven by fear that the development effort would fail, the businessperson simply took it for granted that the techie would be able to build the system. That’s what techies do, after all, isn’t it? Of course he was able to do it. It was his own plan, his own schedule.

But then he takes his first look at the system the techie built, and he sees that the screens aren’t exactly right. Various design elements are in the wrong place. He runs through his first interaction and the whole thing immediately crashes. It’s a mess. He doesn’t know what’s going on.

He sends back a friendly and perky email with a hearty “Thanks! Looks great! But there are a few problems …”

The techie receives this email and is crushed. Of course a few design elements are out of place. That’s the easy part. Design? Who cares about the design? The thing works!

It crashed? Yeah, of course it crashed, because the businessperson is on a different network and certain permissions aren’t set up correctly. Big deal. It works. The difficult problems are all solved. This is the easy stuff.

Confused, the techie goes into the businessperson’s office, but the meeting goes badly. The businessperson can’t even understand what the techie is talking about, and it shows on his face. “Is it done, or isn’t it?”, the businessperson asks, confused and frustrated.

If it isn’t done, the businessperson wonders, why does this techie keep saying it is? And if it is done, why does it look terrible, and why does it keep crashing?

By the end of this sad week, this techie and this businessperson will have begun to hate each other. The project’s final month will be a bitter and punishing trek. The techie will now refuse to work overtime — “why should I work so hard for this asshole?” — and so the remaining fixes and changes will be an aching grind, much to the chagrin of the project manager, who swooped back in for the final month only to find a schedule in disarray and two team members who used to like each other but now refuse to sit in the same room.

What happened, the project manager wonders, to “this time we’re going to do it right”?

This scenario describes just one of several “design patterns for agony” in the web development or software development industry. A good name for this design pattern might be “premature exhilaration”. Everybody meant well. It wasn’t really anybody’s fault.

Monday morning, February 15, 1999. I stand at the corner of 22nd Street and Fifth Avenue, looking up at the slender building that beckons me to enter. It’s a strange feeling to be free, momentarily free of all the heavy karma from my last job, and not yet sucked into the heavy karma that awaits me at my next one.

I let the Nas track on my Sony Walkman play to the very last beat, thinking about the situations I’m about to face, the well-meaning but angry people I’m about to meet.

Then I flick the Walkman off, let out a deep sigh, and walk in the door.