Has refusing to cast blame ever cost you a job?
Posted by orlandoduran@reddit | ExperiencedDevs | View on Reddit | 70 comments
I like my job. I like my coworkers. I even like my CTO and CEO.
I just cannot bring myself to say shit isn’t my fault. If my work looks broken because someone else fucked up, my first and last impulse is to figure out how I could have done something differently such that it would have made the fuckup either impossible or less disastrous and then claim responsibility for the failure. Historically this has led to coworkers going to bat for me when asked to evaluate me, but for whatever reason I’m feeling lately like I’m setting myself up to eat shit.
mistyskies123@reddit
In a psychologically-safe, pleasant working environment - you can do this, and should be ok.
Anywhere else, and unless you're utterly brilliant - someone is likely to use it against you (whether wittingly or unwittingly) at some point. Maybe it's just a performance calibration review where someone at the table attributes a problem to you, and you get a lower rating than you actually merit.
Is it worth some therapy? Taking the blame for others isn't a healthy behaviour, whether in the workplace or not.
And maybe you're "protecting" someone who does need to learn.
fadedblackleggings@reddit
Focus on systems, procedures, and operations are the root cause of failure. Not people.
ba-na-na-@reddit
If you work with a lazy incompetent asshole, systems and procedures won’t clean after him, people will.
selflessGene@reddit
People are parts of systems. If you keep fucking up and not following clearly defined responsibilities, part of the 'system' should be that you get fired.
SituationSoap@reddit
I think this is a pretty reductive response. Systems, procedures and operations do not exist in a vacuum -- they are all built, operated and coordinated by people.
The urge to wrap everything in ever-increasing layers of process instead of just recognizing that you have people who aren't doing decent work, and managing them out of your team, is one that escapes accountability. It's a perverse incentive that allows everyone to shirk accountability and it's not a healthy way forward for teams.
syklemil@reddit
Yeah, plus those things are also sort of continuous training.
The first time someone uses a linter or gets their code run through a policy engine or whatever it can be a bit much, but over time it just becomes a habit not to do the things that produce complaints.
If the rules get added because they have actually been shown to be a cause of an outage or bug or other problem, not just because, the organization learns to not repeat mistakes, rather than specific employees who may leave and be replaced by someone without that experience.
bwainfweeze@reddit
Don’t know that I’m a paragon of interpersonal relationships but I think blaming on outcomes is toxic, but blaming on decisions is a sharp knife that requires delicacy of use.
If someone, especially a trash talker, keeps encouraging the team to go left when they should have gone right, it can be useful to remind the team of how infrequently this person’s decisions don’t turn out well. The loud dev can trigger other devs’ Impostor Syndrome, which can cover up some of their Dunning-Kruger.
And if you are a chatty dev, you have to be careful not to raise your boat at the expense of others. Use your debate powers for good.
BanaTibor@reddit
Yes, you are right, you are setting up yourself to eat shit. Defending yourself and casting blame is not the same thing. You can say, "yeah, that wasn't me specifically" or "it didn't happen due to my work". At the same time you can point out that you as the whole team have overlooked something which lead to a disastrous outcome, and you should analyze what went wrong, why nobody saw it, and how can you prevent it in the future.
Taking it upon you all the time casts a bad light on you, your bosses will think that guy always fucks up.
labouts@reddit
It's a systemic problem at your company if an inquisition to assign blame is a frequent enough fixation for this to be on your mind.
Blameless postmortems are important for most effectively responding to incidents and planning how to avoid similar incidents in the future for a variety of reasons.
The best resolutions are creating processes that catch similar problems before they cause harm. Firing a developer who pushed buggy code to main is a less effective fix than block direct pushes to main and requiring PR approvals before merging.
CodePharmer@reddit
I agree that blameless postmortem is helpful, but they are frequently done with a dogmatic refusal to call out individuals' responsibility. Example: a senior dev may be consistently approving buggy code or a project manager repeatedly fails to completely define functional requirements. Tiptoeing around "naming names" for those kinds of failures usually ends up with a huge amount of additional process requirements that are only in place due to one or two individuals, while everyone else suffers the beauraucratic overhead. Sometimes the individual responsible for the issue is never even aware that their mistakes are the reason for the additional process. Usually, the same people that drove the creation of those new requirements in the first place will find the quickest, simplest ways to satisfy those requirements and still cause issues, which drive more process requirements, until you are in a beauraucratic hellscape because no one is willing to say "this individual keeps fucking up"
labouts@reddit
Sure, I'm not implying that developers are never at fault in any meaningful way.
The place to catch that is their manager being sufficiently aware of what's affecting their team's productivity or causing consistent problems in their workflow.
It's generally unhelpful to focus on that while responding to incidents or the initial discussions around preventing similar problems.
In any case, it's unlikely that taking the concept too far is a significant risk in OP's case based on what they said.
A preoccupation with blame is a more common problem at the majority of companies compared to problems from avoiding it to impractical degrees despite grossly incompetent employees who should be fired.
CodePharmer@reddit
Yeah, my response was not really targeted at OPs situation, just something that I frequently see play out in those kinds of blameless post-mortems within a developer team. And yes, the primary goal after an incident should be "how can we fix this," but incident post-mortems should take place afterwards, and frequently reveal either a confluence of independent failures or a pattern of failures by individuals which contributed to any type of incident. Management doesn't want to hear about complex or systemic organizational failures, so they try to simplify the issue and ideally assign blame to teams for which they don't have direct oversight. I agree that in larger orgs, especially those with corporate ladder-climbing management, people will go out of their way to assign and document blame (particularly for high profile issues). That blame tends to be interdepartmental though, since assigning blame to members of your own team reflects poorly on your ability to manage them.
At the end of the day, developers generally bear the brunt of that blame (since they are the only ones actually implementing anything).
Requirements weren't clear? Dev should have asked for additional clarification!
Failure to identify failures during testing? Dev should have defined more test scenarios more clearly!
Infrastructure fails due to unreliable architecture? Dev should have designed a solution to expect those failures!
It's like blaming the construction crew for a building collapse even though they received incomplete blueprints, poor quality materials, and a pro forma inspection.
Ever since tech companies (cough) MICROSOFT (cough) started to get rid of dedicated testers and shifted testing responsibility onto devs, it feels like we have been going down a slippery slope where we are increasingly held responsible for every aspect of feature work - dragging formal requirements out of project managers, defining and executing test scenarios, building around known deficiencies in infrastructure, etc... And for full stack devs the problem is even worse because you are handling all of those issues for each layer of the stack, which now regularly includes devops as well.
/rant
bland3rs@reddit
I know what you're talking about.
When it's not out of malice and competition, I have found out that it's because some people just have worse memories, so in organizations where this is more of a problem, I make sure we all produce a lot more documentation.
How I know is that I personally tend to remember a lot. I can generally tell you why something didn't work out a year ago, who caused it, what led to it, the decisions we made, and the outcome of those decisions. I will keep most of the blame secret in my head, but it plays in a role in decision making nevertheless, because there's no point repeating work that we've already tried and now know that doesn't work, y'know? I want to move forward.
But when we talk as a team and someone suggests an idea that we tried a year ago, and everyone agrees, what does it tell me? It tells me that no one remembers and we're about to go in circles.
And I've worked on places where this has been a problem and also those where it hasn't. For those where it is a problem, I just make sure that we, as a team, produce sufficient documentation. It's kind of lame that you have to pull out a doc when there is any contention, but what can you do.
ezaquarii_com@reddit
Attack the problem, not the person.
"Our code approval methodology is inadequate and biased."
Now you can improve the process, ex require 2 reviewers approval.
Gwolf4@reddit
I believe you are misunderstanding what a blameful postmorten is. Iirc one is when a developer breaks something, no matter that time constraints/requirements where insane. Then the error is of the developer, and you are the one written on the report, no matter if you are called in public or in private. Suddenly you get a small message wether by slack or at the end of a daily and you get "you are the culprit".
Let's forget that the pm never gave you the tools, that another person approved your commit, or worse you just have direct access to dev, that QA did not catch your issue.
An error is not a developer thing, it is a deparment issue and that is why the last part talks about:
Blameless is just avoiding putting all the responsability of an incident into the shoulders of the developer when in reality all the department is at fault.
I will never forget my first blameful postmortem. It was THE MIDDLE of the daily, in front of all the department, we were a small one but the thing remains, the department leader stressed because yesterday he wasn't able to show something because I broke something in DEV that org did not have other env than dev. He told me "Do you agree this is your fault right?", but cast aside that the thing that again there is no other env than dev, I was tasked that thing with only one day of advance and that task was going to be shown to investors the next day, and this guy did not ever bothered to check the site that he was going to present, hes job was not be my qa, but he did not even know how to use the new spec, this task had to add some global buttons and menus so they of course went into a config modal, not as main page buttons, and then 2 hours after my end of day I get a slack "can you point me where the configs are?".
But yeah I was the culprit.
JoeBidensLongFart@reddit
A strong manager needs to be willing and able to differentiate between a good developer getting burned by a bad process vs a bad developer sidestepping good processes and allowing production failures as a result. In the latter situation, the developer who's sloppy and/or reckless work is causing problems needs to be pulled aside 1:1 and told that they need to improve. Even the best systems and processes aren't enough to make up for reckless indifference among the team.
Of course many managers are weasels who don't like doing hard stuff and would rather not confront an individual but instead compensate by piling a bunch of additional bureaucracy on the entire team.
mr_bag@reddit
Huh, I'd always assumed "blameless postmortem" was more just skipping the assigning "blame" part, rather than actively trying not to name the people who were part of it.
We all mess up sometimes and a culture where people aren't afraid to put there hands up and call out when they realised they have, feels far healthier than attempting to pretend we don't all know who did what? Ultimately the goal is just understand why and figure out how to stop it happening again, sometimes that's just a PSA to be aware of x, sometimes its an extra test/step in our qa/review/process or whatever else.
Granted, I've only ever really run this within the team, as beyond it it's all my responsibly effectively anyway so specifics aren't helpful.
ezaquarii_com@reddit
Blameless postmortems are a way to improve institutional resiliency and gain more understanding.
If the company is not doing it, you are going to eat 💩 sooner or later anyway.
The company will eat dust sooner or later.
Sinusaur@reddit
I blame the lack of a process, then propose a process that could improve future outcomes.
Nqn73@reddit
Taking ownership of our own mistakes is the correct thing to do. Taking ownership of other people's fuckups will eventually paint a target in your back as the person who fucks things up! So please don't do it. Let git show who fuck things up; isn't that what “blame” is for? 😉
Xaxathylox@reddit
If you are more concerned about business process succes than you are self-development, then perhaps accepting blame is not helping to achieve that goal because doing so may deprive the real offender from a piece of the feedback loop.
On the other hand, if you are primarily looking out for yourself, then maybe being a martyr helps you develop further.
In this model, it is a continuum and you will fall somewhere between two extremes.
What role do YOU want to play?
Duffy13@reddit
I come from a mentality where “blame” is either “I” or “we” based, I rarely if ever will specifically point blame at anyone unless it’s malicious or a compliance problem. For everything else who is at fault doesn’t really matter, what matters is that you identify the problem, fix it, and put in policy/plans to prevent or mitigate it going forward.
henryeaterofpies@reddit
I cam pretty close for not narcing on a team member who was unhappy and I told my director we would lose good developers if things didn't change.
Their response was 'which ones' and when i told them I wasn't going to say they threatened me with a writeup. Thankfully i had the clout/pull to tell them to shove it then they ended up losing 3 of us to the same competitor a month later.
thodgson@reddit
There is a difference between blame and responsibility. Taking blame is not the same as taking responsibility. You are doing the latter which may look good in the short-term but can accumulate and tarnish your overall reputation. You need to take that into consideration.
ReservoirBaws@reddit
Well, I didn’t get fired, but I got rolled off a project and screwed out of a promotion because of it. I was a consultant, and I was tasked to work with another dev at the client. I constantly covered his mistakes, and didn’t bring up that they kept ignoring my emails. It turns out, they’d been complaining about me behind closed doors to make themselves look better.
It’s fine to not want to throw others under the bus, but it doesn’t always come without consequences unfortunately. If you’re in a competitive work culture, covering for people can absolutely bite you in the ass - not arguing for you to start leaving people out to dry, but just be aware of what can happen.
KosherBakon@reddit
I used this phrase for over a decade in tech: a system will never self-correct if the parties creating issues aren't held responsible for those issues. It's not casting blame to answer someone's question with a factual answer.
You don't have to say "Sally is a moron", but it's 100% acceptable to say "the latest changes to this config file caused the error, and those changes didn't go through PR review. We should ensure all changes go through PRs going forward."
My wife struggled with this for a bit. Here is what I told her:
Throwing yourself under the bus to take ownership for an issue you didn't create is stupid.
She had a colleague who didn't care much about the quality of his work. He went on vacation for a couple weeks and al of his shit broke. She talked to her boss and said "These issues are things I could look into, but they are concerns I've brought up with him already. If you're open to it, I'd like to leave these things for him to fix when he returns."
The manager agreed. She filed a dozen tickets waiting for him when he got back.
I encourage you to always look at how to improve and what you can learn from every situation. But taking blame for something you didn't do is lying. Don't do that.
FragileIdeals@reddit
Yes. We gave realistic estimates for a project and they wanted it done in 1/4 the time. We showed great progress and gave a demo(and honestly probably would've finished way ahead of time) but we weren't meeting their deadline that they set for us that we communicated couldn't be met. My manager absolutely blew up at us one meeting like full on screaming at us. After that my team was then brought in one by one for us to take responsibility for the "fuck up". I had seen it before many times in the company where they would pin blame down on the lower level employees and refused to take blame or place blame on my team members. I was put on a PiP a week later and gave my 2 weeks 10 days after that, the rest of my team left in the following months.
JoeBidensLongFart@reddit
You were nice to even give a 2 week notice in that situation. I'd have said nothing until I was ready to leave and then just left.
FragileIdeals@reddit
In hindsight yeah they probably didn't deserve any notice
Gloomy_Freedom_5481@reddit
screaming is crazy really. like u're not my dad. you dont get to raise your voice to me
FragileIdeals@reddit
Yeah this really threw me off guard, he was someone I had a decent relationship with too. It was his first management gig so I don't think he knew how to handle a difficult situation and was under a lot of pressure from higher up.
Fluid_Frosting_8950@reddit
We have at least 1 hour of blaming sessions per days, It doesn´t happen in your jobs guys?
JoeBidensLongFart@reddit
I hope you spend the other 7 hours meticulously documenting your work and doing CYA every chance you get.
HoratioWobble@reddit
I see pointing the finger in the same light as "an eye for an eye leaves everyone blind" I think it's important to take ownership, but a company who encourage people to blame others for their mistakes just ends up creating a toxic culture that reduces output because people are afraid of losing their job.
No one is to blame, the ownership should be on the whole team and the resolution should be a team effort thats the only way mistakes don't happen in the future and people feel safe owning up to their fuck ups
iceyone444@reddit
More than once and I've seen it happen to others - I try to say "lets figure out why it happened, who did it isn't importnt - is it a process, system or other issue?"
I was fired from a company without warning after 2 months - the project was failing and my manager needed a scape goat.
I had evidence etc but could not be bothered as it was a toxic environment.
He got fired 12 months later anyway.
JoeBidensLongFart@reddit
That happens sometimes. It happened to me early in my career when I was hired as a contractor. They needed someone who would either be the savior of the entire project or the scapegoat. I was too naive at the time to see the numerous red flags in advance (waterfall process with no business interaction, no meaningful QA process, previous dev teams had failed with the same project, manager disengaged until it came time to blame someone).
Sometimes all you can do is recognize a bad situation and bail before you get bit.
willcodefordonuts@reddit
If every time there’s a problem you’re looking for reasons to make it your fault then you’re going to be seen as that guy who causes problems - or that guy who won’t address them properly.
I’m a manager. If someone on my team fucks up I want to know about it, I don’t want someone saying “oh if I had written this block of code differently they wouldn’t have made the mistake so it’s my fault” that hides the issue. I can’t solve issues people are hiding.
The real problem here should be why was broken code deployed. Why didn’t QA catch it. Why didn’t automated tests catch it. We need to discuss those things to put process or improvements in place to fix the issue.
You don’t have to block for people. They need to learn to own their mistakes.
arcticmaxi@reddit
This is the way
Covering for people does not have the effect people think it has
FragrantFire@reddit
And what do you do with that info? If someone contributes 10x as much as another person, they will also make mistakes 10x as much. Mistakes are not a way to judge people’s performance.
When mistakes are made, it’s important to identify root cause and make sure they don’t reoccur. But that’s not by assigning blame.
willcodefordonuts@reddit
Most mistakes don’t make it into production unless there’s a breakdown in process.
So if I know who made the mistake I can discuss that with them / the team, and find out why / how the mistake was made and find out what process can be put in place to prevent it.
At no point did I talk about blame. I said people need to own their mistakes which they aren’t doing because they let OP make it their issue.
Stubbby@reddit
Asking people to evaluate coworkers is the best way to eliminate the great ones and achieve a cesspool.
Also, stacking individuals in a team is the best way to make a toxic workplace.
JoeBidensLongFart@reddit
Yup, this exactly. People will not be genuinely helpful or collaborative with teammates knowing that it could easily work against them, if their advice enabled another teammate to be ranked higher than them.
Obsidian743@reddit
This makes you a good leader. A servant leader.
It comes with the territory that you shield your teammates from crap. Which sometimes means you're the one who gets the brunt of the force. Sometimes that means losing your job, etc.
I try to find ways to talk about problems generally without assigning specific blame and hope that management picks up on it.
ThigleBeagleMingle@reddit
https://sre.google/sre-book/postmortem-culture/
rballonline@reddit
I liked my job too. We got a new team integrated on our project and everything started to become the blame game from their side. The project manager fed into it, and I just kept letting them know that things were working fine from my end. Found out that all of the new people were blaming our side even though it was always them. I felt like the job became just defending myself daily and the job wasn't fun anymore.
I'm the type of person that is like "oh there's a problem? How do we fix it?" And they were "oh there's a problem. That's because Bob and Fred did x, y and z. Sally doesn't do x either." Then have a meeting to figure out who's to blame and meanwhile I've already solved the issue.
Did the typical search for another job while working. Kept hoping it would get better but found a new place to go to and two years later I'm really liking this job, no more weird blame game stuff.
It was crazy, before that team came in I was a rock star. When I left I felt like no one cared even though I did most of the work. Whatever, the new position was super excited to have me, and still is. Sometimes it just doesn't seem to work out I guess.
CountryBoyDeveloper@reddit
No, but at the same time I am not loyal to a single co-worker. I have bills to pay and would not risk my job for someone to think I was “cool”
thecodingart@reddit
I’ve witnessed a coworker dig their own grave admitting to messing up, consistently, without properly fixing things.
They were overly emotional, over transparent and generally weren’t good at their job … sooo yeah.
You shouldn’t have to worry if you dont hit those checkmarks unless someone is building a case against you.
needed_an_account@reddit
Do you also spread the wins among the team even if you're directly responsible for them?
_lumb3rj4ck_@reddit
I wish more people were like you, friend. If more people had even an ounce of your self respect and personal accountability the world would be a very different place.
dashingThroughSnow12@reddit
This is an alright philosophy to have. (Depending on the details.)
As an example of this philosophy, I believe an intern or junior developer can never cause an outage. If an outage can be traced back to them, then something else is responsible. Did we not review the code properly? Do developers have too much access? Do we have too little docs?
This philosophy of how we can improve things to prevent mistakes is fine to a point.
unstableHarmony@reddit
Do you exhibit this behavior outside of work? Do you routinely apologize for bad things that happen, even if it's minor and you would've had to move heaven and earth to prevent the issue from occurring?
There's not enough information here but it sounds like you're sabotaging yourself. Maybe you think subconsciously that you're not worthy for some reason, or that you need to feel the consequences for some imagined wrongdoing.
If that's the case, take heart. Your coworkers seem to recognize your work ethic, so it's time to start focusing on the good things you're doing. Start keeping track of all of your work wins, big and small. Build a resume for yourself of any notable changes you've made to the system, from bug fixes to major releases. Don't rely on memory for this. Write it down and keep it updated. It'll be useful for any performance reviews as well as resumes and cover letters you may send out in the future. Most importantly, it'll remind you that you're better than you think you are.
I won't tell you to stop the negative thoughts, but I will tell you that you need to introduce positive threads into your thought processes so you can rethink this need to beat yourself up and bear a cross of imagined sins.
If the above doesn't apply to you, others have provided plenty of advice regarding processes that should help you if you want that.
GoTheFuckToBed@reddit
You are probably took on this role because no body else in the company prevents incidents. There is a process and quality issue that is not getting addresses.
One way to solve it is talk up with the team that you have an eye to spot incidents and offer to do 10% time for disaster prevention QA before releases.
Notsodutchy@reddit
A lot of positive comments about blameless postmortems here.
But I think a blameless culture can be as toxic as a blameful one.
Working somewhere where there is no accountability, no responsibility, no authority to make a decision, consensus required at all times is not universally wonderful.
If you want to have authority and autonomy to make decisions as a professional individual, then there needs to be a proportional degree of accountability. Aka “blame”.
edgmnt_net@reddit
Blame decisions or reasoning instead of people. Or frame it as a possible future improvement instead of a past screw-up.
Reinheardt@reddit
If you’re willing to take blame, others will oblige you.
Saki-Sun@reddit
When I am wrong I'll wear it and tell everyone I fucked up. Because it's so good damn rare.
syklemil@reddit
Yeah, being able to say "I don't know" or "I was wrong about …" is a good trait.
But at the same time, being too willing to take the blame will leave someone open to exploitation, and it may even undermine the intent of blameless postmortems. Human psychology, especially group psychology, isn't as good as we might want it to be, and it's worth being careful about assigning or taking blame.
oldmaninnyc@reddit
I can say with absolute certainty that one of the largest items holding me back at various earlier stages of my career was not taking credit for my work in various ways.
xabrol@reddit
People fuck up. People fucking up shouldnt matter aa much as how often they fuck up.
I really dislike it if somebody eats crap because of my fuck up and nobody ever tells me I fucked up. I don't want to live under the delusion that everything I do is correct. I appreciate feedback even if it's negative and I thrive transparency.
How am I supposed to get better if I have a co-worker that fixes all my crap and doesn't tell me?
Particular_Camel_631@reddit
Yes. I refused to throw a subordinate under the bus following a gdpr breach. It was a systemic deta integrity failure, and not specifically his fault.
Senior management wanted someone to blame, so blamed me. Couldn’t make it stick so made my role redundant.
Still hate them. Even though I now have a much better job.
allKindsOfDevStuff@reddit
Accountability and self-awareness are great, but don’t needlessly put a target on yourself and make yourself a martyr. No one else there will do the same for you
Sneaky_Tangerine@reddit
Some really great answers here around blameless postmortems and a focus on the systemic causes of incidents; both approaches I agree with. As to
check out the concept of Extreme Ownership which is basically what you are practicing here. If you're already wired this way then it might help to learn about the nuances of EO so you're not just falling on your sword all the time but contributing to a culture of ownership of problems and their solutions.
ithunk@reddit
I’ve seen it play both ways. At a startup, one time we were doing a large deployment (waterfall method). Something was screwed up and the devops guy got fired the next day. I don’t think that was the right thing to do, but our CEO was impulsive like that. In another small company, I was a manager and someone on my team fucked up. My manager, the COO, wanted to fire him. I had to get him off the ledge and let me put him on a PIP instead. Eventually, the CTO removed me from the managerial position because I wasn’t doing his dirty work (I’m west coast mentality and he is boomer east coast), and then he fired that guy for a small technicality like badging in later than the time he put on his timesheet.
In other large companies, messing up and confessing is encouraged. Run fast and fail often. Blameless development teams. I’ve seen devs release code, find the issue in prod, raise a sev 1, etc, and there is a proper process for fixing and later doing a retrospective on what could have been done better. Nobody gets fired. If your systems can be brought down by a single dev, the fault is on the system and not the dev.
fllr@reddit
Just be realistic with your involvement. Even the most thorough of people are not omniscient. You can’t be everywhere, you can’t know everything.
Before speaking up, just ask yourself: “what was my real involvement in this project?” If it was low, just don’t say anything. If people reach out, say “i don’t currently know, but i can investigate and get back to you”
ventilazer@reddit
Write tests.
TheOnceAndFutureDoug@reddit
I mean, are you taking blame so you can say what you did wrong and help avoid someone else making the same mistake in the future or are you looking to put yourself up on a cross?
The reason we advocate for blame-free cultures in dev isn't because no one is ever to blame. Someone is always to blame. Or multiple people. But someone could go up on that cross if we really wanted to but what would be the point? Mistakes happen and if the mistake is bad enough that we're having a meeting about it there's a good chance an improvement to process, training, infrastructure or all of the above would have mitigated the damage or eliminated it entirely.
The only time it's worth blaming someone to the point that there's a punishment is when that's not true. When there was process and they ignored it. When they'd been trained and they did it anyway. When the infrastructure had protections and they walked right through them.
Malicious intent and arrogant ignorance are why punish people. Not honest mistakes.
So by all means when it comes time to do the 5-why's on the P0 put your hand up and say, "I'm the one who started it and here's what I did," so we can add it to the timeline but don't be surprised if we add a few things before that and plenty of things afterwards.
Otherwise, as my good cousin Wayne used to say, get off the cross we need the wood.
Well, pitter-patter.
Raaagh@reddit
I just try and be effective, kind and truthful when it helps the team/org/company.
Life is simple and consistent that way.
RogueStargun@reddit
When you get to the point where you're blaming individuals for problems, it's really indicative of systematic failures.
I made the mistake of falling into this trap and blaming one of my lower level coworkers once. The reality is (and deep down inside I knew this), the problem was actually with how we ran our process.
The team had adopted a culture of simply approving code willy nilly, and I myself had actually encouraged this practice due to a tight upcoming deadline "to maintain velocity".
Generally, at a certain high level, the entire team is what is ultimately graded by a company. A not-so-great software engineer who is getting their code into `main` and breaking things is a sign that the team is not healthy. A bad programmer can in most cases be coaxed to be a good one through more comprehensive code review and carefully managed siloing/quarantining.
Rather than cast yourself in the firing line, perhaps you can orient the discussion towards how process can be changed?
Daveypesq@reddit
There’s no need to take the blame but there’s also no need to throw anyone else under the bus.
“A change coincided with mine that unexpectedly caused x upstream/downstream”
Can always use this time to highlight the need for better integration/e2e testing as part of a pipeline.
Saw someone else mention them but blameless postmortems are a really useful tool. X happened, what can we do as a team to stop x happening again.
Jarwain@reddit
Idk I've always felt that with any situation, blame never falls solely on one person. There's always some level of fault that lies with me, some with others, typically those in leadership, the system, etc.
Blameless postmortems are quite helpful from a systems/process perspective
Buuut it doesn't sound like that's exactly what you're talking about. It sounds like it's just you in your mind seeing the ways that it's your fault, the ways you could have done things differently to prevent the issue.
This wouldn't necessarily cost you the job. It depends on the people around you. If you deliver good work most of the time, most people won't care. Could even see this as you Taking Ownership, which is generally considered a Good Thing.
I wouldn't stress too much about it. It's a useful skill. The biggest thing, I think, is to focus how you communicate it as a failure in process, and to outline how to improve the process so that neither you nor anyone else can make the same mistake