A Truck Full of Money (4 page)

Travel was just something that Paul liked to do. What he really cared about was building new engineering teams. In a jaunty moment once, he said, “For me businesses exist as an excuse to get a team together, and product is what a team does. You have to pay salaries, so, unfortunately, you have to make a profit.” Creating teams and managing them were his version of the business romance. He loved his own large biological family, he would say, but at times he felt as though at Kayak he was building another family, better in the sense that he could choose its members and fire those who didn't work out.

He used to have his own website, where from time to time he posted his algorithms for recruiting and hiring. He actually practiced some of the techniques he described. His usual pitch was seductive. In effect, he'd tell recruits that they had higher aims than simply making lots of money, and he'd congratulate them for it. High-tech America was vying fiercely for the best programmers and web designers. Paul could offer stock options and, eventually, competitive salaries, but all the people he hired could have made at least as much elsewhere. The extra thing he had to offer was his enthusiasm, aimed at recruits. He told them they were “awesome,” “rock stars,” “monster coders” who could “knock down buildings with code,” and it seemed that in many cases both parties believed it.

Paul's recruiting might have served as the subject of a business school case study—called, let's say, “Why the Traits of Effective Leadership Can't Be Codified.” A young engineer whom he had recruited to Kayak described Paul's courtship: “Maybe it's a technique, but within the first five minutes of meeting someone, Paul will tell them something personal: ‘I broke up with my girlfriend last night,' or ‘I was completely wasted.' It's disarming, especially if you know this is Paul English. Then you start to think of him as this empathetic being that you can totally relate to, and before you know it, you've totally fallen for him. I don't think people are loyal to him because of his innate managing ability. It's very stressful to work for him. He gets superemotional about stuff, and he changes his mind all the time. But ten minutes after meeting him, you think, ‘I will follow that person.' And somehow that continues. People who make a strong first impression often pale, but not Paul. And I think it comes from knowing somehow he's someone you can trust and count on.”

Recruiting and hiring were one of Paul's great loves, his knack for them perhaps his greatest pride. He hated firing people, though you would not have known that from reading some of his interviews in the business press. In the December 2010 issue of
Inc.
magazine, for instance, he was quoted as saying: “The only way 100 people can ever build a larger company than one that has more than 8,000 people—that's what Expedia has—is by hiring Olympic-quality, unbelievable all-stars of technology.” To preserve that very high standard, firing people was also necessary, and not just a few: “I do all of the firing. At times, I've fired maybe one out of every three people I've hired. That might make people think I'm bad at hiring, but I think I'm quite good at hiring.”

This sounded tough, and doubtless it was meant to. But Paul in action was more humanist than tyrant. According to one of his assistants from Kayak's early days, he once threw up in the bathroom the morning before a firing. He still offered to meet with each fired person outside of work. He would say, “It totally fucking sucks. I hate this. I have been fired myself. You can still be a rock star at some other company.” Reassuring words for some perhaps, and dubious comfort for others, but he also tended to give the fired people very generous severance packages and to help them find other jobs. The first person he fired was a woman, a monster coder according to Paul, whom he had reluctantly let go. He said he once argued with her for an hour as to whether or not she was argumentative. Nine years later she seemed to feel that she and Paul together had decided she should leave. They were still correspondents and, she said, still friends.

Paul sometimes rated employees on the letter scale. He said he wanted an engineering office with nothing but As, and ideally he wanted A-pluses. On another occasion, though, musing about his engineers, he referred to one who was a solid but slow coder.

But hadn't he said he didn't allow Bs on his team? Why hadn't he fired that programmer?

Paul looked surprised. “But he's a great human being! He's a moral compass!”

Companies involved in computer technology often portrayed themselves as places of great liberality, as democratic and nonhierarchical. What this meant for employees, almost universally in the software business, was the freedom to dress as they pleased and to work odd hours—in some cases even from home. On other matters, meanwhile, the hierarchies of supposedly nonhierarchical companies typically went in for a lot of social engineering.

Paul had made it a habit to glance now and then through the transparent walls of Kayak's conference rooms, and, spotting meetings that he thought too large and long, he would poke his head in the door and with a smile, always a smile, say he was sure that three of the dozen people in there were smart enough to solve their problem in half the time they'd already spent. He also bought a tally clicker, a device that nightclub bouncers use to keep count of patrons, and hung it outside the door of the main conference room—this by way of saying, “I'm paying attention. I want meetings of three people, not ten.” He also bought a toy stuffed elephant to be present at meetings, an embodied cliché, the elephant in the room. He named it Annabell. He had hoped it would encourage shy engineers to speak their minds to each other and to him.

Programmers tend to disdain titles, and at Kayak titles were deliberately meaningless. A solid engineer might be labeled “senior engineer” while an absolutely essential one, receiving handsome bonuses, might be simply called “software engineer” or “design architect.” The person who should unquestionably have been called chief operating officer had given himself the nondescriptive title “senior vice president.” His name was Paul Schwenk, known simply as “Schwenk” or “Papa Schwenk.” The name fit him well enough. He was in his early forties, old enough to be the father of many here.

Since there were no private offices and the most senior engineers were scattered around on both floors, you couldn't read the hierarchy in the seating arrangements. But of course there was a hierarchy, and seating was carefully controlled, by Papa Schwenk and Paul. They wanted “the right balance of energy,” Paul would explain. “We like people who are loud, but not right next to each other.” At one point, Paul had dissolved his own favorite grouping, because he thought that he and the people seated around him were having too much noisy fun. Some engineers would get distracted if they had to sit too near the gregarious ones. Paul and Schwenk tried to assemble people whose tasks required them to talk to each other, but inevitably roles shifted and small clashes arose, so it wasn't at all uncommon for an engineer to come to work one morning and be told, “Schwenk moved you.”

Once in a while, a programmer had resisted a new idea of Paul's, saying it was too difficult to implement. Paul had sometimes managed to get his way by saying to the recalcitrant coder, “Okay, but can you think of anyone who's smart enough to do it?” More often, though, he had let the matter drop. He didn't usually get deeply involved in technical matters. There had been some exceptions—most notably Kayak's UI, its user interface, the webpages that the site presented to customers' computers. In Kayak's very first days, Paul had made a survey of the other online travel websites, and to his delight he'd found them all to be slow, hard to navigate, and ugly, all jammed with enough garish colors to cause, as he liked to say, an epileptic fit. He wanted his team to create a user interface that was spare, elegant, and easy to use. To Paul, this meant it had to be fast.

To prove his point, he had the team create two versions of the Kayak website, identical except that one was half a second faster in responding to the user. The test subjects all declared that the faster version was simpler. “I don't want the user thinking about Kayak, but about hotels or flights. Speed allows that,” Paul said. “I want a UI so simple that drunks can use it, with software so fast that someone who's ADD won't have time to be distracted away.” He wanted the results of users' searches to be displayed on their computer screens within a hundred milliseconds. He took this request to his chief engineer, Bill O'Donnell, known as “Billo.” For a time, Billo insisted the goal was unreasonable, even impossible. “Just try,” Paul told him. Paul harped on the matter, and finally a concerted effort was launched, and rather to Billo's surprise, it worked.

In Kayak's first few years, when Paul had time to kill in airport waiting areas, he would look for people with empty seats beside them. He'd sit down and ask them to open the Kayak website on their computers. For what seemed like a long time, those strangers would ask, “What's Kayak?” And then, around 2007, the question began to change: “Kayak? You work there? You
do
?” The UI itself, Paul thought, had represented Kayak's first successful advertising campaign, the thing that had made people like the site well enough to tell their friends about it—free word-of-mouth advertising at last bringing customers to Kayak in profitable numbers.

The idea behind Kayak was undeniably clever and the timing good: When they started, there was no comprehensive and reliable search engine for travel, and a company that was just a search engine and didn't do booking didn't have to finance a large sales force and administrative apparatus. But the annals of American commerce are full of good ideas that failed. There is always some mystery, some concatenation of things, behind a success like Kayak's. Paul liked to say the company had flourished first of all because of abundant good luck, and because of his co-founder's brilliance. And also—maybe most of all—because of the engineering team.

In a business where not even powerful companies seemed to last for long, this intentional family of Paul's had unusual continuity. Six of the first dozen people he hired for Kayak had worked for him before—and not just briefly, but at five different companies over more than twenty years. His term for these people was “twenty-pluses.” They still made up most of the engineering team's cadre. Among them, Papa Schwenk and Billo were preeminent. In Paul's lexicon, they weren't just “value-adds.” They were “need-to-haves.”

Bill O'Donnell manned a desk beside an aisle on the office's lower floor, a floor below Paul's station. You would find him sitting there working at his computer, short and stocky but fit, with a large face and thinning black hair, often dressed in a two-colored polo shirt—the sort of shirt you'd wear to a bowling league, Paul thought. Billo talked nearly as fast as Paul when he was telling a story or explaining something technical, but when he didn't have anything to say, he went quiet, and if you started to fill the silence with small talk, you were apt to find him staring at you, with no expression on his face. It was easy to imagine he was hoping you would hurry up and finish, or say something worth his commenting on. Not that he was rude, but especially when he was coding, you could stand in front of him for a very long time before he noticed you.

Paul said, “At some point everyone thinks Billo hates them.” In fact, Billo was very popular, especially among Concord's young programmers. A young engineer named Vinayak Ranade told this story: “There was a guy I worked with that I never seemed to agree with. We got along otherwise. We were just always at odds when it came to decisions about the product, and this was incredibly frustrating for me. As with everything, I ended up mentioning it to Billo. He said, ‘If two smart and logical people disagree, it's most likely because they are acting on different information.' ”

This proved to be true. Vinayak discovered that he and his colleague had been thinking about different issues, such as ad revenues versus customer complaints. Vinayak went on: “This is an example of why Billo's a great boss. In one sentence he distilled the root of my problem, showed me how to solve the problem, gave me a compliment. He didn't pretend that this was a teaching moment or that he was imparting great knowledge to me. He just told me exactly what I needed to hear at the right time. I started seeing all of my disagreements with the person in question in a different light. Since then, I've been applying this to a lot of conflict resolution or big decision situations at Kayak and even in my personal life.”

Billo was a gifted manager, and it didn't hurt his popularity among the twenty-year-olds that at forty he still wrote a lot of code himself, and did so as fast and accurately as any of them. He came from New England computing royalty. His mother, the daughter of Italian immigrants, had run engineering divisions at two important Massachusetts computer companies—a rare feat for a woman. She had majored in math at Boston College and graduated as valedictorian of her class. Unlike her, Billo had always found math difficult, but it seemed to him that he had always known how to program computers.

Paul had discovered Billo's technical talent some twenty years before, when Billo had only recently graduated with a degree in computer science from Carnegie Mellon. At the time, Paul had become a manager of programmers at a large software company. When Paul had left that place to become a vice president at what looked like a hot new start-up, Billo had followed him. One reason was that for Billo, as for others, Paul represented something rare in the world of commercial software, an adept fellow programmer who could also deal with “the suits” in a company, shielding a programmer from the sorts of administrative and political folderol that most software engineers found dull or incomprehensible or both. Paul was also someone clearly on the rise, an engineer with dreams that could translate into both money and interesting new work. The time was the late 1990s. “There were Internet start-ups everywhere,” Billo remembered. And Paul was very persuasive. He told Billo and some others that this new company—it was called NetCentric—was “a rocket ship.”

It wasn't. “That place,” Billo remembered, “was a clusterfuck of epic proportions. I wish I could teleport myself back to then and say, ‘Get out!' I left quickly. Within two months. It was an incredible experience. A horrible commute. Insane start-up hours for ultimately no benefit, and my father died that spring. I just quit. I had no other job.”

Billo took a break from Paul then, but within a year he returned, following Paul to two other companies, and finally, in January 2004, to Kayak. Paul wanted him to fill the role of Kayak's chief technical officer, the CTO. In keeping with local obfuscating practice, though, Paul took the title for himself, and Billo was called “chief architect,” which was accurate enough, at least at the start.

When Paul first told him the idea behind Kayak, Billo said, “That sounds really boring.” Moreover, joining up for Billo had meant taking a 50 percent cut in pay, at a time when his wife was pregnant with their third child. Why had Billo signed on? Partly, he said, he'd been persuaded of the commercial possibilities. “And,” he added, “the fact that I would work with Paul on any idea that was viable.”

Paul told Billo that he would assemble a technical team within two weeks, and within two weeks there was both a team and a place for them to work, a temporary office a few towns away from Concord. It was little more than a room outfitted with a large table where half a dozen engineers worked side by side, Billo first among equals. Paul had the dual gift, in the technical sphere at least, of identifying people he could trust and then of actually trusting them. He left it to Billo to manage the creation of Kayak's technology, and first of all the website's architecture—the blueprints, as it were, of a complex machine made of software programs and computers to run them. Billo remembered the job as deeply pleasurable, he and his colleagues at the table all knowing their roles, sharing a common purpose, combining into what he thought of as a “hive mind.”

Their task was to create a website that contained a specialized search engine. At the simplest level, at what programmers call a high level of abstraction, the website would first take in a user's request—for example: Tell me all the flights from Boston to San Francisco and give me up-to-the-minute seat availability and prices. Then the internal software and hardware machinery would have to travel out, as it were, on the Internet and gather the answers from other websites and data banks, and filter the results, eliminating absurd itineraries—such as flights from Boston to San Francisco via Caracas. Then the machine would have to assemble a webpage of responses and present those to the user. And it would have to do all this very accurately and quickly, within a few minutes at most—and, if the site succeeded, do the same kind of thing over and over again, millions of times a day. “It's not floating-point nuclear simulations or anything like that,” Billo would say of the chores the system had to perform. “But it does use a lot of computing.”

Billo's little team had created many websites before and knew that they often broke down under the burden of early success, under the load of rapidly increasing traffic. In their talk at the table and the diagrams they scribbled, they imagined a system that was resistant to crashing and that could grow gracefully, a system that would “scale.” Their plan didn't call for one gigantic program that would perform all the various required tasks. Instead, they broke the search engine into component parts, into about a dozen separate programs: a program that would search for flights, for instance, another that would check users' passwords.

These programs could be duplicated as many times as necessary to meet demand. The team aimed to keep all tasks discrete, so that the different software components of the search engine depended on each other as little as possible. Likewise the hardware, the computers. The discrete programs would run on many identical computers, the connections among them arranged so that if one machine broke down, another would automatically take over its work. As traffic grew, the whole search engine wouldn't have to be rebuilt but could simply be enlarged, by adding more copies of the various different programs and more computers to run them.

The start-up team worked fast. Within five months, by May 2004, they had created a functioning website. “It was actually pretty good,” Billo remembered, in a voice that sounded mildly surprised. At the start, the system broke down periodically—first at around 1,000 visitors, then at about 10,000, finally at about 500,000. As the number of customers grew, the sheer amount of computing revealed bugs in the software. More often, bottlenecks developed in the databases. Fixing the problems usually took a few hours but always seemed to take forever, the engineers working feverishly, imagining customers out there in the world, staring at the interrupted searches on their computers, glowering at those rotating globes on their screens and vowing never to use Kayak again.

There were some memorable crises. On Christmas Eve 2006, the site suddenly couldn't handle the volume of incoming traffic and was teetering on the verge of breakdown. Fortunately, just a few weeks before, Billo had created a mechanism in the software that he called “lockdown mode,” a figurative switch. He spent the night monitoring the computers in the system and when they started to become overloaded—“It's like a car engine that's lugging”—he would flip the lockdown switch. Users just arriving at the site would receive a message saying that the site was overly busy and asking them to try again in a few minutes. When people already inside the system were finished with their searches, Billo would reopen the site for a while and let some people in. “I was essentially standing at the door of a shop, letting customers in a few at a time when others left,” Billo recalled.

The basic architecture of Kayak's site and internal search engine had survived, but over the years most of the software had been rewritten and its known flaws repaired. There were still only a dozen or so discrete programs running on Kayak's computers, but by 2012, at any given moment, there might be as many as four thousand copies of those programs running, communicating with each other and with Kayak's own very large databases situated in Massachusetts and Switzerland. And yet for some time now, Kayak's website had been up and running about 99 percent of all the hours in a year.

Both Paul and Billo kept abreast of changes in the online world, talking with colleagues, reading technical reports, trying out many new things. In 2008, when the smartphone was still a novelty, they both felt sure that mobile smartphone applications would supplement if not displace web-based sites on the commercial Internet. So Paul had asked Billo to put together a team and create a handheld version of Kayak, a version to run on smartphones and notepads. Billo had chosen three programmers for the job. The mobile app they'd created was a nearly instant hit. Kayak hadn't even tried to market it, but by late 2012 it had been downloaded thirty-five million times.

Paul rated Billo the best in the company in the purely technical sphere. Of Papa Schwenk, the chief operating officer without the title, Paul said, “Schwenk is killer. He is
the
most reliable person in the company. The businesspeople in Connecticut feel totally comfortable talking to him. Like he doesn't talk in gobbledygook? And he cares about them, like really cares about them, he wants to understand their jobs and he really listens to them. And the tech people all respect him. So on average Schwenk is the most respected in the company by the most people.”

Schwenk was one of the first to arrive in the morning, right around seven, tall and thin, carrying his lunch in a brown paper bag. His gray mustache was always impeccably trimmed, his gray hair neatly parted in the middle. Add a tie and a starched high collar and he could have been a figure in a vintage photograph. He sat two dozen desks away from Billo, at the edge of the main aisle on the lower floor, an area of high traffic, a lot of it headed toward Schwenk. Not far away, another early arriver—a vice president named Jim Giza, another of Paul's twenty-pluses—would sit at his desk and listen with half an ear to Schwenk on the phone, solving problems for Kayak's European teams. “Norway, Lithuania, Berlin, Zurich,” Giza said, “at seven in the morning they're all calling Schwenk. The flannel shirt, the beat-up pickup, you never would have thought he was the guy to hold it all together. Schwenk runs this organization, this engineering organization. Every kind of decision, from what kind of sodas do we get, to what kind of server do we buy, to who gets paid what—that's Schwenk. Paul comes in bouncing, bouncing, bouncing, and if he bounces up to me, I just bounce, too. Schwenk levels him. ‘No, we're not spending eight thousand dollars on an exotic lamp, Paul.' ‘No, we're not sending the entire company to the Bahamas.' ”