Chapter 4

W. Mike Presz

M&A/Senior Advisor
SVP/GM International
Chief Technology Officer

Harvard University
B.A., Computer Science · (1983 – 1987)
Activities and Societies: Harvard Varsity Baseball, 1983-1987. Single Season Pitching Record Holder, 7-0, 1984, Harvard Varsity Club.

A journey from sports, to an elite college, to one of the most influential internet brands, yields lessons that only an insider can provide…

New Book by W. Mike Presz

TEAM CHEMISTRY…

In sports, team chemistry is often characterized by teams that play harder, play unselfishly, put team goals ahead of individual goals, refuse to quit, support teammates, and work for the benefit of the team and the organization. Often, “chemistry” is cited when teams with lesser talent “on paper” play and beat teams with more talent. As in sports, business teams can have or lack chemistry. So, good leaders need to develop team chemistry.
Match had both talent and chemistry. We went over two big events at Match in the last chapter where everyone at Match worked together for the greater good of the company. While these were two of the larger examples, everyone working together as a team wasn’t uncommon. It takes special people and an environment of trust to enable this type of behavior. This includes hiring the right people, setting expectations, building trust, and building respect, among other things. It doesn’t “just happen”. There are many things that can kill a culture. Unfortunately, these things are like a cancer. The symptoms may be minor at first. Maybe they are tolerated or people assume that they will go away. Maybe they aren’t even recognized. Often, it’s too late before any action is taken, the culture is already poisoned. Good leaders need to work hard to keep the cancer out. And, if it’s found, it needs to be cut out fast. No playing around. No maybe it’ll change. Cut it out. Good principles to follow:

Take preventative action – always be on the lookout.
Don’t ignore symptoms even if they are minor. Don’t look the other way when you see something wrong.
Recognize your own involvement in the situation. Don’t contribute directly or indirectly to the spread.

This is all easier said than done. And, if you are not in a leadership role, it’s just as important that you help make the culture positive. It’s often human nature to dwell on the negatives or to join in on the gossip train. Don’t.

Fortunately, given my background in sports, I was very successful at helping to build a good culture at Match. Ultimately, the employees made the environment what it was. However, I was passionate about developing the people and culture sides of my teams. I loved doing it and worked relentlessly at it. I spent as much time on the people side as I did on the business and technology sides. Because, at the end of the day, I was more of a coach than a player on most days. And, nobody, neither a player or a coach, can win by themselves. You’ll hear me repeat this many times. If your team gives up on you, whether it’s your players or your teammates, you aren’t going to be successful. And, they won’t be either if they try doing it alone. So, the reverse is also true, you can’t give up on them. Business is no different.

Different coaches like to play different systems in sports. In the NFL, you could be a “west-coast” offense and this is an air attack. Or, “ground and pound” that relies more on the running game. In the NBA, there are “3 and D” teams built around three-point shooting or other teams that like to pound it through the paint. All sports have different systems and teams employ them differently. Some are unique. Some become revolutionary. Some don’t work very well and must be changed. We could probably argue all day about which ones are better. However, what I believe is indisputable, is that in order to win, your players need to buy into the system and their talents need to align with that system. If you play a west coast offense you need a great quarterback and fast receivers. In addition, you need players that want to play on the team and in that system, not ones that are questioning everything. The system permeates the entire organization from recruiting, to coaching, to player evaluation, to player training, to player development, to game planning, to game execution, and everything else. And, if you get all of these things: talent, commitment, and buy-in, you are likely to win with most systems.

Business is no different. You should have a system. I did. Over the years, I have adjusted and refined my system based on actual experiences. This chapter will take you through how Match’s culture was established early on and the important takeaways that I’d like to share. First, however, I will explain the history of my early days. Team chemistry helped set the stage for major growth at the company, probably more so than many on the outside would believe. In order to help you understand more, I’ll start by taking you back to the very beginning of my tenure at Match.

The Early Days

My journey with Match started in late 2000. I received an email from Sean Moriarty, then CIO of Ticketmaster Online-Citysearch (TMCS) and eventual CEO of Ticketmaster. In Sean’s own special way, the email stated that TMCS was looking for a highly motivated, highly skilled, cigar-smoking, Harvard pitcher to come in and be the CTO of Match. Sean is a brilliant, high integrity guy who I had known for a long time. Shortly after the email, he called me to explain things. He was looking for technical help at Match. TMCS was a publicly traded company controlled by USA Networks. In May and June of 1999, TMCS had acquired Match.com and The One & Only Network. Match.com was a branded product run by a small team of consultants out of San Francisco. One & Only was an affiliate-based product and had an employee base run out of Dallas. The strategy for the combination of both acquisitions was to retain Match.com as the branding for the company but leverage the One & Only employee base in Dallas to remain under TMCS installed senior management. The consultants in San Francisco moved on after the acquisition and the Match.com product was transitioned to the Dallas team in 2000 prior to my arrival. This effort was not going well and by September 2000 revenue fell by over 50% due do major system problems. In October of 2000 refunds grew by 800% and management at TMCS had seen enough. The existing team was able to get the system back up hobbling but the damage was already done. The business impacts were substantial. Confidence in the Dallas tech team was lost and the acquisition decision was put into question. I remember on my arrival the head of finance reflecting and telling me that they “thought that they had lost the Match business forever”. In hindsight, it seems dramatic but when you are in the middle of chaos with the site down, cancellations skyrocketing, revenue plummeting and billing shut off for two months, it’s easy to feel that way. TMCS management had already tried to insert internal tech help to Dallas but this hadn’t gone well either. So, they decided to look outside the company for technical help. And, that’s why Sean called me.

I had my own technical consulting firm in the Washington DC area. I had no intention of moving to Dallas. I told Sean as much on our first call. However, Sean and I go way back and I respect him a lot. So, I told him that I would go to Dallas and check it out and at least give him a chance to change my mind. Sean and I have a similar mentality on recruiting talent so he pulled out all the stops on my visit. John Pleasants, the CEO of TMCS and Dan Marriott (TMCS’s deal guy) were with Sean in Dallas to talk with me. John and Dan are both amazing talents and I would learn a lot from both of them over the years. But, at the time, I didn’t know either of them and I was a bit skeptical about Match’s situation. I remember Dan telling me that he believed the business could be a $100 million-dollar business (it was about $20M at the time). And, John was explaining his grand vision while everything tech around us was collapsing. The tech heavy stock market had just collapsed. Match had been shut down for weeks due to systems issues. It was barely limping along on my visit. The internet back in 2000 after the dot.com collapse was still in question. It’s not like today. So, given that I’m a conservative guy, I was not sure of any of it. I also met with Cindy Hennessey, Match’s CEO, who would become my first CEO boss and who was brought in by TMCS management. Cindy helped explain her thoughts about the business and the current state of the technology group. As I learned more, I felt like this was a great opportunity for me. I wasn’t sure about the outcome but I was pretty sure that this business could be a game changer. I could be at the center of making this change happen. You don’t get an opportunity to play in the super bowl every day. When you do, you’d either have to be scared or be a fool to refuse the chance to play. I’m certainly no fool but I’d have to admit that I was a little anxious at the time. It wasn’t just the super bowl. It was that it was the super bowl and we were huge underdogs. Like four touchdown underdogs. If Vegas had odds on it, I would have probably been the longest odds on the board.

After meeting with the management group at TMCS, I met with four leaders of the Match team: the current acting CTO, the head of systems, the head of database and the head of development. All four of them reported back to TMCS management that I should not be hired. So, TMCS offered me the job anyways. That’s how bad things were and how little faith our parent company had in the existing team. I started in mid-November, 2000. Let me explain the main reasons why:

Match’s problem was that it had too much demand. It could not fulfill this demand. Customers were pounding down our doors to use our products and our technology could not serve them. I was living in the Washington DC area in the early years of AOL when AOL was growing like crazy and mailing out disks. At one point, it got so crazy that their systems got overloaded causing major issues with the service. The stock tanked and customers were complaining. It was a huge news story in the DC area where AOL was headquartered. Eventually, AOL fixed their system issues and the company soared again for quite a while. If any business has a major problem, they can only dream that it’s too much demand. What really scares me is a business with no demand. Luckily, Match had plenty of consumer demand.
I had the support of the entire TMCS management team. Sure, I had to keep that support but going in with full management support was a big deal for me. Even though I didn’t have any support from my employees (all four who met me said don’t hire me), I knew that was something that I’d have to change by earning it.
Things were really, really bad on the technology side. The business side had lost hope and faith in the technology group. They were taking down all of their business projections. Expectations going forward were in the toilet. I like these types of situations because of the following:

At this stage, white boards and theory go out the window. The business side just wants it fixed and if you deliver, everyone will stay out of your way. I like to make my own decisions where I am responsible for the results. Don’t tell me what to do and then blame me for the results. Let me do what I do and if it doesn’t work then you can fire me. I’d probably resign before that happens anyways. I knew that I would deliver results. I didn’t know if they’d be enough. However, this environment was well suited for me to operate within. I would be given a lot of authority and leeway to deliver results my way.
It’s easy to make major changes in situations like Match was in. In fact, it’s expected.
It’s easier to get funding. Nobody wants to be the reason why you didn’t get the resources that you said you needed to turn things around.
The best time to buy a stock in a great company is when it’s low. Well, I believed Match would be a great company and it was certainly at an all-time low. In a way, I was investing in Match. I was investing my time and my reputation. I also received stock in the parent company so I would be a true owner (and benefit) if I delivered.

I had been working on delivering PC programs to client desktops just prior to Match. Managing program installs across thousands of client desktops was a complete nightmare. I had worked on centralized mainframe solutions with central code and emulator front ends in my past. This “centralization” model was far superior from a management and delivery perspective. However, the client experience was far inferior. Emulators were basically all text, no graphics. There were a couple of graphical “screen scrapers” for emulators but these were not very good. Then, along came the internet and I knew it could be a game changer. It had the best of both worlds. Centralized deployment with a nice graphical front end handled inside the browser. And, even though the stock market was tanking, I still believed that this was going to be a winning architecture. Match would give me the chance to learn more at one of the highest volume internet companies in the world. The opportunity for learning was a critical driver for me.
Ticketmaster was a household name. Match wasn’t. It was common for internet companies to raise money/IPO back in the late 1990s. Ticketmaster Online-CitySearch (TMCS) went public in late 1998 raising $100 million, soaring on its NASDAQ debut, with many investors believing more in CitySearch’s promise at the time. TMCS contained only the “online” portion of Ticketmaster. The phone and outlet distribution-based company (the vast majority of how tickets were sold) remained separate. Selling online wasn’t proven back then. Sounds crazy today but it’s true. Still, even though TMCS was separate, the Ticketmaster brand and model carried significant weight with me. I felt this company was solid compared to the other high-flying internet companies that were crashing and burning around me.
I wanted to work with John, Dan, Sean and Cindy. I wanted to work under the USA Networks umbrella of companies. They were acquiring major companies like crazy. All filled with top internet talent. As I mentioned, TMCS was controlled by USA Networks who was controlled by Barry Diller. I wanted to work for Barry as well. Barry would give me the most unbelievable opportunity to join Match back in 2000. Over the years, I was fortunate enough to meet with him many times. I will forever be grateful for the opportunity to work for him. It was very challenging but I learned a lot from him. Victor Kaufman was USA Network’s Vice Chairman at the time and was another executive that I was excited to work for. Over the years, I got to work closely with Victor and learn directly from him as well. We ended up developing a good relationship and he took the time to mentor me when he thought I needed it. I’ll forever appreciate the time that he spent with me and I won’t forget the lessons that I learned from him. Back in 2000, I knew in my gut that the chance to work with these people was an opportunity of a lifetime. And, now, I know that I was right.

Following my Dallas trip, I accepted the CTO position offer by early November, 2000. I worked out an arrangement with TMCS management where I would start immediately and commute from Virginia. The plan was that after a few months, my wife and I would move to Dallas full time. However, I started right away on preparation for what I knew was coming.

For my very first meeting with my direct reports, I developed the following strategy agenda:

Discussion Points

1) Focus on making the current site better (shorter-term, tactical improvements)
– Fast (satisfies key aspect of the business drivers)
– Significant upside (less than given credit for)
– No focus on a complete re-design
– Prove value of our capabilities

2) Building credibility
– Management of expectations
– Set dates and functionality and then deliver
– Top priority
– Get business people to believe we don’t need a whole-sale change to make significant improvements in functionality
– Start with release 3.2
– Important to deliver and provide new features but really focus on re-formatting information that we already have today and “easy to add” features to ensure delivery.
– Taking credit for what you do every day (sometime taken for granted)

3) Preparation for increased volume Database/Applications/Operations)
– Identification of areas that are likely to become “scalability issues”
– Recommendations on areas of improvement within the current database design
– Measurement ability
– Higher visibility
– Information written up and sent to me
– Reasonable time frame

4) Release management (more than just 3.2. Likely to be 3.3, 3.4, etc.)
– Specs
– Source code management
– Is it all documented?
– Do we need to get external help to come in and provide help?

5) Project plans
– Do we currently do them?
– Weekly meetings to discuss (Tuesday, 10 am?)

6) What other things do we need to address immediately?
– Database consolidation
– Getting more help

7) Documentation of current operations
– Does it exist?

I asked TMCS for 60-90 days so I could perform a detailed assessment. After this “assessment period”, I would come back to them with recommendations. Patience in these types of situations wears thin. So, even though I had the expected 60-90 days, I needed to get things accomplished much, much sooner. Nobody was going to wait 90 days to take further actions if the downward spiral continued. Even before I started, there were proponents at TMCS for moving the Match business out of Dallas and back to LA where TMCS was located. Sean and John had discussed this with me on my interview visit. Since I was living in DC, I was open to either Dallas or LA as the location where the business ultimately ended up. Personally, I would have preferred LA. So, if I started in Dallas and we moved to LA, great. If not, staying in Dallas was fine too. I didn’t have roots in either place. I was moving so the location really didn’t matter to me. However, I really wanted to determine what would make the most sense from a business perspective. I wanted it to be my decision and not one that was forced on me, triggered by inaction or by just being in “assessment mode” while the technology and business continued to flounder. So, going in, I planned two parallel tracks.

Inject short term stability into the system and keep the existing team focused on efforts in this regard. Basically, stop the downward spiral. Avoid more self-inflicted wounds that would further erode confidence in the group and their capabilities. Instead, make some smart changes to the product and technology to show progress and build back some confidence (i.e. get some wins under our belts, even if small). Keep the team as occupied as possible on these priorities so they aren’t preoccupied with #2.
Assess the team, the technology and procedures in place. Build a set of recommendations and develop a long-term plan for moving forward.

Unfortunately, getting easy wins at the time wasn’t easy. Nothing was. On the day after I arrived, the team launched new code to the website and the entire site went down – no users could access it. I was told that the code had to stabilize so just wait. And, it did stabilize. The site stayed down – not the stabilization that you want. I told the team to roll back the changes. Unfortunately, there were no formal roll back procedures. The developers had to manually hack their way back to site availability (I forced them to pre-plan something for this launch and I’ll describe more about this later). It was an early indication that my job was going to be a lot harder than I imagined even though I expected it to be bad.

During November and December, I talked to every one of my employees many times. I held “all-hands” team meetings where my team could ask me questions. I set up sessions where we reviewed everything we did: development, testing, database, systems, mail, network, etc., etc. I asked a lot of questions. I also held one-on-one sessions. I started happy hours after work where the team could go and have a couple of drinks, play billiards and talk to each other and me, in a more informal setting.

I started bringing in external companies in the Dallas area to talk with them and get their views. I contacted resources that I knew in Dallas to help me with recruiting. My mindset going in was to make dramatic changes. I just needed a little time to figure out exactly what those changes should be. And, time to figure out what options were available to me in Dallas.

As I’ve stated, I really wasn’t expecting what I found. It was a lot worse than I thought it would be in many areas.

There was zero documentation in place.
There were no good job specs or recruiting procedures in place.
Minimal project planning was happening.
There were no formal development procedures.
a. No formal spec or release management.
b. No integrated development environment.
c. No formal testing environment.
d. No QA/testing team.
e. No analytics or measurements.
f. No rollback procedures.
g. Developers pushed code right to production from their own machines or hacked the production code in place.
The production site was housed in a back room at the office on bread racks under live sprinkler heads.
There were no formal operations procedures in place.
a. No operations hotline.
b. No on-call schedule.
c. No escalation procedures.
d. No partner notification procedures.
There were no formal hardware upgrade plans or patching procedures in place.
There was no standardization for hardware used.
Team infighting was rampant and cliques had formed.
CYA and a blame game mentality made it hard for me to determine the facts and what people really thought.

At the beginning, it was clear that nobody in the technology organization wanted me there. They were aligned with the previous CTO who was still there. I felt like I had parachuted behind enemy lines. Like a coach who gets a job for a team that doesn’t want to play for him. Of course, this is never blatantly stated by the players. People usually say the right things in public. However, there are a lot of ways players can fight leadership changes. Don’t work as hard. Drag your feet. Don’t cooperate as much as you can. Don’t support the coach’s direction with other players when coaches aren’t around. Openly question or associate problems to coaching with upper management. Keep management in the dark. Look for problems and highlight them instead of looking for solutions. In a business context, all of this happened with me early on before I made changes. Essentially, I was fighting my own team. We had major issues happening, like the site going down continually, and nobody on my team would communicate with me.

From: Mike Presz
Subject: Contact me when site goes down
Date: Thursday, December 28, 2000 3:26:46 PM

Guys,
Again. Please notify me whenever our site goes down for any reason that impacts our availability.

We went down last night and again today around noon. I won’t repeat this again.

-Mike

There seemed to be a prevailing mentality of: “If we all stick together then he’ll have to fire all of us and he can’t do that”.

During this period, I was constantly reminded of the challenges at hand. It seemed to occur on a daily basis. Here are a few of the major events and findings to give you some additional context as to what Match was facing.

All of the user data for the system went to a single 8 CPU box called DB1. This was the machine that housed the database where all new registrations, billing, and all other updated data was stored. Read only searches were handled through replication to other machines. However, no box was more important to the site functioning than DB1. If it went down, Match was down. Completely down. Well, I was informed that DB1 had only 7 operational CPUs. Given that we were looking for ways to scale, I asked why the team hadn’t replaced the bad CPU. The answer: there was no confidence that if the machine was rebooted that it would come back up successfully. It hadn’t been re-booted in months. This meant the entire site was at risk if the machine rebooted. I didn’t sleep well for days until we figured out a plan to test this and make sure we performed regular maintenance going forward.
While I was informed that DB1 was not used in searching, further analysis uncovered this was incorrect. Turned out that DB1 was hard coded as the default database connection for some searching requests. The meant that additional load was causing excessive I/O and site issues where it shouldn’t be. Nobody knew this until the site was impacted and we were forced to look deeper.
On Christmas evening, I received a call that the site was completely down. I was in Virginia because I was still commuting. I asked why they hadn’t reached out to the head of systems. I was told that he was in jail as part of a retreat and completely unreachable (more on this later). I still have no idea if this was literally true. He was unreachable, that I do know. He didn’t do anything wrong from a personal view – he was on a retreat. People have their own personal lives but “being in jail” surprised me at first because I thought he was in trouble. I never heard of such a thing. And, I didn’t really care because all I wanted to do at the time was figure out why the site was down and fix it. Obviously, he couldn’t help. That wasn’t good – not being reachable when you are in charge of a system that is constantly going down is not a smart move. At least have a backup plan and resource coverage in place to cover your absence. Maybe notify your new boss (me) that you will be unreachable? The site was down for hours until the problem was eventually found. There was a hard-coded limit on the registration counter. When this limit was reached, no new users were accepted, errors were returned, the site backed up and crashed. And, it stayed down the entire time until the hardcoded limit was removed. Why it was there, why nobody knew it was there and why it took so long to find are all great questions spanning multiple groups. For me, the entire debacle just highlighted the lack of professional development procedures in place at the time. Unfortunately, it was a painful lesson with real business and customer impacts. After it was found, even though I had these concerns, I sent out an email thanking everyone who worked on Christmas to find and fix the issue. My boss was upset with my note and I understand why. The problem should have never happened in the first place. However, I think my team appreciated someone sticking up for them, in some small way. Some of them were literally working 24×7 and still were getting beat up from every direction. For the ones that were reachable on Christmas, I saw some fight in them that night.
I called the city of Richardson and asked about the sprinkler heads above all of our machines in the “computer room” at the office. I say “computer room” because it was basically a room in the back with desktop computers on bread racks. It was nothing like a data center. It would be comical, really, except this computer room housed match.com. If a problem happened in that room then the site would be down, possibly for a long time. The Richardson civil engineer that I spoke with confirmed that all of the sprinkler heads in the room were live. This meant that water was above all the machines and if a fire happened, everything was going to be wet. We had no back up facility. We had no extra machines to replicate the site. And, we had no alerting system other than a screeching fire alarm that would probably signal weeks, if not months, of outage for Match. What was worse, when I was discussing this with the city engineer, he told me that the risk wasn’t just fire. If one of the heads malfunctioned or somebody hit one of those heads, the water would come a’gushin out. I just couldn’t believe my ears and kept asking him questions. He was spouting his PSI numbers and other technical water/pressure phrases but all I can remember is his Texas drawl and that water would come a’gushin out. I asked him to write all of this up on official city letterhead and mail it to me. And, he did. I should have framed that letter after I used it to help secure moving our site out of the back room and into a real data center.
The team had planned a release that had been started prior to my arrival. We were about a week before launch day when I set up a “go/no” meeting to discuss status. I had good launch templates from my experience in large enterprise developments so I modified the procedures for the internet environment. One of the items on my checklist was customer care. I asked the customer care manager if we were ready with the care tool to support the new website functionality being launched. He said that he didn’t know. He told me that one of his developers was working on it. So, I asked him to go ask the developer on the spot and find out. He responded that he couldn’t because the developer wasn’t talking to him. I’ll talk more about this situation later but it was wild. Here is a manager of a key component of our site and he has no idea if his part is ready. Worse, the lead developer won’t talk to him. You can’t make this up. Nobody would believe you.

None of this was funny to me then. However, through all of this, the customers kept coming. And, coming. In addition, I was making some progress with some key team members. While things were tough, many of the employees had real skills. They were just young and inexperienced. Yet, I could see potential and I also could see many were probably willing to give a new direction a try after spending more time with me. They were tired of losing. Meanwhile, in parallel, the move to LA was picking up steam both in Dallas and LA. The project was called “Project Spike”.

From: Dan M
Subject: Project Spike Reminder – 8 A.M. – 10 A.M. PST CALL TOMORROW
Date: Wednesday, December 20, 2000 4:09:00 PM
Importance: High
Sensitivity: Confidential

Team-
This is a reminder that we’ll be further attacking Project Spike tomorrow in a two hour video conference. For those of you in Pasadena, we’ll be in the Board Room. To set expectations for the call, we’ll start by reviewing the information that Ken and John have been gathering from each of you and end with agreeing to the next set of iterations needed to move to a recommendation phase. Without elaborating, if we have no information in hand for the discussion, there is no discussion. To further reinforce pace on this, we desire to get to the all the information with pros/cons and a
team discussion presentation ready for John P. / Tom M. by the first week of January (read: final, polished and all key questions/issues addressed). We’ll then quickly turn a recommendation to USAi.

12/20 – Video Call
12/28 – F/U Video Call (9-11 a.m. PST)
Week of 1/3 – Presentation to JP/Tom/Others

Just to reinforce – this is a HIGHLY CONFIDENTIAL project that requires full discretion from everyone.

Thanks and see you there,
Dan

Executive Vice President, Corporate Strategy and Development
Ticketmaster Online – CitySearch, Inc.

At this point, I had been on the job for just over 30 days and the move to LA train was already rolling. Given what I had found thus far in Dallas, I was certainly more “on” the LA train than “off” it at the beginning. None of my employees knew formally about a possible move to LA but they were all smart enough to suspect that it was being discussed. Given all the problems, how could it NOT be?

TMCS was looking to make a recommendation in early January of 2001. I was gathering as much data and understanding as I could. I wanted to be sure to make an educated decision and not a rash one. Sure, I had problems in Dallas but they were known problems at this stage. I needed to figure out what my options were in LA. I’m a very practical guy. I don’t place a lot of stock in “hope”. I need executable options. Sure, the options can be hard. They can take time. That’s all fine. However, for me, options have to be real or I need to believe that I can make them real. I talked with Sean about the resources that were available for me in LA already within the company. Effectively, there were none although Sean committed to help find and hire them. In theory, we could hire a team in LA and train the new team on the existing system. We’d keep some of the existing team from Dallas permanently (if they’d move) or temporarily to help transition. Best case, that would take a lot of time with a low probability of success. The people that we wanted to keep from Dallas were unlikely to move. So, directionally, we’d have to find a whole new team with appropriate skills, train them on a system they didn’t build, and offer almost no support from the Dallas team that built the system because they’d likely be long gone. I didn’t have time. I hated the risk. The patient was on the operating table and needed an immediate operation. Any delay or, worse, transporting the patient in this condition, was likely fatal. I didn’t want to rely on a doctor that I wasn’t even sure existed. In fact, a doctor who most likely wouldn’t materialize, certainly not in time to save the patient. As much as the current situation in Dallas troubled me, I had talked to enough of the employees and seen enough of the technology system to know that the ONLY chance of success was to keep things in Dallas. I communicated this clearly to TMCS management. I didn’t sugar coat anything. I reiterated that the situation in Dallas was dire but I gave them enough hope that I was going to change things dramatically. In Dallas, I had an executable plan. I had a core team. I knew what needed to be done. I wouldn’t have to waste time in a transition. Yes, I didn’t like all of the problems but I was committed to fixing everything. Most of TMCS management knew that a move to LA would be costly and very high risk. It was a long shot. For them, it would also impact their other businesses. It would be a distraction at best and a disaster at worst. And, they would own part of the responsibility. In Dallas, it was all on me. Sure, they would help with financial support and expertise as needed but they were not helping me with the team and day-to-day execution. They had their own businesses to run. Businesses, I may add, that were more important to the company than Match was at the time. So, sitting in LA, I’m sure that they felt they had no other choice than to go with my recommendation for a variety of reasons, regardless of their concerns. I had provided a recommendation for continuing in Dallas and “assumed” all responsibility to execute the plan. “Assuming” responsibility is a funny term. When you are in a leadership role, the responsibility is yours regardless. So, you might as well just go right out and take it because it’s yours anyways. Accepting it builds confidence in those around you. If you are willing to take responsibility it sends a clear message about your confidence in the plan. You don’t have to use words like “I assume responsibility” but rather an attitude/words that convey “I’ll do it”, “It’s on me”, “I will make it happen”, etc. Even better, use the word “We”. “We’ll do it”, “It’s on us”, “We will make it happen”, etc., and make it clear to your team that you believe in them, regardless of whether you have concerns. It’s your job to make everyone better. You’ll be surprised in what people can do when they are motivated. Then, take action.

So, after the January meeting, finally, we had set an agreed-to direction. I immediately started making major changes. The changes happened in four major buckets:

1. Systems changes
2. People changes
3. Procedure changes
4. Product changes

On the systems side, I proposed moving Match to a professionally hosted and managed environment. Essentially, these datacenters, support systems and personnel were like early cloud computing platforms are now. However, they were not in style or favor. They weren’t nearly as robust either. However, I felt that this was the best choice for Match given where we were. We had a large deal with MSN but site issues put the deal at risk. Furthermore, we were in negotiations with America Online to host Love@AOL. Given that context, here is the proposed plan document that I sent out at the time:

Background

The decision to move the Match.com web site from the Match.com back room to a professionally hosted environment, will improve the reliability and availability of the site. Currently, there are a number of single points of failure that could seriously jeopardize the site. These include:
• Single Source of Power.
• Single provider of Internet bandwidth.
• Single Core network systems (Router, Main network Switch – Have 1 spare router and one spare Network Switch available)
• Single Network entry from Main Network Switch.
• Single Network Switch.
• Single Load Balancing switch.
• Single Database for write operations (matchdb1).
• Single server for Replication to read-only Database servers.
• Single File server for matching cache.(matchf1)

In addition to these single points of failure, the following issues present additional concerns:
• Sprinkler systems above the machines could turn on
• Non rack mount computers on bread racks leaves computers open
• Non labeled wiring and cords could be unplugged, trip over, etc.
• Lack of detailed expertise in various hardware systems on staff

We have already experienced significant outages due to the current configuration and have been put on notice by Microsoft for our MSN contract. Even with these outages, we have been extremely lucky that the impacts have not been far, far worse. There is a very high risk that a major problem could hit leaving the site out for days.

MSN Contract
MSN Deal. Microsoft has put us on notice that our contract clause has been violated. We must be up 99.5% of the time. Starting Feb 26, Microsoft can charge us significant penalties per 30 day period where we fail to meet this requirement. After 4 incidents, they can cancel the contract. This represents a worst case scenario if we get failures in each of the 30 day periods starting after our 2/26/01 response period.

AOL Contract
We can’t support the AOL requirements as stated in their technical standards document. We would be immediately be in violation of the “fully redundant” clause and the 70% line utilization clause.

Moving to a professionally hosted and managed environment was going to cost about $1.2 million per year back then. It was a lot of money for Match at the time (especially given questions around the business). There were some off-setting capital expenditures and headcount costs but this still represented a major move with significant additional cost. In addition, the news of the move was a big blow to my internal systems staff. They viewed it as a knock on their abilities and the first step in eliminating all of them. From my perspective, their first concern was somewhat true but the second wasn’t. And, honestly, I didn’t really care that much because I knew it was the right thing to do. I was confident that I could convince them of this. My primary focus was to secure the environment and my second concern was bringing in experts to help train my team, not get rid of them. I really had no choice. However, while everything made sense to me, I still needed approval from TMCS management. And, that meant getting our CFO’s approval. So, we had a call with our CFO and I presented my case. Our CFO was one of the resources that I respected most. He didn’t want to spend money for the sake of spending money. He challenged theory and didn’t like unproven techniques. He asked about alternatives. He made damn well sure that you were standing behind your proposal as a matter of principle and substance before you’d ever get his approval. In many ways, he thought a lot like me. So, the meeting was challenging but not unexpected. He asked why we needed to move out. He asked why there weren’t cheaper alternatives, citing a reference to a popsicle stick and glue approach. What about hiring someone to sit in the room and watch things? This was his style – pinching pennies while making millions (and eventually billions). No matter what the revenue or success level, he didn’t want careless spending. He also didn’t want carefree thinking. And, given the dire situation at Match, it was even worse. Back then, TMCS was worried that the Match acquisition was a mistake. So, his questions were dead serious in intent. And, I was dead serious about moving out of that back room. No chance Match sits where it is today had we not received approval after that meeting. Luckily, we did. So, I started moving in that direction immediately, in February of 2001.

By the end of February, I had most of the people changes done as well. This was a very difficult time for me and the company. I let go at over half of my team. There were various reasons for the changes but a lot was due to fit – skill fit as well as team fit. On announcement day, I arranged meetings late in the afternoon and scheduled two meetings. In one conference room were the people that were staying and the other were the people that were leaving. I talked to the group that was staying first and then sent them home. I then talked to the group that was leaving and told them the news. I explained that everyone else in the group was gone home and that they could retrieve their belongings from their desks in peace. There would be no walk of shame in front of their peers and no disrespect at getting locked out of the office unexpectedly. I was telling them now. It wasn’t easy. They didn’t like it. However, I think they respected how it was done. I even wrote a couple of recommendations for employees that asked and I knew had talent. They just weren’t a fit for us moving forward.

The following day, the remaining employees returned to work. Now that the big changes were over, I was transparent with them. Here is what I communicated at a high level:

1. That I had been in communication with TMCS management about moving Match to LA. That process was now over. I decided that this was not the best way to proceed. I had enough confidence in the people in the room to deliver a new system from Dallas. Obviously, it won’t be easy but I’m placing my bets on this team.
2. I had no plans for more organizational reductions in the near term assuming we do what is expected. As far as I was concerned, this was the core team that was moving forward.
3. I was going to bring in additional help for the team. So, we need to find new talent that would fit with our new direction and culture. They should tap their contact sources for anyone they knew.
4. We were going to deliver a new system and I needed everyone to help me set a date for when this would happen and then deliver as promised. I would help however they needed me to. New equipment? Training? Tell me. I can’t promise that I’ll get it all approved but I would definitely fight for it.

Translation: I was going to live or die with the Dallas team. I had faith and confidence in the remaining core group. We needed to supplement this talent. We needed to implement better procedures. In fact, we needed to improve a lot of things but everyone was on board. I could feel the culture changing. The negative attitudes seemed to be diminishing. Everyone was cautiously excited.

The procedural changes were fairly easy. We hired a quality assurance (QA) manager for testing and she built out a separate team. We implemented good development and testing procedures, bug tracking and release management. I had been doing this for enterprise businesses before Match so I had a lot of experience here. I brought in some people that worked for me at other companies and this got established quickly.

On the product side, we spent countless hours on developing a plan for a new Match system. As mentioned, the existing product needed work. We set a date of June 4th, 2001 and everyone agreed that we could deliver by then. This new system would be called Match 4.0. It was an aggressive date. It was an aggressive new feature set. However, we needed it. Microsoft could leave our deal if current systems problems persisted. AOL was on the horizon. Back then, this represented the bulk of our business. No way that our current system would handle both MSN and AOL. Everyone knew it. It was do or die. There would be no second chance at this. Not for me. Not for them. Fail and this thing was likely moving back to LA with whatever was left. Without us. Certainly, without me. I had made the case to keep it in Dallas. It was my plan. It was my team. And, that’s exactly the way that I wanted it.

The product team got to work on the new product specs. New hires were coming in. Better procedures were now in place. We had approval to move to a professionally hosted facility. Still, besides the difficulty of large-scale execution on a tight timeline, we had two other major challenges. We didn’t have a development environment or a testing environment. I decided that the testing environment would be solved by using the new production environment as the testing environment for this launch. Longer term, we’d need a separate testing environment since production would already be used. However, since we were moving to a new facility for Match 4.0, we simply got the production environment ready early so we could test in it. It was not “live” until we switched over our traffic to the new facility. That left the development as the only real pressing need, especially since it was needed immediately. Our hosting company had a test lab and they had pitched it to me for performance testing. I went to them and said that I wanted to rent their lab and use it as our development center. And, we did. In parallel, we started to build our own development environment but there was a lot of lead time in those days on ordering machines, racking them, getting the network infrastructure, etc. There were no “on demand” clouds like Microsoft Azure or AWS or GCP (Google Cloud Platform). So, we used an external performance test lab as our development center.

The time period between February 2001 and June 4th 2001 was as intense as any other time at Match during my tenure. Match Group and Tinder are household names now. It seems inconceivable to think of a time where nobody had heard of online dating and Match was nothing more than a small start-up, fighting to survive. Yet, that time existed and we were dangerously close to it collapsing back in 2001. Literally, the entire future of the business was at stake. Whether this would have proved true had we failed, we’ll never truly know. However, I can tell you that we all thought this was true. With that said, we were not going to fail without a 24×7 fight.

The team was working 7 days a week. Day and night. Every Friday around 6 pm, I blasted the song “Eye of the Tiger” through the entire office, symbolizing another week of intense focus and getting everyone pumped up even more. It became our theme song for the launch.

During this time, I spent much of my time focused on employee morale. My job was to ensure that our employees had the tools that they needed to be successful. That we were staffed right. That we had the right talent. That our plan was good. And, most importantly, that I believed in them. They knew that I chose to stay with the team in Dallas. The company was spending significant money on new hires. We invested in a new hosting facility. I was spending day and night with them working. I could see progress. I could see our mentality changing. I sent out the following message in early May:

Team,

I am very happy about the progress on Match 4.0 and our current status. This progress is due to all of your hard work, dedication and skills. With that said, I want us to continue with our killer instinct mentality. We should proceed as if this system is due TOMORROW and we are behind schedule. We should think this way every day from now until June 4. We should never underestimate the problems yet to surface, the unknown issues still lurking and the reality of fix cycles, testing and implementation. Now is the time to press and put this thing away. So, I want to thank everyone for the outstanding Match 4.0 efforts to date and challenge everyone to do whatever it takes each day to exceed our plans and prove what I already know: We will deliver this system and position this company with a platform fully ready to handle AOL and other future objectives.

-Mike

Shortly after this note, I had launch shirts made for everyone on the team. I had spent enough time with everyone to learn more about them. So, I personalized every shirt with my own nickname for each team member and an appropriate comment. Here is the list from back then:

Mr Yello Light – Need his conservative approach – File Server, Forms, Etc.
Pipe Filler – Always needs to reduce bandwidth because of it
Baldy
Prop King – Needs no explanation
Balancer Boy – F5 Work
Photo Finder – So many lost care photos
Debabblizer – Symbol of how many times a photo goes through
Move Master – More to come
Exchange Queen – Is the debug folder full?
Beat Reporter – So tired of all this reporting
Data Cleaner – Replication too
Sniffer – Panther broadcasts?
Plan Man – Nothing he can’t chart out
Schematic Fanatic – Nobody touches his logical design
Venus Femail – Matches for everyone
Copycat – For cranking out 4.0 pages without diagrams
Bugzilla Killa – Squashes bugs without mercy
Eye Doctor – For work on the double blind
Stress Maker – And I’m not talking about load testing software
Scene Maker – Soon to be changed again
Mr 0115 – Can take a site down
Message Queen – Nobody sends more emails
Lonely Tester – Never seen a smaller testing department
Impression Maker – Tracking is his middle name
Care Taker – Luckily, we grabbed him from customer care
Care Maker – Do the words scripting engine mean anything?
Picture Mover – Match needs a strong back for these numbers
Problem Maker – In a nice way – logging errors to be fixed
Byte Counter – Never enough disk space for this guy
Schema Dreama – Then, try and change his mind!!
Mr Visio – Wizard on the keyboard
Redo King – Can you change the image again?
The Critic – Reviews code with the best of them
Access Giver – Especially if you need some data
Ms. Project – or is that “M” “S” Project
Quality Queen – Zero tolerance
Spec Goddess – Can’t touch her binder
Hyper Typer – Glad to have her on board

I didn’t include the names for each person in this book for obvious reasons but everyone on the team was on the list. Nobody was left off. I’m Baldy (the empty space with no explanation in the list). You’d obviously know why if you met me or seen my picture. I hope the rest of these people are reading my book. They’ll remember. I’ll never forget any of them. Match owes a debt of gratitude to every single one of them. I do too. I instructed them to wear the shirts on launch day even though, in hindsight, I didn’t really have to.

From: Mike Presz
Sent: Wednesday, May 09, 2001 4:36 PM
To: Developer Team; MIS Team;
Subject: Shirts Must be Worn on Launch Day

I forgot to mention that these shirts must be worn on launch date. Other than that, it is up to you when you want to wear them.

-Mike

June 4th came a lot quicker than any of us wanted. Everything appeared to be ready but you always wish that you have more time when the day finally comes. Still, you know that it’s game day so it’s time to take the field. Our new production facility was ready at full scale. We had new procedures in place that gave us confidence that the product was ready for live production traffic. Well, it was as ready as it could be given that there is no test like live production traffic. You can’t simulate it at Match’s scale, even back then. Still, we had tested the new product as much as we could in the production environment for months. You can only prepare so much. It was time to start the game. This meant redirecting www.match.com to our new production facility that contained the new code base.

The planned launch time was 1 am when user traffic was low. Everyone was in their launch shirts. We played “Eye of the Tiger” one final time around 12:30 am, 30 minutes before launch. Everyone was ready. We were just waiting for game time, 1 am, June 4th, 2001. During this waiting period, I remember getting a call from our CFO right before launch. He had one simple question: Is this going to work? I replied “Yes”. And, basically, that was the extent of the call. Knowing him, he probably gave me some words of support but I can’t remember anything else. I was too focused on the task at hand.

While the call was unexpected, I totally understood our CFO’s position and the need to call. He was responsible too. Not as directly as I was but still responsible. And, knowing our CFO, I’m sure he felt very responsible. Yet, he had no control over the situation. That’s a tough place to be. Your pitcher needs to throw a strike and win the World Series but it’s him, not you, who has to make it happen. This wasn’t the World Series but it sure felt like it. And, now, with a $30+ billion market cap on the company, the comparison sure looks more reasonable. Fortunately, I dealt with pressure all the time with my history and experiences in sports. I was the pitcher. And, on June 4th, 2001, the Match.com ball was in my hands (with my team behind me) and that is where I wanted it.

At 1 am, June 4th, 2001, we launched Match 4.0 as planned and then all hell broke loose. This isn’t all that unusual for major launches but this was a unique situation. It was the first launch of this magnitude for Match, and me, with such intense pressure riding on it. That night/morning, we fought problems for hours, fixing problems as we identified the cause. By 5 am, we still had a lot of little problems but one major problem was threatening the entire launch. Our CPU was pegged at near 100% and it was still early in the day. As more people got on the system during the day (our peak was 8-10 pm CST), the system wouldn’t be able to handle it and could crash. My head operations guy said that we may have to consider a roll-back if we didn’t find the issue soon.

Everyone was trying to figure out the cause of the major problem. Theories were rampant. Most of these theories were like conspiracy theories: far more complex and far less probable than common causes. Maybe it’s in the OS kernel. Maybe it’s this obscure condition with the hardware. My experience is that this is rarely the case. It’s usually something simple and/or self-inflicted. So, I started to go through the new features that I thought could be resource intensive. I asked about the “new spell checker” that we implemented. I never liked the idea for initial launch. I don’t like unproven or untested solutions being launched wholesale especially if they are resource intensive or could have negative consumer or revenue implications. Sometimes, we’d have no choice but to launch them in this fashion, especially back then when we didn’t have a mature testing infrastructure in place. However, this wasn’t the case with the spell checker. It was a nice to have as far as I was concerned and not a core requirement of the launch. The product folks wanted it as part of the launch so I was OK with it in that context. We actually built it in a way that it could be turned off on-request just in case it caused problems. Given our situation after launch, I wanted to see what would happen if we turned it off. So, we did. Immediately, the CPU usage dropped dramatically. That was it. There’d be no rollback, no failed launch, and no call back to TMCS management with bad news. The answer to our CFO’s question was now right: Yes, this is going to work.

Immediately after launch, the business results jumped. While we still had issues, we knew they could be fixed. We knew that things were only going to get better with time. We also knew that we had a platform that would serve us well for years to come. In the moment, it’s all about short term goals. I wasn’t thinking about the launch in terms of Match’s legacy. I wasn’t thinking about the culture that was developing that would be a foundation for years and years to come. I wasn’t thinking about all the reasons why this launch was successful. I wasn’t thinking about the improbability of it all. Nope. I was just happy that the launch was done and working. The business was growing. The platform was more stable. My employees were happy. They earned it. I’m sure, deep down, they were hurt that I was thinking about moving the platform to LA. They had something to prove. It’s like winning a big game in sports. You prepare like crazy. You hear the noise along the way but need to tune it out. You hope that you get that chance to show what you can do. If you get that chance, when you step on the mound like I did many times, you have to make the most of it.

By late November, 2001, we had stabilized the platform, launched new upgrades, saved the Microsoft deal, and launched a new AOL site. The business was setting huge new records. The team was doing great. We had confidence about our future and the future of the business. And, everyone had confidence in us.

From: Mike Presz
Subject: 4000 Subs and AOL launch
Date: Monday, November 26, 2001 12:11:00 AM

Team,
Congratulations on another successful launch – the final phase of AOL is now complete. This makes 3 successful, major launches in 2001 – Match 4.0, AOL web properties and AOL Rainman. Tonight, we hit 4000 subs in a day – the first time ever at Match. You should all be very proud of your accomplishments and there should be no question of the impact that each of you have on this business.

Now, it almost seems routine but I caution everyone to keep perspective. We live and work in a challenging business environment. While it may appear easy on the surface, we all know how difficult it is under the hood. So, I continue to ask everyone to remember this and not to take anything, anything for granted. We have many more objectives to meet and many more hurdles to overcome. It won’t be easy and luck isn’t anything that I believe in. It will continue to require hard work, dedication, and expertise to ensure that we deliver advanced searching/matching, IM, a disaster site, and the other major projects on the calendar. It should be an exciting ride and I’m looking forward to it with your help.

-Mike

I now have time to reflect back on that launch. The 4000 new subscription number is a small number in today’s context. However, it was huge back then. The specific number isn’t important now. What’s important is how success was achieved. With the exception of Tinder, there is arguably no more important non-acquisition event in Match’s history than the launch of Match 4.0. And, that is saying a lot because Match has had a lot of important launches and other events. This launched saved the company. Literally, six months prior to launch, we had considered moving the company to LA. I considered whether it was worth letting all of the Dallas technical employees go in that situation. Many of TMCS’s management believed that my decision to stay in Dallas would be a mistake. They had good justification for these beliefs. I didn’t fault them then or now for holding this position. Yet, In June of 2001, a bunch of young men and women, most of whom had been written off for dead, changed the course of Match.com and online dating history.

Twenty+ years later, Match 4.0 seems more improbable and more important today than it did back then given what has followed. To entertain the idea that Match’s potential may never have been realized is scary. Look at the t-shirt list again. It has 38 names on it. Just 38 people helped ensure that Match.com would be forever remembered in the history of our culture. These people helped set the stage for millions, billions, of interactions, relationships, and marriages. How many children are walking the earth in part because of their efforts? Literally, these people changed the world. I really hope they understand the magnitude of their contribution. There are many, many more people at Match both then and since then that have made major contributions. My point here is not to compare them but to illustrate how important your contribution can be. Whether you realize it in the moment or years later, there is a fine line between success and failure. So, when the moment comes, seize it.

There were mistakes that I made leading up to the launch and during this period that I didn’t mention. Not everything that I did helped build a better culture, team and environment of success. Some things didn’t work. Some didn’t help. These mistakes seemed important at the time but don’t now. It was part of the process. I had to make game time decisions. So, I’d rather discuss what worked – the things that I believe helped build team chemistry and created an environment that enabled success. And to let you know not to be discouraged if something doesn’t work. Try something different. I have learned a lot since the early days of Match. However, like most good foundations, the principles that helped Match back then are as important and as relevant today as they were 20 years ago. So, I will give you my thoughts on the key lessons.

Give Everyone A Chance

During my first 60 days at Match, I spent a lot of time talking with everyone. I held private one-on-one sessions. We held team meetings. We also held after-work outings. Every single employee heard the same message.

Things are going to change
I need people who want to embrace the new direction
You need to decide whether you want to be part of it
I’d rather you be part of the new direction but you need to be all in

When times are crazy, it’s really hard to judge people from the outside. Mob mentality can take over. So, you have to be direct and firm. You need to communicate. No matter what happens, when you give everyone a chance and if they don’t take it, then ownership of the outcome is also on them. It’s easy to understand when talented people decide to embrace the new direction by choice and then help contribute. Typically, the stars are obvious. Your goal is to get them to embrace the new direction. However, you can’t just focus on the obvious. There are surprises too. There were people that I had assumed had little talent but over time proved me completely wrong. And, I’m very glad they did. These are people who had great attitudes, embraced the new direction, and worked like crazy. Maybe they were in the wrong roles prior. Maybe the old way wasn’t motivating them or utilizing their full capabilities. Most people think that making employee changes is easy. In the course of Match’s history, I’ve probably had to let more people go than many who have been in management. I will talk more about this later in the book. However, I will tell you that I try to avoid this if at all possible. Losing a job impacts the employee’s confidence, their career, their family, and their future. It’s a brutal decision to make. For me, deciding on budgets, project features, acquisitions, deals and everything else in the business is far easier than the choice to let people go. However, it’s not fair to the team or the business to have members that are not helping us win. What’s also not fair is not giving everyone the chance to try out. To show that they are capable and willing to help the team. If you are a manager, make sure that you give that chance. If you are a team member, make sure that you ask for it. Show up and try out. But, give the tryout your absolute best. You might surprise everyone, including yourself.

To this day, I think about the early employees that decided to jump ship, either by directly doing so or by fighting the new direction, intentionally or unintentionally. I hope they found direction and did well. However, they sure missed out on an unbelievable opportunity at Match. I want you to understand there was a very fine line between many who stayed and those that left. I could have made some mistakes, I’ll never know. I do know that I decided to keep some individuals at the last minute that turned out to be stars. The point here is that when you are given that chance, think very seriously if you are considering NOT taking it or NOT giving your all.

Remember The “Mirror Test”

What’s the mirror test? It’s my term and I use it to remind myself that every action on an employee is viewed by other employees in this way: it’s not me this time but it could be me the next time. This view is somewhat universal in that it applies to negative actions (attacks, admonishment, firing, etc.) and positive actions (praise, bonuses, raises, promotions, etc.). These actions could also apply to me. My superiors could choose to take similar actions towards me. It forces me to think about the following questions:

Do I understand the reasoning behind the action?
Do I think the action is fair?
Do I like the way the action was done?

For all important decisions regarding employees, I try to ensure that I’ve communicated my reasoning, that I believe I’m being fair and that I do things in the best possible way (i.e. if it were to happen to me, I’d understand). I know that it will never please everyone. Not everyone will agree. Not everyone will like how things were done. However, I still go through the exercise to prove it to myself, as best I can. I do care about these things. If you are in this position, you should too. So, I spent a lot of time communicating with the team before I made any decisions. I spent time listening and watching. I spent time researching options, both in Dallas and LA. I wanted to be sure that I considered everything and everyone. I also wanted to be sure that I didn’t sugar coat or hide anything. I informed the team afterwards about the LA decision. Sure, it was confidential while it had to be but I like transparency. So, as soon as I could, I talked to the team about any potential move. I let them ask questions. Nothing is off limits. Ask and I’ll give you my answer if I know it. I may not have all the answers but you can judge my sincerity yourself. I’m not going to tell you how you should judge me.

As I discussed in the previous section, everyone knew that they had a chance going forward, whether they believed me or not. They also knew that everyone else did too. It wasn’t as if I came in and just made dramatic changes without talking to people. Or, that I talked to some but not others. In these types of situations, team members understand who is embracing the new direction and who is fighting it. They understand who is helping and who isn’t. There really isn’t much mystery here. The hardest part of these types of situations is honoring your principles. So, you have to understand the following:

1. You can’t keep a star that is openly defying the new direction.
2. You can’t let someone go with lesser talent that is working like crazy and supporting the team. Find a place for them. There is always a job for people like this.

In the end, two of our top developers (including the development manager) were not part of the team going forward. I wished that they had supported the new direction and stayed. They didn’t. After the changes were made, I’m sure that some of the remaining employees were upset that they were gone. With that said, I also know that the remaining team members knew that these two developers were fighting the new direction. So, it was as much the choice of those individuals as it was mine. They had the opportunity to remain as much as anyone else. They just didn’t want to or care enough to show it for whatever reason. It’s simple for me. I don’t care if you are a star player. I don’t care how talented you are. If you don’t want to play here, on our team, I don’t want you here, regardless of your talent.

For some of those that remained, I found new positions. We didn’t have a testing team. So, some developers that weren’t fit to be developers but were working around the clock with great attitudes, I moved to the testing group. They were happy to embrace a new challenge, especially one that allowed them to be more successful in their new role. Most people understand when they are not a good fit for things. Don’t demean them for it, help them. Train them. Provide them with other opportunities. That’s what we did. A lesson here, though, is that if you are one of these people in a role that may not be a good fit, speak up. Don’t hide or be miserable in a role you aren’t a good fit for. It’ll be obvious to everyone else by your actions and words anyways. If you do not have the right attitude, aren’t working harder than everyone else, and/or don’t ask for help, you’ll never be considered for any new opportunity. You may even get washed out of the company and your true talents will never be known. So, it’s ok to be proactive and to say that you think you aren’t in the right role, offer an alternative, ask for additional training and/or propose alternatives. Talk to your manager. Do it in a positive, constructive way. And, if new positions become open in your company, apply for them.

I described the process earlier when the actual changes were made to the team. For those that were let go, we offered as much of a respectful process as we could. I didn’t want to embarrass them. I didn’t try to lock them out or have the guards escort them out. It’s a fine line here between risking damage to the business and respecting human beings that just lost their job. I think you can do both if you handle things in a respectful way. And, everyone that remained saw it. You need to remember that these people worked alongside those that were leaving. Many were friends. On a personal level, I’m sure they weren’t happy to see them go. Yet, those that remained understood that we could have done things in a much worse way.

Many of the employees that remained after the changes in 2001 remained with Match for years. Some are still there today. Over the years, I had a chance to talk with many of them about the early days. Here is what I took away from these discussions:

People believed that I was sincere in my efforts to make a positive change for the team and for the company. They could hear it in my voice. They could see it through my actions. They understood the reasons behind what I was doing. Whether they agreed with every little detail or would have done the exact same thing, it didn’t matter. It was my job to make the decisions and they understood the rationale and respected that I took action.
People felt that I cared about what I was doing. I didn’t make arbitrary decisions. I gave people a chance. I also didn’t play favorites. Doing what was right for the team and the company was the main consideration.
I think most people appreciated how the actual day of the changes played out. They were allowed to go home while their colleagues and friends were told that they wouldn’t be part of the future direction for Match. Those remaining didn’t have to deal with that uncomfortable situation of watching the departure of those that were leaving. They went home and could have some time to deal with the emotions of it. I didn’t make it worse. I think they also appreciated that their colleagues were not treated as threats to the company and shown the door via guard escort or simply locked out of the company and told to “deal with HR”. They got to pack up their things with no-one else present in the office. I’m sure that it still stung. I’m sure that many disliked me and disagreed with me. But I dealt with all of this myself. If you are going to deal with tough situations, don’t pass the buck. Don’t do it from far away. Have the decency to look people in the eye and make the changes. The meeting where I told them all at the same time wasn’t easy. I thanked them. But, unfortunately, we were moving in a new direction and they were not going to be part of it. I told them that everyone else had left and that they could clean their desk and go home. It was a very short meeting.
I think everyone that stayed felt that they made the right decision. They did better, the team did better, the company did better and their family did better. Winning makes everything a lot better.

So, don’t ever forget that all employees are important, not the just the ones that are staying. How you treat them helps set the culture for your company. Remember the line from earlier: it’s not me this time but it could be me the next time. Make sure you spend the time to communicate. Try to get all of the data so your decisions are sound. Set expectations accordingly. Treat everyone with respect. Be confident in your actions armed with the knowledge that you’ve done everything that you can.

The good news is that the same principles apply to rewarding employees as well. It’s just a lot easier. Find ways to reward and promote good behavior. Communicate. Set expectations. Be fair. I did so immediately after the Match 4.0 launch had stabilized. I fought like crazy to get TMCS management support. I sent the following email to my boss, the Match CEO.

—–Original Message—–
From: Mike Presz
Sent: Friday, June 08, 2001 11:20 PM
To: Tim
Subject: Bonus Recommendation

Tim,
Here is my bonus recommendation. I’ll fall on the sword for this. A small price to pay for the huge effort given by my team and for the morale moving forward. This would be the ultimate symbol of how this company under our leadership is different than the past. I know that you will do everything possible to support this and get it approved and so will I.

Thanks.
-Mike

Over the past 2 decades, I’ve had many opportunities to reward contributions as well as challenging times where I had to restructure the team. On the positive side, I’ve explained Crop ‘Til You Drop and Shock and Awe. There were many others. The key to rewarding employees is to ensure that it’s well-earned and understood by everyone. You can’t play favorites with rewards either. And, you need meaningful rewards for meaningful contributions. Use the same mirror test.

Team Results Matter Most

At the end of a game there is a score posted on the scoreboard. That score is a team score not an individual score. You win or lose as a team. And, you must win if you expect to control your own destiny and keep your jobs. If you don’t, someone else will tell you what to do or simply replace you. And, that’s the way it should be. In fact, you should prefer it that way. You need to play the right way. You need to play hard. There are a million other things that you must do in order to win. But, at the end of the day, it’s the team score that matters most. In business, that score is the business results. That is the team score. It’s not whether you hit your development date, came up with a new product feature that everyone liked, got a partner deal closed, or many of the other tasks that happen every day. Yes, these are contributing factors but none of them ultimately matter if they don’t cause the business to win. And, the only way that the business wins, is if you are delivering value to your customers. So, make sure that everyone in your organization is focused on how their work delivers value to the customer and helps the business win. Match had many TVs around the office that were updated with business metrics in real time for all employees to see.

Once I decided to keep the team In Dallas, I made sure everyone understood the importance of launching the new product for the business. It would be a team effort. This wasn’t about individuals. It wasn’t about me. It wasn’t about any single employee. Win or lose, everyone would be responsible for and judged by the outcome. Furthermore, I emphasized that while we were staying in Dallas for now, decisions can change. We have to keep winning to expect to keep our jobs. If we like our jobs here, if we like what we are doing, if we want to keep controlling our own destiny, then we must continue to deliver. And, the only way that will happen is if we do it as a team.

The truth is that I would have preferred no people changes at all. If I knew that everyone was willing to accept the new direction, work hard, stay positive and put the team ahead of everything else, I would have been happy to find roles for everyone I could. We didn’t have a testing group, no analytics team, limited developers, etc. We talked about my view that everyone counts. Everyone can play a role. Everyone matters. However, everyone must be committed. They must be working as hard as they can for the team. In my experience, this can only happen when they fully support the direction and are all in. Unfortunately, this was just not the case with many of the employees when I first started. The rowing team can’t have everyone in the boat fighting each other and the boat captain instead of oaring in unison. The boat will not move or just spin in circles. So will business teams.

Avoid The Hail Mary

I’m going to let you in on a little secret: All ideas work on the whiteboard. No matter how improbable they may be, you can always show how they are going to work on the whiteboard. It’s easy to show and explain. It may even make sense. However, real-life isn’t a whiteboard. You need to make decisions on plans that can be executed. You need to avoid what I call the “Hail Mary” situations. The “Hail Mary” in football is where the quarterback peels off and throws the ball way up in the air, way down field, and hopes one of his receivers jumps up and catches it within a scrum of players waiting underneath. It’s a desperation play. It almost never works. Yet, it has a whiteboard play. It’s drawn up with X’s and O’s and arrows. The players have roles. The coach can explain it. It all makes sense. Except, any player that has been part of this play in an actual game knows that it’ll likely fail. The better plan is to be in a position where you never have to use this play. That’s where experience matters. The move to LA was such a situation for me at Match. On the whiteboard, the move could work. It made sense. Unfortunately, I knew that it was a Hail Mary. The Dallas situation was tough. However, it was real. And, while extremely hard, it was executable.

Set And Align Expectations

I look at things in two ways: an expectation path and a delivery path. For me, the expectation path is the “promises made” path. For projects, it includes working with the business owner getting their requirements, setting scope and defining deliverables and timelines with them. The expectation path is not under my complete control. Everyone reports to somebody, their boss, their board, and/or their shareholders. So, it’s not always possible to make all the decisions on what is expected to be done on the expectation path. The delivery path is the “promises kept” path. You need to align the expectations path with the delivery path up front. They may diverge and need to be realigned. You must communicate often to keep these aligned. The biggest mistakes happen when there is no delivery or the delivery is misaligned with the expectations. Here are a few things to consider around this principle:

Scenario 1: I tell you that I’m going to give you $1000 and then I give you $20. Scenario 2: I tell you that I’m going to give you $20 and I give you $20. In both scenarios, I gave you $20. However, I bet you’d be happy in scenario 2 and very upset with me in scenario 1. Make sure you deliver what you promise.
There have been many times when I explain a feature set and this feature set is “unacceptable”. Yet, if I show this same feature set is up-and-running and available to test (and launch), I get a different response: It’s running in test? Can I see it? When could you launch it live?
If I were to take you to a showroom of items and ask what you wanted, you may say “everything”. I put it all in the cart and say, ok, that’ll be $1,000,000. You’d probably be upset. Maybe you’d feel tricked? Maybe you thought the items were free or a lot cheaper. Make sure the cost of things is part of the expectation setting. Do it up front. Don’t wait until the end and then spring it on the payer.
I don’t know how many times that I’ve been told a requirement is a “must have”, that the business can’t survive without it. When I ask how it’s done today, I get this answer: “It isn’t”. Ok, let that sink in.

Spend the time up front to set expectations that help the business and that you can actually deliver at an acceptable cost. You can always launch in stages so don’t make the expectations all-or-nothing. If some of the “must haves” can’t be done up front (because, maybe, they are not really must haves), then launch them later. The most important thing is to deliver what you promise. A lot of times, people will ask for everything in the hopes of getting something. Or, they will not truly understand the risk/cost with doing “everything” all at once. In my experience, “everything” is never needed to bring substantial benefit to the company. Determine what can bring immediate value, is deliverable, and deliver it as promised. Phase in more features over time as you get more confident in the ability to deliver the other items that you haven’t already delivered. You climb steps one step at a time. You can’t leap all the way to the top in one jump. And, don’t stand there searching for an elevator when there isn’t one. Get climbing. Before you know it, you’ll look back and see a lot of steps behind you.

Show Progress And Build Trust/Confidence Early

I try to deliver something quickly because almost all deliverables can be delivered in increments. It shows progress. It builds trust and confidence both with the team and with the stakeholders. It’s best to start with an easier delivery early and then build your way up to the more complicated finished product. I’ve found that delivery always trumps expectations. And, expectations in a vacuum are pointless. Delivery never is. It yields value.

Manage expectations. Set scope. Set deadlines. Work the expectation path forward. But, focus on the deliverable path in parallel. At the end of the day, your delivery record will matter more that your expectations record. Anyone can make a promise. Those that keep them will always have a job.

Just Do It.

Like I said earlier, I don’t put a lot of faith in white board theory. The paper results never match the real-world results. On paper, everything comes out a winner. In practice, only a few will. You know how many times that I’ve heard that a proposed change would yield a 10% lift? Match grew like crazy. But, nowhere near the rate by which every change was projected. Product also needs to develop over time. I don’t believe that you can come up with the eventual answer right from the start. You need to launch something, get feedback, adjust, etc. And, you need to be sure that you test your way into it. Listen to what your customers and your data tell you after launch. As I mentioned in Chapter 2, just about every new project manager would come in and tell me that our home page could be better. They wanted to re-design it. I told them that our home page was the result of thousands of tests over time. And, inevitably, they would get their chance to test against it and lose. On a few occasions, we’d get a winner but things are never as easy as they seem on paper. The answers evolve and get better over time. Plan and discuss. Have your reasoning. But, understand that much of it may end up wrong. So, don’t waste a lot of time on the white board stuff. You just need to do it and adjust. You’ll almost never get the exact answer on the first try.

Let The Horses Run

I introduced this concept in Chapter 2. I have little patience for endless debating. It’s all guesswork in debate mode. I like hearing why we think something is a good idea. What’s the core reasoning behind the idea? Why do we think it’s better? But, getting mired in the weeds or comparing multiple ideas against each other on paper is mostly a waste of time. Launch them in an A/B test and see which one wins. We talk about the race horses and why we think one will win. Everyone will likely have valid reasons why their horse will win. Yet, only one horse will win. That’s why they run the race. If a horse keeps winning and winning, it’s simply a better horse. So, afterwards, keep the obsession of finding out why to a minimum. Sure, if there are obviously lessons as to why, use them in the future. Sometimes, however, there is no way to truly know why. Just move the winner to full production traffic and enjoy the business lift. Spend your time on doing more new tests to lift it even higher.

Keep It Simple.

I find brilliance in simple solutions. I’m extremely skeptical of complexity. Simple solutions have fewer parts that can break, are easier to diagnose when then do, can be more easily understood by people other than the original designer, can be tested easier and generally withstand the test of time. The six types of simple machines in physics are a wheel/axle, an inclined plane, a wedge, a lever, a pulley and a screw. In a complex discipline, over centuries, these six simple machines are still a foundation for many important implementations today. Find the “simple machines” in your field. Promote simple solutions. And, reward people that do.

Don’t Reinvent The Wheel

Use proven solutions. Almost every problem has occurred before. It’s very unlikely that you are the first person to ever see an issue. So, the first thing I always ask is what have others done to solve the problem. And, if we find a good solution, let’s not tinker with it because we think we can make it a hair better. This wheel is working just fine. Spend your time on fixing another broken wheel instead.

Practice The Way You Play

If you expect to perform well on game day, you better have practiced. Practice hard and practice smart. And, when I say smart, it means you practice in a way that you expect game day to happen. Practice game situations. Practice as a team. Have a game plan. Practice it. Business is no different. For example, make sure everything is tested before you move it to production. Ensure you have a testing environment that is similar to production. The Boston Red Sox have a spring training facility in Florida that is similar to Fenway Park in Boston. Same dimensions including a somewhat similar green monster (the left field wall). Why? So, during spring training their players are getting experience that is as close as possible to Fenway. Sure, it’s not exact. And, Florida weather is a little different than Massachusetts weather. However, control everything you can and don’t change things arbitrarily.

In Closing

While the early days set the stage for good team chemistry at Match, there were plenty of challenges going forward. Team chemistry must be worked at every day just like other important skills. I’ll quote Vince Lombardi again:

“Winning is not a sometime thing; it’s an all the time thing. You don’t win once in a while; you don’t do things right once in a while; you do them right all of the time. Winning is a habit. Unfortunately, so is losing.”

Many things in business require this type of mentality. We’ll talk a little more about leadership in the next chapter, something that I view as an “all the time thing”.