Latest / The Tech Career Podcast with Fexingo: Engineering Jobs, Interviews, and FAANG Career Strategy / How FAANG Engineers Use Code Freezes to Ship Faster
Transcript
- Lucas: You know that moment, two days before a major release, when someone on your team says, 'actually, let me just squeeze in one more fix'? And you feel the pit in your stomach because you know that fix is going to break something else. Luna: Oh, I've been that person. You think you're being heroic, and then the release train derails. Lucas: Exactly. And that's why one of the most surprisingly effective productivity tools in big tech is the opposite of what you'd expect: it's the code freeze. The deliberate, sometimes painful, decision to stop all non-critical changes for a period. Luna: It sounds counterintuitive. You're saying to ship faster, you stop shipping? I want to unpack that. Lucas: Let's start with a concrete example. Back in 2019, Google Cloud had a major incident during a routine release. A small change — something that looked perfectly safe in code review — ended up taking down a chunk of their infrastructure. After that, Google got much more serious about what they call 'release freeze' periods. They basically said: no code changes except for the release itself, and only if it's a security or data-loss bug. Luna: So the freeze is there to protect the stability of what's about to go out. You're not slowing down — you're putting a fence around the final mile. Lucas: Right. And there are different flavors. A hard freeze means absolutely nothing goes in — not even documentation changes. A soft freeze might allow low-risk changes like config updates or comments, but no logic changes. Most FAANG teams I've worked with use a soft freeze for the first few days of a release cycle, then a hard freeze in the final 24 to 48 hours. Luna: But I imagine a lot of engineers push back. 'My change is safe, it's just a one-liner.' How do you handle that? Lucas: The data actually shows that last-minute changes are disproportionately likely to cause incidents. There's a well-known study from Microsoft Research that looked at thousands of releases and found that changes submitted within 48 hours of a release were something like three times more likely to introduce a regression than changes submitted earlier. So the freeze isn't a bureaucratic hurdle — it's evidence-based risk management. Luna: That's a strong stat. And I think it helps to reframe the freeze not as a policy but as a tool for focus. When you know no new code can land, you can actually concentrate on stabilizing what you have. Lucas: Exactly. And that's where individual engineers can take initiative even if their team doesn't have a formal freeze. You can declare a personal freeze for yourself. Say, 'For the next three days, I'm not going to start any new feature work. I'm only going to test, review, and fix bugs on the release branch.' I've seen engineers do that and then become the hero of the release because they caught issues early. Luna: I like that. It's a way to model the behavior without needing permission. But let's talk about the flip side — what happens when a freeze goes wrong? I remember a story from a friend at a well-known social media company where a two-week freeze actually delayed a critical security fix because the process for exceptions was too slow. Lucas: That's a real risk. Freezes have to be flexible enough to handle emergencies. The key is to have a clear, fast exception process. Usually, that means an on-call release manager who can approve an exception in minutes, not hours. And the exception should be logged and reviewed later so you can improve the next freeze. Luna: So the freeze itself isn't the goal — it's about intentionality. You're saying: we're going to be deliberate about what changes when, so that the release is predictable. Lucas: Exactly. And that intentionality is really what this episode is about. Look, a lot of listeners might be at companies that don't do formal freezes, or they're at startups where every commit feels urgent. But the principle still applies: you can create a personal or team-based 'freeze mindset' around any deadline — a demo, a conference, a quarterly review. Just say, 'From now until the event, I'm only touching critical bugs.' Luna: Yeah, and I think that also helps with the psychological side. When you have a freeze, you're giving yourself permission to stop chasing the next shiny feature. There's a relief in that. Lucas: Absolutely. And on that note, if today's conversation gave you something usable — maybe one idea to try in your next release cycle — we'll put a link where you can support the show. We deliberately keep this podcast ad-free because we believe the content should stand on its own. If that matters to you, the link is buy me a coffee dot com slash fexingo. No pressure, just an option. Luna: I love that we can keep this clean. And listeners, honestly, even just sharing an episode with a teammate helps a ton. Lucas: So back to freezes. One practical takeaway: if you want to introduce a freeze culture on your team, start small. Propose a 24-hour soft freeze before your next release. Explain why — cite that Microsoft stat if you need to. Most people will agree to a trial run. Luna: And what do you do during that 24 hours? Just wait? Lucas: No, that's the misconception. During a freeze, you're more active than ever. You're running regression tests, doing manual exploratory testing, checking logs for anomalies, reviewing the release notes. It's not downtime — it's focused stabilization work. Luna: Okay, so let's zoom out. How do freezes fit into the bigger picture of deployment velocity? Some teams claim they deploy hundreds of times a day without any freeze. Lucas: Those teams usually rely on feature flags and canary deployments. They don't need a freeze because they can turn off a bad change instantly. But most teams — even within FAANG — still have some release cycles where a freeze makes sense. For example, when you're cutting a major version of a mobile app that has to go through app store review. You can't roll back a submitted binary easily. Luna: That's a good point. The freeze is really about managing the risk of irreversible decisions. In that case, it's a no-brainer. Lucas: Right. And there's also the social signal: when leadership declares a freeze, it tells the whole org, 'This release is important enough that we're all pausing to get it right.' That can be really motivating. Luna: But it can also be demotivating if it feels like a lack of trust. If engineers feel like they're being handcuffed, they might check out mentally. Lucas: That's why communication matters. Instead of saying 'no changes allowed,' frame it as 'help us protect this release.' And involve engineers in defining the exception criteria. When people feel ownership, they buy in. Luna: So what's your rule of thumb? When should a team consider a formal freeze? Lucas: If you've had more than one release in the past quarter that was delayed by a last-minute change causing a rollback, you probably need a freeze. Also, if your release process is stressful — people dreading the day — a freeze can actually reduce anxiety because everyone knows the rules. Luna: That's a good heuristic. And I think the freeze is also a forcing function for better planning. If you know you have a freeze coming, you'll be more disciplined about getting your code in earlier. Lucas: Exactly. It creates a natural deadline for feature work. And that's why some teams use a 'code cutoff' instead of a freeze — same idea, but less scary language. They say, 'Feature work must be merged by Tuesday noon. After that, only bug fixes.' Luna: I like that. It's still a freeze, but it sounds more like a planning milestone. Language matters. Lucas: Totally. And one more thing: don't forget to celebrate the end of the freeze. When the release goes out, have a brief retrospective. What did the freeze help us catch? What was annoying about it? That feedback loop makes the next freeze better. Luna: So it's not just a tactic — it's a practice that improves over time. That's a great note to end on. Lucas: Yeah. And maybe the next time you feel that urge to sneak in one more commit before a release, you'll think about the freeze. Sometimes the most productive thing you can do is stop.