64

I work at a tech consulting company in the US and I recently took over a project from a coworker (Bob) who got laid off. (He was mainly let go because of covid, but he wasn't the easiest to work with and people occasionally had complaints about him.)

A few weeks before Bob left, he deployed a big feature into production. The deployment seemed to work properly. He did not know at the time that he would be laid off and there was no particular extra pressure/stress involved with the deployment.

The client asked me last week about an issue they were seeing with the production, where some of the data wasn't flowing through. Nothing major but it raised quite a few eyebrows from the client side.

After looking into it, I see that Bob had forgotten to remove a testing filter which was limiting the input data. This means that for the last month the process wasn't working for a significant section of the target data. Thankfully it is fixable without permanent damage.

I honestly sympathize with the client about this: It was quite a big oversight. How can I professionally acknowledge that my former colleague made this mistake and express that I'm also not-happy about this, but without making a big deal out of it or sounding like I'm bad mouthing Bob?

Improve this question
6
  • 37
    "It was quite a big oversight" Was it Bob's fault alone ? Management had no fault ? Your organization's code review process has no faults ? And the place you last worked in - would you think it would be fair and appropriate if they were telling clients you (by name !) were to blame for issues after you're gone and without your knowledge ?
    – StephenG - Help Ukraine
    Jun 17, 2020 at 10:32
  • @seventyeightist and Joe Strazzere there were some known process issues on this project specifically, but it's not a company-wide issue. My question was a drop oversimplified to keep things generic. TBH, it's unlikely that this coworker would have stayed as the lead engineer for the project for much longer, even if he hadn't been let go.
    – c36
    Jun 17, 2020 at 16:24
  • 11
    I would like to emphasize what others have already pointed out. A proper retrospective should be done - even without the colleague - to find why and how such an error made it into production. Simply saying "It was that guy, he's gone" is not going to prevent it happening again.
    – bytepusher
    Jun 18, 2020 at 1:21
  • 1
    If it's a production system, and they have specs on the input and output, how could this not be detected within hours? If I put in an invoice with 500 items, I need to see 500 items somewhere else. I will expect 500 items split up into orders according to the spec, which is worked out before hand and someone should be able to work out the input/output by hand if they have to.
    – Nelson
    Jun 18, 2020 at 1:22
  • How would you handle it if the colleague was still in the company? Or if it was your fault. Should it matter in the end?
    – Gerhardh
    Jun 19, 2020 at 14:42

9 Answers 9

Reset to default
317

Why don't you just acknowledge that you found the problem and fixed it? Why do you need to name names? If pressed, tell the client

"We left a testing filter in place. We removed the filter and the issue is now resolved."

Naming Bob is not going to make the mistake any less concerning to the client and does nothing to appease them... and so naming Bob is unnecessary and gains you (and the client) nothing.

After all, it's not Bob, or you, or John Doe. It's your company. Your company is responsible for the mistake, regardless of who made it.

Improve this answer
15
  • 94
    I think I'd go for "A testing filter was left in place. We removed the filter and the issue is now resolved."; saying "We left.." implies that the people who did it is still at the company.
    – PeteCon
    Jun 16, 2020 at 19:26
  • 19
    The OP said the employee left, not that he was fired. Additionally, this isn't information the client needs to know and serves no purpose in addressing the mistake. Furthermore, if a company that I purchase goods or services from fires employees for making mistakes then that's probably not a company I want to do business with, so telling the client this has the potential to cause harm to the business relationship. Not everyone wants blood when a mistake is made. Some companies frown on that idea.
    – joeqwerty
    Jun 17, 2020 at 3:37
  • 146
    This wasnt the fault of one person, it was the fault of many - the processes involved that allowed the testing filter to make it to production were either flawed or non-existent, so it wasnt just Bobs fault - use it as a learning exercise and improve the processes. There is nothing wrong with admitting the process is flawed so long as its improved as a result of that admission. While Bob might be gone, most of the reason he could make the mistake remains in the company.
    – user34687
    Jun 17, 2020 at 5:12
  • 13
    @IMil as already stated in other comments, such a statement would look really bad in everyone's eyes. Creating a blame culture so strong that you fire someone if he makes mistakes is not something good. As a client, I might want to go look elsewhere. As an employee, I would definitely start polishing my resume. As already stated, it's never about the people, it's all about the processes that let this mistakes go unnoticed.
    – bracco23
    Jun 17, 2020 at 9:06
  • 69
    TLDR; Never, ever, air your internal dirty laundry in front of a customer.
    – J...
    Jun 17, 2020 at 16:05
66

I am going to look at that from the customer's perspective:

I don't care if Tom, Dick, or Harry was responsible- you as a company / team are responsible to me.
I care about this getting fixed, and verified, so we don't have to look at it again; and I especially care about your processes getting permanently improved so this won't happen again in the future - more testing, quality control, automatic verification, peer reviews, whatever, you name it. Convince me that a similar issue cannot happen again.

Giving me a person's name is not only useless, but tells me that you are not a team that takes responsibility, but instead blame someone (even rightly so), and fire him?

As a customer, I want improved quality control and you as a team taking responsibility, not three more issues this year with a name each time who's fault it was.

my recommendation is to use 'We', and strictly decline to name a person, even if asked.

Improve this answer
4
  • 12
    I'm a one-man team and I still use the word "we" in all my communications. "We implemented a new..", "We had a bug..." Works both ways. I don't take all the credit for the good or all the blame for the bad.
    – egherrmann
    Jun 18, 2020 at 14:54
  • @erich8 - You technically still do... but this good practice frees the first person singular for you to be able to occasionally say "I think" or "I would advise" for cases that where you are volunteering to help your customer with anything outside of what they are paying you for and outside of what you want to be blamed for in case they go with your word.
    – Jirka Hanika
    Jun 19, 2020 at 9:27
  • 2
    My preference goes out to removing any "he/she/we" from any communication regarding a product / service. Sure, "we" (as in the company/one-man-band) might offer a service/product. But in case of something new, a bug, whatever, it's generic. "A filter was left in the code from testing. It has been removed and the issue is now resolved." But I think OP might need to look into it's existence before pressing "delete", you don't test with a useless (extra work to create) filter for no reason...
    – rkeet
    Jun 19, 2020 at 11:57
  • I would bold "I especially care about your processes getting permanently improved so this won't happen again in the future" (it won't let me do that because it's only 4 characters and minimum is six). This is the most important thing--the client wants to know what reason they have to believe that this isn't going to happen again.
    – msouth
    Jun 19, 2020 at 18:52
13

How can I professionally acknowledge that my former colleague made this mistake and express that I'm also not-happy about this, but without making a big deal out of it or sounding like I'm bad mouthing Bob?

The mistake was in letting anybody deploy a feature when they won't be around to make a fix if there is a problem. That means you or your company made the mistake.

I know places that never make a change on a Friday, because the pressure to get it done while ignoring warnings signs is too great. Releasing on a Friday also means nobody is there to fix it for 60 hours.

Letting a change hit production when Bob was in his final days just compounds the problem. There was probably pressure to get it finished.

So you report the problem, and how it is going to be addressed the same way you always do. If the client presses for more details the team/company should take the blame, don't try and put the blame on Bob.

I have been in Bob's shoes. People wanting me to make changes on my last day, and then complaining when everything wasn't perfect.

Improve this answer
7
  • This in an interesting point, in general. It's not relevant to this exact situation though - He was laid off a few weeks after the deployment, so there was no extra pressure on him at the time when he was deploying it and he was certainly around to fix it initially... The issue just went unnoticed for about a month and at that point he was gone.
    – c36
    Jun 16, 2020 at 19:49
  • 12
    "The mistake was in letting anybody deploy a feature when they won't be around to make a fix if there is a problem." ................. I think when Bob deployed that feature, he didn't know he was about to be laid off. Probably (if my experience relates to other companies) his immediate management who would have signed-off on the deployment didn't either. As far as any of them were concerned it was "just another day in the office", until it wasn't. ... (Sidebar: asking a "known to be laid-off employee" to 'just make this change' is asking for trouble yes.)
    – seventyeightist
    Jun 16, 2020 at 19:51
  • 1
    The timing should be added to the question, The question said "Right before Bob left, he deployed a big feature into production." But it appears the change was weeks before he even knew he was going. That changes the entire premise of the question.
    – mhoran_psprep
    Jun 16, 2020 at 19:56
  • @mhoran_psprep Yeah, agree. The details weren't stated in the question and should have been; I "intuitively" knew that Bob had deployed that feature before he knew he was going to be laid off, but it ought to be made explicit.
    – seventyeightist
    Jun 16, 2020 at 20:00
  • 6
    The real problem is letting anyone be responsible for a feature completely own their own. It doesn't matter if you never plan on firing them, they can quit themselves, they can get run over by a bus.
    – Voo
    Jun 18, 2020 at 9:08
10

Simply put, you can't.

Code errors are the responsibility of the company, not the employee. If this got through to production, then it is the company's fault. If you wanted to assign individual blame (which is almost always both unwise and unlikely to be accurate), it would take a lot more information. (I.e. Who authorized a deployment to occur with insufficient QA? Did they authorize that due to an unreasonable budget requirement? Etc.)

The bottom line is that as it was the company's fault and you are now the face of the company for this customer. So you should be expressing regret for "our error" and offering the customer the best solutions the company can provide. It would be unprofessional to turn Bob into a scapegoat.

Improve this answer
6

When I was working in a different field, if something like this happened the main question from both management and customers is "What are you doing to make sure it doesn't happen again?". "Being more careful" was an inadequate answer. I can imagine that a reasonable approach would be to open a bug report when the filter is put in place. After all, you have made the software not function as desired, even if it was intentional. Then you review all the open bug reports before making the production build, which you may do already. We would then be asked to review our process to see if there were similar holes elsewhere. You might be asked if you write a test version of some piece of code how you make sure the real version is used in the final build, for example.

Improve this answer
5

How can I professionally acknowledge that my former colleague made this mistake and express that I'm also not-happy about this, but without making a big deal out of it or sounding like I'm bad mouthing Bob?

I don't think you can unless the client had previously knew Bob as someone who would make mistakes like that. Without that bit in history any attempt to pass the blame on Bob, rightfully or not, will just look like passing the blame instead of owning up the mistake.

So even though it may be right to blame Bob in this case, likely the safest thing to do is to simply own up to the mistake, fix it and move on. Mistakes happen, they are part of life, and that is usually understood. Blameology on the other hand rarely goes by well, even if deserved.

Improve this answer
2
  • Agreed. Passing the blame serves no purpose. Assigning accountability does, but seeing as Bob no longer works there, telling the client "Bob did it" doesn't accomplish anything. Additionally, I take a dim view of companies that play the blame game and I don't do business with them. "Blaming it on Bob" has the potential to harm the business relationship. The company should own the mistake, not point the finger at it's employees. "We made a mistake and we've resolved it."
    – joeqwerty
    Jun 17, 2020 at 3:42
  • "own up to the mistake, fix it and move on." should be "own up to the mistake, fix it and make sure it can't happen twice"
    – Mooing Duck
    Jun 17, 2020 at 22:25
3

How can I professionally acknowledge that my former colleague made this mistake and express that I'm also not-happy about this, but without making a big deal out of it or sounding like I'm bad mouthing Bob?

Some of the places I worked this was done because everyone knew that "Bob" was a problem. Other places, this was a running joke, "blame the guy that left". In both cases, it was only internal to the shop. DO NOT BADMOUTH former employees to a client. It makes your company look bad. As others mentioned, acknowledge the bug and then move the focus to the fact that it has been fixed. No harm, no foul.

Then as mentioned, fix the internal processes that allowed a test filter into production (preferably, don't mention that it was a "test" filter that got into production). Letting test only code reflects poorly on your company's processes.

Improve this answer
2

I’d tell the customer that you found a problem in the company’s code, and that it is now fixed. That’s it. Blaming someone else can only put you into a bad light. Especially blaming the guy who just left and can’t defend himself.

Improve this answer
1

There are two different problems here:

  1. Is the mistake that caused issues with a client. Simply acknowledge that you have found the issue and fixed it. Do not bring up who caused it.
  2. Is the lack of structure that allowed such a mistake to affect the client. This is a far harder problem to solve as it requires changing something at your company. You didn't mention what kinds of QA your company has, what kinds of sign offs, etc. But these need to either be put into effect or updated based on this problem getting through. This can mean political action and convincing upper management to buy into these changes.
Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .