How to explain a failure caused by someone else without acting defensively or as a bad colleague?

Question

I know there's a workplace forum, but I think I can get better answers here.

I work on projects. I always have the main boss (let's call them A), who remains the same over time, but the project manager (B) on my project is always my temporary boss. B gives his evaluation of my performance on the project to A.

My first project at the company was a disaster and I'm not completely sure what I could have done better. The problem was, B excluded me from important communication. I didn't receive important information and was dealt with in a very harsh way, which made my role very difficult, even impossible. It was no fun either.

I tried:

• addressing the problem directly with B. I tried several technics to convince them I need to be included, I would like to contribute more, etc. But it didn't work out. I tried being nice. I tried pressuring them. Nothing worked.

• talking to A and explaining the problem. They said they understood but told me to "make an effort" - I tried asking what it means, but didn't get any additional info.

I need to discuss my "performance" on the project with A now and I'm really uneasy about it. I love delivering results and the project... It was a disaster. I'm super tired of struggling for every piece of information. And I know I didn't contribute how much I would love to have contributed.

I don't want to blame anybody. Also I'm afraid I will come across as defensive and searching for excuses.

What the best way to tackle that?

Answer 1

Assuming that your assumption is correct: your project manager threw you under the bus. He didn’t do his job of delivering important information. To not come over as defensive, you absolutely need to throw your PM under the bus. State very strongly what you needed from him and what he didn’t deliver.

For example, make a list of what information you needed, when you asked for it, when you asked for it again, and when you finally received it. Again, assuming your complaints are justified, you want him to take the blame, not you. You can be sure that his evaluation of your performance will blame everything on you.

On the interpersonal level: Before you talk to your boss A tell yourself and convince yourself that your complaints are facts not opinions and definitely not excuses. You form your reality and with that reality you go to your boss. He’ll argue about opinions and laugh at excuses but facts are facts and cannot be denied. That’s something you can practise, and it works.

Regarding Rainbacon’s comment: This is advice how to interact well with manager A, not with PM B. OP has at this time no desire to interact well with B. The complaint that part of the advice is intra-personal completely misses the point. Learning how to interact with others is intrapersonal. Saying “talk to your boss in a convincing way” is useless advice without advice how to achieve this.

And it works. One of my better successes using this method was getting a $3,000 cabin upgrade for an 80 year old couple, for free.

Answer 2

TL;DR:

Stick to the facts, come there with ideas on how to improve things.

---

At my workplace, after every major (bad) incident, we do what we call a "post mortem".

It's a meeting were everyone related to the incident comes. It's not to assign blame, it's only to understand exactly what happened to make sure it will never happen again.

Here it's how it usually goes:

1. The timeline

We establish a timeline of the incident. For example, something like:

11:32 am - A new version is pushed online.

12:45 am - All non-regression tests are run, no error comes up.

2:16 pm - Person X see something weird, do a round of tests to make sure the application is fine, don't find anything, assume they made a mistake the first time.

3:56 pm - A client sends a mail to complain. The mail isn't read until two days later.

10:03 am the next day - An important client phone to complain, the team is finally aware that there is a problem.

10:42 am - A rollback is done. The application is correctly working again.

As you can see here, the timeline is strictly fact-oriented. As I said, the idea is not to assign blame but to make sure something like that doesn't happen again.

2. Making a plan

In the second part of the meeting, we list the action we will take to make sure that the problem doesn't occur again in the future.

For example:

• Adding a non-regression test to verify X, Y and Z.

• After pushing a new version online, be available to read emails that client might send to complain about the issue.

3. Assigning the points of action

Finally, after each possible actions have been listed, the points are assigned to people.

For example:

• [QA team] Adding a non-regression test to verify X, Y and Z.

• [Product Owner 1] After pushing a new version online, be available to read emails that client might send to complain about the issue.

---

In my current workplace, I already had two of these meetings where I had some things to blame myself for (thankfully, not that much) and I find those meetings far less stressful than the one where people just want to assign blames.

Also, it does work great to make sure things improve.

I know your situation is a bit different, so you might have to adapt what you will talk about (for example, also talking about the good things). But, when it comes to talking about what went wrong, sticking to the facts and having a plan for it to not happen again has always done wonders for me.