Latest / The Tech Career Podcast with Fexingo: Engineering Jobs, Interviews, and FAANG Career Strategy / How FAANG Engineers Handle Being Wrong at Work
Transcript
- Lucas: You have been at a FAANG company for two years. Your code has been solid. Then one Tuesday afternoon you run a command that accidentally deletes a production database snapshot. The on-call phone starts ringing. Your manager asks for a post-mortem. Today we are talking about what happens next, because almost nobody prepares you for the moment you are wrong at work. Luna: And I think a lot of listeners assume 'being wrong' means a bug in code. But the really career-shaping mistakes are usually operational or architectural. Lucas: Exactly. There is a famous internal story from Google Cloud a few years back where a senior engineer misconfigured a firewall rule and accidentally exposed two million dollars' worth of compute credits to the public internet for about 47 minutes. The engineer was not fired. He was not even put on a performance improvement plan. He wrote the post-mortem, presented it at the weekly engineering all-hands, and stayed on the same team for three more years. Luna: Wait, that is actually a big deal. Two million dollars. Most people would assume that is a firing offense at any company. Lucas: Right, and that assumption is why this topic matters. The reality at most FAANGs is that one expensive mistake will not end your career if you handle the aftermath correctly. The thing that kills careers is not the mistake itself, it is hiding it, deflecting blame, or failing to show you learned. Luna: So what is the actual protocol? Walk me through the day after a major incident. Lucas: The first rule is: communicate immediately. Do not try to fix it silently and hope nobody notices. You send a message to the on-call channel, you tag your manager, you say 'I caused this, here is what I know so far, I am working on the fix.' That single act of ownership changes the narrative from 'someone broke production' to 'an engineer is handling it.' Luna: So you are borrowing trust by being transparent upfront. Lucas: Exactly. Then you write the post-mortem. And this is where culture really shows up. At Amazon, they call it a 'Correction of Errors' document. The format is designed to prevent blame. You list the timeline, the root cause, the impact, and the action items. You never write 'so-and-so typed the wrong command.' You write 'the system allowed a single command to delete a production resource without a confirmation step.' Luna: That is a subtle but huge reframe. It moves the failure from the person to the process. Lucas: Yes. And that is the defining feature of a blameless post-mortem culture. Netflix even has a policy called the 'Sunshine Policy' where post-mortems are open to the entire company. Anyone can read them. The idea is that if you hide mistakes, you hide the learning. So the engineer who made the error becomes a kind of case study for everybody else. Luna: I love that in theory. But I have seen teams where the post-mortem says 'blameless' but everyone in the room knows who was responsible. Does the culture actually forgive? Lucas: It depends on the track record. If you are a high-performing engineer who made a one-off error, yes, the culture genuinely forgives. But if you have a pattern of carelessness or if you avoid writing post-mortems, then the trust erodes. The mistake itself is rarely the problem, the pattern is. Luna: So what about the social side? You still have to face your teammates the next day. How do you rebuild that personal trust? Lucas: You own it in person too. You bring it up in stand-up. You say 'I messed up the config on Tuesday, I learned X, I have added a pre-commit hook to prevent it from happening again.' People respect vulnerability when it is paired with action. The worst thing you can do is act like nothing happened. Luna: I have a friend at Meta who accidentally pushed a bad experiment that affected millions of users for about three hours. He said the worst part was not the incident itself, but the week after when people would give him 'the look' in the hallway. Lucas: That is real. And it is why some engineers change teams after a big mistake. Not because they are forced to, but because they feel the social debt is too heavy. But I actually think that is often the wrong move. If you stay, you demonstrate resilience. Your teammates see you learn and recover, and that builds a deeper kind of trust. Luna: But there is a counterpoint: sometimes the mistake reveals a fundamental mismatch between the engineer's skills and the team's risk profile. If you are on a safety-critical team like payments or infrastructure, one error can be a signal that you need different responsibilities. Lucas: That is fair. At Apple, I have heard of engineers being moved from kernel development to higher-level application work after a memory safety issue. It is not a punishment, it is a recognition that the person's strengths are better used elsewhere. The key is that the conversation is honest and the move is framed as a strategic fit, not a demotion. Luna: So what advice would you give to a listener who is in the middle of that awful week after a big mistake? They cannot sleep, they are dreading every meeting. Lucas: Three things. One: write the post-mortem before anyone asks for it. Be the person who drives the learning. Two: schedule a one-on-one with your skip-level manager. Tell them what happened and what you learned. That shows executive awareness. Three: find one system-level change that you can implement in the next week. It could be a new CI check, a runbook improvement, whatever. That tangible artifact proves you have moved from regret to action. Luna: I would add a fourth: forgive yourself. The imposter syndrome spike after a mistake is real. You have to separate the event from your identity. Lucas: That is huge. And honestly, one reason we can have this conversation at all is that this show exists without ads. We are not selling you a course or a service. If today's conversation gave you something usable, and you want to support that kind of independent content, you can find us at buy me a coffee dot com slash fexingo. It is a small gesture that keeps us ad-free and focused on what actually helps engineers. Luna: Yeah, that support makes a real difference. And it means we never have to structure an episode around a sponsor message. Lucas: Exactly. So back to the topic. There is one more thing I want to touch on: how managers should handle an engineer's mistake. Because a lot of the burden falls on them. Luna: Yes, because the manager sets the tone. If they react with anger or blame, the whole team learns to hide errors. Lucas: Right. The best managers I have seen do two things. First, they publicly support the engineer. In the team meeting they say 'this was a systems failure, not a person failure.' Second, they privately ask the engineer 'what do you need to feel safe again?' That question is incredibly powerful because it acknowledges the emotional impact. Luna: I have heard stories of managers who actually took the blame themselves in a higher-level review. Saying 'I should have caught that during design review.' That buys the engineer incredible goodwill. Lucas: That is next-level leadership. But it only works if the manager genuinely missed something. If they are just taking a bullet, it can feel performative. Luna: So what about the long-term career impact? If you make a big mistake early in your FAANG career, does it close doors for promotions? Lucas: Surprisingly, not usually. I have seen data from internal promotion docs at a couple of these companies. Promotion packets rarely mention specific incidents unless they are part of a pattern. What they focus on is impact over time. One costly mistake does not define your trajectory. But if you handle it poorly, that pattern will show up in peer feedback. Luna: So the mistake is not the story. How you respond to the mistake is the story. Lucas: Exactly. And that is actually a liberating thought. It means you can take bigger risks. You can ship faster, push harder, because you know the safety net is not perfection, it is your ability to recover. Luna: I want to come back to the blameless post-mortem idea for a second. Some critics say blameless post-mortems are dishonest because they ignore human error. What do you think? Lucas: I think there is a nuance. Blameless does not mean no accountability. It means you do not assign blame as a conclusion. You still identify the specific actions that led to the incident. But you frame them as 'the engineer did X because the system made it easy to do X.' The accountability comes from fixing the system, not from punishing the person. Luna: That makes sense. And I think the best teams combine blameless process with honest individual conversations. The post-mortem is blameless, but the one-on-one with the engineer might include 'hey, you need to slow down and double-check your commands.' Lucas: Yes. That is the ideal balance. You protect the person publicly and coach them privately. Luna: So for the engineer listening who just made a mistake and is panicking: what is the one thing they should do today? Lucas: Draft the post-mortem. Even if you are not sure of the root cause, start writing the timeline. It will clarify your thinking, and it signals ownership. By tomorrow, you will have a document that makes you look like a leader, not a liability. Luna: And that is how you turn a failure into a career asset. Lucas: Exactly. Because in the end, engineering is not about being right all the time. It is about building systems that survive human fallibility. And that includes you.