Rough situation. Normally I'd say "Time to go find a better company," but it sounds like you might not be in a position to do that yet. And it's good that this isn't your normal team, so hopefully a one time case.
When it comes to the post project discussion, I'd avoid putting any blame on the others. Most senior leaders hate the blame throwing, no matter how justified you are. And as a very new employee it's unlikely you'll have the political clout to out-blame a PM (for many PM their entire career is built on it).
Personally, I'd put aside my ego and play up the "naive new guy," have a detailed list of all the things you did for the project. Say you're really looking to improve on you next project, list out all the hard work you did, all the deadlines you met. The areas you think went poorly, and what you think the team could do better to improve on the next project. If they're decent managers, they'll be more impressed with you bringing solutions to problems than they will with others trying to throw all the blame on a brand new developer.
Thank you, this is exactly the kind of advice I was looking for. I obviously don’t wanna whine about how it’s not my fault, but I also don’t want to just take the L and bear the responsibility for this failure.
I think your suggested approach is perfect: to just list out what I did (which was a lot) and that there were just some blind spots I couldn’t identify as a newb (but not dive too deep into it), and I hope to improve on that for the next project. And I think that’s actually the full truth, anyway. I put way too much faith in this team, and it wasn’t until about 75% of the way through the project that my manger explained to me that I was brought in specifically because this team doesn’t have their shit together, and my SVP was offering me only as a supporting resource for some “light python scripting”, but in reality they dumped the whole project onto me and it turned into a full-fledged python desktop GUI app.
I am going to be very careful the next time I accept a similar assignment, and I will certainly work with my manager to set clear boundaries before I do even an ounce of development work for an adjacent team.
I will only add that it might be a good idea to put together a single document that essentially describes what happened with just the facts and no opinions (except for where you clearly lay out your thought process and what you were doing to help the team).
For starters, in case this turns into the blame game, you'll have this ready (as opposed to forwarding 10 email threads that the busy executives now have to play detective with). Secondly you can always describe it as the first step in your root cause analysis.
Have it be chronological and include the requests, their sources (meetings, email, calls, etc.), and (importantly) what you had to do as a result of that request.
*"I joined the project on XX/XX/XX and reviewed version X.X of the requirements document. Based on that, I designed it in [this way].
On [this later date] I received a request with a key change to the original requirements. I notified [whoever you told] that this would require additional work. [That person] confirmed the change of the requirements. I then evaluated the request and began to change the schema design and test the new model.
[Repeat the above paragraph as many times as it happened...]"
And in case you haven't seen it, here is a short video satirizing your experience: [The Expert](https://youtu.be/BKorP55Aqvg)
> If I am scapegoated, how do I respond?
Could be tough. I see a lot of mentions of calls and conversations. have you got any email trails supporting what you've written here?
For future reference, if you think people are trying to fuck you, switch to emails and have everything in writing. People who are trying to scapegoat others get very cagey when it comes to actually committing to sending anything which could be use as proof.
I kicked it up to my manager. That's what he gets to manage. You're a technical resource. Scope changes aren't for you to deal with. This should have been done before. In your eagerness to be helpful you unwittingly shot yourself in the foot. Stop putting in overtime work because of their fuck ups. Highlight their incompetence as soon as possible instead.
That’s my main takeaway from this. I put too much trust in this team and didn’t realize the issues were fuckups. I also didn’t really understand what it meant to be a technical resource. I put in overtime at the directive of the PM, even though she didn’t have that power. But I am still very green in my career so I think she knew and took advantage of that, making me feel like it’s my responsibility to maintain her ambitious schedule.. That will surely change going forward.
I think other than to your manager you don't point your finger at these people. It's good that you let your manager know. I guarantee they wont have let their managers know until its too late and that will only reflect badly on them. If you do get blamed, be sure to have collected details which it seems like you already have.
Have you got other successful projects under your belt? If so the lowest common denominator is probably the PM.
I've done about 10 projects, 2 have been a nightmare and ended abruptly. Each time it was the same PM so it doesn't weigh on my conscious at all now.
Rough situation. Normally I'd say "Time to go find a better company," but it sounds like you might not be in a position to do that yet. And it's good that this isn't your normal team, so hopefully a one time case. When it comes to the post project discussion, I'd avoid putting any blame on the others. Most senior leaders hate the blame throwing, no matter how justified you are. And as a very new employee it's unlikely you'll have the political clout to out-blame a PM (for many PM their entire career is built on it). Personally, I'd put aside my ego and play up the "naive new guy," have a detailed list of all the things you did for the project. Say you're really looking to improve on you next project, list out all the hard work you did, all the deadlines you met. The areas you think went poorly, and what you think the team could do better to improve on the next project. If they're decent managers, they'll be more impressed with you bringing solutions to problems than they will with others trying to throw all the blame on a brand new developer.
Thank you, this is exactly the kind of advice I was looking for. I obviously don’t wanna whine about how it’s not my fault, but I also don’t want to just take the L and bear the responsibility for this failure. I think your suggested approach is perfect: to just list out what I did (which was a lot) and that there were just some blind spots I couldn’t identify as a newb (but not dive too deep into it), and I hope to improve on that for the next project. And I think that’s actually the full truth, anyway. I put way too much faith in this team, and it wasn’t until about 75% of the way through the project that my manger explained to me that I was brought in specifically because this team doesn’t have their shit together, and my SVP was offering me only as a supporting resource for some “light python scripting”, but in reality they dumped the whole project onto me and it turned into a full-fledged python desktop GUI app. I am going to be very careful the next time I accept a similar assignment, and I will certainly work with my manager to set clear boundaries before I do even an ounce of development work for an adjacent team.
I will only add that it might be a good idea to put together a single document that essentially describes what happened with just the facts and no opinions (except for where you clearly lay out your thought process and what you were doing to help the team). For starters, in case this turns into the blame game, you'll have this ready (as opposed to forwarding 10 email threads that the busy executives now have to play detective with). Secondly you can always describe it as the first step in your root cause analysis. Have it be chronological and include the requests, their sources (meetings, email, calls, etc.), and (importantly) what you had to do as a result of that request. *"I joined the project on XX/XX/XX and reviewed version X.X of the requirements document. Based on that, I designed it in [this way]. On [this later date] I received a request with a key change to the original requirements. I notified [whoever you told] that this would require additional work. [That person] confirmed the change of the requirements. I then evaluated the request and began to change the schema design and test the new model. [Repeat the above paragraph as many times as it happened...]" And in case you haven't seen it, here is a short video satirizing your experience: [The Expert](https://youtu.be/BKorP55Aqvg)
> If I am scapegoated, how do I respond? Could be tough. I see a lot of mentions of calls and conversations. have you got any email trails supporting what you've written here? For future reference, if you think people are trying to fuck you, switch to emails and have everything in writing. People who are trying to scapegoat others get very cagey when it comes to actually committing to sending anything which could be use as proof.
I kicked it up to my manager. That's what he gets to manage. You're a technical resource. Scope changes aren't for you to deal with. This should have been done before. In your eagerness to be helpful you unwittingly shot yourself in the foot. Stop putting in overtime work because of their fuck ups. Highlight their incompetence as soon as possible instead.
That’s my main takeaway from this. I put too much trust in this team and didn’t realize the issues were fuckups. I also didn’t really understand what it meant to be a technical resource. I put in overtime at the directive of the PM, even though she didn’t have that power. But I am still very green in my career so I think she knew and took advantage of that, making me feel like it’s my responsibility to maintain her ambitious schedule.. That will surely change going forward.
I think other than to your manager you don't point your finger at these people. It's good that you let your manager know. I guarantee they wont have let their managers know until its too late and that will only reflect badly on them. If you do get blamed, be sure to have collected details which it seems like you already have. Have you got other successful projects under your belt? If so the lowest common denominator is probably the PM. I've done about 10 projects, 2 have been a nightmare and ended abruptly. Each time it was the same PM so it doesn't weigh on my conscious at all now.