The opinion of the court was delivered by: Katharine S. Hayden, U.S.D.J.
In early 2001, defendant UBS Services USA LLC (―UBS‖) hired plaintiff R. Dale Mitchell, who was almost 54 years old at the time, to work in its Corporate Information Security (―CIS‖) Department. Four years later, in 2005, UBS fired Mitchell, citing his persistent failure to satisfy the company's employment expectations. In response, Mitchell filed a two-count complaint against UBS, alleging violations of the New Jersey Law Against Discrimination (―NJLAD‖), N.J.S.A. § 10:5-1, et seq. He claims in this diversity action that UBS discriminated against him because of his age and in retaliation for complaining about the discrimination. UBS has moved for summary judgment [D.E. # 22], which the Court now grants for the reasons that follow.
I. FACTS & PROCEDURAL HISTORY*fn1
UBS provides information technology services to its affiliated companies. Def. R. 56.1 Statement of Material Facts (―Def. Facts‖) ¶ 1. Its CIS Department is responsible for ensuring the technological security and integrity of computer systems throughout the UBS family. Id. ¶ 2. The company hired Mitchell on February 2, 2001 to work as a Lead Associate in the CIS Department; Mitchell was 53 years and 11 months old at the time. Id. ¶¶ 3-4, 7.*fn2 Peter Sacher, a Systems Administration manager and Mitchell's direct supervisor throughout his employment at UBS, interviewed and participated in the decision to hire Mitchell. Id. ¶¶ 5-6; Certification of Peter Sacher (―Sacher Cert.‖) ¶ 5. Mitchell asserts that Sacher did not play a primary role in the interview and that the responsibility for the hiring decision came from Technology Officer Regina Toney. Pl. Resp. 56.1 Statement of Facts (―Pl. Resp. Facts‖) ¶ 5. Mitchell admitted at his deposition, however, that he did not know who made the ultimate hiring decision. Def. Rep. R. 56.1 Statement of Facts (―Def. Rep. Facts‖) ¶ 5.
As a Lead Associate, Mitchell's responsibilities included the following:
Establishing computer access for authorized users;
Creating user IDs to ensure that UBS employees had sufficient access to the UBS system, consistent with their security clearances;
Resolving and closing ―tickets‖-troubleshooting requests for assistance by computer users experiencing technical difficulties;
Issuing passwords to UBS computer users to permit them to access the mainframe;
Creating reports for user access;
Conducting forensic analysis of computer users' activity;
Providing "on-call" support upon request;
Registering the correct installation date for computer programs, which are necessary for programs to be put into production at the correct time.
Def. Facts ¶¶ 10-15*fn3 ; Certification of David B. Beal (―Beal Cert.‖) Ex. 5 (hereinafter referenced as ―Mitchell Dep.‖) at 26:8-14; 28:25-31:23; 34:17-35:25; 36:1-25.*fn4 When asked at his deposition whether he considered CIS's role within UBS important, Mitchell responded, ―Oh yes, critical,‖ and elaborated that without CIS, ―things could be mismanaged, things could be misappropriated, things could be -- information could be damaged. In a financial institution, it is built on trust and integrity of the data. We must keep that [data] precisely accurate.‖ Mitchell Dep. at 25:5-15 (emphasis added).
Mitchell's employment went without incident until August 2004, when his superiors began alerting him of a series of job-related errors. On August 11, 2004, Toney advised Mitchell via e-mail that he had processed a ticket (a troubleshooting request) incorrectly by assigning the user the wrong access code. Beal Cert. Ex. 6; Def. Facts ¶ 17. On August 19, 2004, Toney again e-mailed Mitchell, stating that he had failed to close a number of tickets that were supposed to be closed on August 4, 2004 (Mitchell had instead placed the tickets in a hold status). Beal Cert. Ex. 7. She requested that Mitchell close 12 remaining tickets and advised him that she ―need[ed him] to start taking extra steps and double check the information that's given in the request forms and not just place the tickets in pending or on-hold status.‖ Id.; Def. Facts ¶ 18. The next day, Toney alerted Mitchell that he had granted certain access to users who had not been approved, and emphasized that ―I must stress to you to be careful when you are defining new dataset profiles[,] if you need help please see me.‖ Beal Cert. Ex. 8; Def. Facts ¶ 19.
On August 23, 2004, Toney e-mailed Mitchell the following:
We were told two years ago by auditing that we can no longer setup user ids and make their non-expiring password the same as the id. We spoke about this issue back on 7/26/04 when you processed GTS ticket 250034 to create the two non-expiring user ids RESPRD1 and RESPRD2. You forgot again to run the encryption job that you created for the group back in December of 2000 that answered our audit issue . . . . If you need more training on these procedures please see me. If one of these processes are [sic] not followed correctly we will never be able to pass the audit.
Beal Cert. Ex. 9 (bold in original); Def. Facts 20. A week later, on August 31, 2004, Noel Murphy (another UBS employee) e-mailed Mitchell (and cc'd Toney and Sacher) the following in response to Mitchell's modification of a ticket request that he had submitted:
Here we go again. You cannot modify either a new job request or an update to [a] current job request. Once we process a request from you that's it. You then have to fill out another online request form. . . . We will then receive this new request and act on it. Once a request is marked complete or in rare cases rejected that's it. You either verify your request was done or you resubmit the request again correctly. In the latter case yes a new request number is generated.
Beal Cert. Exh 10; Def. Facts ¶ 21. Toney replied to Murphy's e-mail by e-mailing Sacher, stating that ―[w]e went over this issue last week. Dale was told he needs to generate a new ticket for [h]is updates, but again he used an old ticket number . . . .‖ Id.
On September 7, 2004, Mitchell e-mailed Sacher, alerting Sacher to an error he had made regarding changing a portion of a computer program, and advised him that he had forgotten to make the necessary change, but that the error was in the process of being corrected. Beal Cert. Ex. 11; Def. Facts ¶ 23.
On November 10, 2004, Sacher e-mailed Mitchell requesting an explanation as to why he had sent an e-mail to a certain group of employees (the ―Technology Infrastructure‖ distribution list) that should not have received it. Beal Cert. Ex. 13; Def. Facts ¶ 25. Mitchell explained that he was trying to find the correct recipient of the e-mail because the normal contact was out of the office, and unfortunately the list ―turned out bigger than [he] thought.‖ Beal Cert. Ex. 13.Approximately two months later, on January 11, 2005, Mitchell was sent an e-mail by Ron Seggio, Director of Application Support and Communication Services, again admonishing him to stop using the Technology Infrastructure distribution list because the e-mail to that list was being ―delivered to many many people that should not receive it.‖ Id. Ex. 14 (repetition in original); Def. Facts ¶ 26. In response, Sacher (who had apparently been forwarded the e-mail) reminded Mitchell of the erroneous e-mail in November 2004 that he had sent to the Technology Infrastructure distribution list, which sends a message to the ―entire division.‖ Beal Cert. Ex. 14. Sacher then demanded to know why Mitchell had again used the Technology Distribution list after being warned not to only two months before. Id.
In mid-January, 2005, Mitchell rotated in as the on-call associate responsible for troubleshooting technical issues that arose during off-hours. Beal Cert. Ex. 16. At 5:00 a.m. on January 15, 2005, Toney e-mailed Mitchell (and cc'd Sacher) with a technical problem that had arisen during the night. Beal Cert. Ex. 15. She stated that she had tried calling him at two different phone numbers, explained the particular technical issue, and asked him to verify her understanding of the issue. Id. Later that morning, Sacher e-mailed Mitchell, asking him to confirm that the numbers at which Toney had called him were correct; Sacher explained that he too had experienced problems reaching him at the numbers. Id. Mitchell responded to Sacher at 10:18 a.m., stating that ―[the numbers] are correct. I [mu]st have left my PC plugged in when I fell asleep -- the cell phone was on the charger. I was going to check the job the next morning rather than at 3AM, for there was no rush.‖ Id. Four days later, on January 19, 2005, Sacher e-mailed Mitchell to confirm that Mitchell's new laptop was functional (unbeknownst to Sacher, Mitchell had spilled coffee on his old one). Beal Cert. Ex. 16. Sacher stated that ―[i]t is critical that you are able to remotely assist with any issues that arise off hours since you are on-call this week.‖ Id.
Mitchell does not dispute that he committed the errors described above; rather, he disputes the gravity and exceptional nature of the mistakes. For instance, Mitchell asserts that the incorrect ticket that he processed on August 11, 2004 was a type of error ―not uncommon for his co-workers.‖ Pl. Resp. Facts ¶ 17; Mitchell Dep. at 168:14-23. With respect to his repeated e-mails to the Technology Infrastructure distribution list, Mitchell minimizes the impact of the mistakes, asserting that ―in most cases, the only problem with sending an e-mail to the wrong distribution list [i]s that it creates clutter.‖ Pl. Resp. Facts ¶ 26; Mitchell Dep. at 58:5-9. Regarding the tickets which Toney specifically advised Mitchell that he had failed to process and which prompted her request for him to take extra steps to close them, he avers only that the ―amount of time required to close a ticket varies depending upon the ticket.‖ Pl. Resp. Facts ¶ 18; Mitchell Dep. at 153:5-16. With respect to Toney's inability to contact him during his January 15, 2005 on-call duty, Mitchell acknowledged that he should have been reachable at the time Toney was attempting to contact him. Mitchell Dep. at 65:13-22. He asserts, however, that it was not uncommon for people in his department to be unreachable while on call, and that that incident was the first time he had been unavailable to meet his duties as the on-call associate. Id. at 172:15-173:24; see also Pl. Resp. Facts ¶ 30.*fn5 Mitchell emphasizes that the other errors were easy to make and caused insignificant harm to the company, or in some cases, none at all. Pl. Resp. Facts ¶¶ 21, 23, 24, 26.
Meanwhile, Mitchell asserts that between October 2004-shortly after the time in which UBS now asserts that he began underperforming-and January 2005, he and Sacher had a series of one-on-one meetings. Def. Facts ¶ 40; Mitchell Dep. at 101:8-9, 109:15-20, 156:4-10. He states that during these meetings, Sacher would begin ―ranting and raving and shouting,‖ but he cannot recall precisely what Sacher said other than that he called Mitchell ―absentminded,‖ ―forgetful,‖ and ―slow.‖ Def. Facts ¶¶ 41, 48; Pl. Resp. Facts ¶ 48; Mitchell Dep. at 101:19-103:23, 184:22-187:1. At his deposition, Mitchell described Sacher's demeanor at the first meeting, and his own reaction thereto, as follows:
I was called into his office. The door was closed. And he started one of his rants. And he was complaining about, oh, mistakes, not crossing the Ts or dotting the Is or a typo or a date that was off or something like that. And it was not constructive. . . . To my opinion, it was irrational. . . . He was using a very loud voice. . . . I was appalled and bewildered.
Mitchell Dep. at 156:11-157:13; Def. Facts ¶ 42; Pl. Resp. Facts ¶ 42. When pressed as to what Sacher actually said, this exchange followed:
Q: So he called you into his office. And tell me what you can recall was said in the conversation as closely as you can recall it as if I was listening to it.
A: That's the problem. A lot of what he said didn't make a lot of sense.
Q: Regardless of whether it made sense --
Q: -- can you tell me what he said?
Q: You can't recall what ...