Junior engineers fail by not being good enough. Senior engineers fail by being good enough to make consequential mistakes. These are the 7 failure patterns Boris Cherny identified across his E4-to-E8 career at Meta — organized by who’s at fault, and how to avoid each one.
Part 1: Your Own Mistakes
These failures are entirely within your control. They get more sophisticated as you get more senior.
1. Skip Homework
What it looks like: You start building before checking if the idea even makes sense.
The example: GroupSync — Boris’s first project at Meta. The team spent months building bi-directional syncing between Messenger chats and Facebook Groups. After launch, their DS Ida Li showed that because Messenger push notifications have a 10x higher open rate than Facebook, by the time someone saw a synced photo on their Feed, there was a 99% chance they’d already seen it in Messenger. The entire product was redundant. A single data pull before starting would have revealed this.
The antidote — Pattern 3: Prove the Problem Before Proposing a Solution. Pull the data first. Quantitative + qualitative + broad survey, all three pointing the same direction, before you write a single line of code.
2. Cart Before Horse
What it looks like: You secure resources before identifying a real problem to solve. The project starts with headcount, not with a user need.
The example: Communities as the New Organizations — a pitch deck, a Zuck review, and 120 engineers allocated. Then they went looking for problems to solve. Boris scoped custom domains for Groups, embeddable Groups, merging Groups and Pages. Almost every workstream was eventually canceled. The cart (resources) was leading the horse (problem).
The antidote — Pattern 4: Follow Latent Demand. Start with what users are already doing, not with what you could build. Facebook Marketplace worked because 40% of Groups posts were already buy/sell. Communities failed because no one was already using Groups as organizational infrastructure.
3. Scope Inflation
What it looks like: You have a valid problem and a good design vision, but you execute the vision literally instead of incrementally. A simplification project becomes a new product.
The example: Lightweight Groups v2 — the design mock showed a simpler, more modern Groups that felt like a messaging app with channels. Beautiful vision. But instead of simplifying the existing Groups product piece by piece, they built an entirely new product alongside it. This created massive complexity: how do LW Groups and regular Groups coexist? How do you migrate millions of existing Groups? How is this different from Community Messaging?
The antidote — Pattern 5: Scrappy MVPs with Hypothesis-Driven Iteration. Test the core hypothesis with minimal investment. Build on one platform, learn in days not weeks, scrap what doesn’t work. Chats in Groups drove 1M Meaningful People with 3 engineers. LG v2 got 20+ engineers and was killed a year later.
4. Against Better Judgment
What it looks like: You have the judgment, the data, the experience — and you know this project is wrong. But you do it anyway because leadership wants it, because it’s expected of you, or because saying no feels too risky.
The example: Lightweight Groups v2 again — Boris saw the problem from day one. He knew they should simplify existing Groups incrementally, not build a new product. But he focused on “what was expected of him” instead of tackling it directly. A year later, the project was killed. His reflection: “I probably would not have taken on the project.”
Why this is the worst failure: Skip homework is ignorance. Cart before horse is process failure. Scope inflation is execution failure. Against better judgment is integrity failure — you betrayed your own expertise. Boris says this type is more damaging than all the others.
The antidote — Pattern 14: Know When to Say No. Only work on projects whose success trajectory you can meaningfully bend. This requires the credibility to push back (built through Patterns 1-9) and the self-awareness to separate your ego from the opportunity. If the best version of yourself can’t make this project succeed, walk away.
Part 2: Environmental Failures
These failures aren’t entirely your fault. But they’re predictable, and you can defend against them.
5. Org Friction
What it looks like: Your project requires cross-org collaboration, but the two orgs have structurally misaligned goals. The collaboration slowly grinds to a halt.
The example: Chats in Groups — the product had real traction. But it required collaboration between Facebook Groups (goal: DAU and engagement, ship fast, iterate) and Messenger (goal: reliability, performance, simplicity). The cultures clashed on every front: Groups iterated quickly and sometimes regressed Messenger’s reliability. Messenger’s top-line metric (daily message sends) wasn’t moving. Integrity questions that Facebook had answers to were unresolved for Messenger. Despite early success, both orgs gradually lost interest.
The defense — Pattern 3 + Pattern 10: Prove the problem exists for both orgs (not just yours), and pitch with three options that align both orgs’ incentives. Boris’s retrospective fix: “I probably would’ve gone to Zuck and said, if you’re really serious about this, move Messenger into the Facebook org.” If you can’t align goals structurally, no amount of execution will save you.
6. Priority Tsunami
What it looks like: An executive directive redirects the entire org’s attention to something new. Your project, which was working, loses all oxygen — not because it failed, but because something louder arrived.
The example: Chats in Groups again — the product was nearing product-market fit. Then “Zuck asked the team to make Groups bigger.” The entire org pivoted to a massive marketing campaign (~$1B spend), new discovery features, and front-and-center positioning. Chats in Groups couldn’t get resources anymore. The team got less and less attention. The project was eventually sunsetted.
The defense — Pattern 9: Side Hustles Build Networks. A project with one sponsor dies when priorities shift. A project with allies across multiple orgs survives because someone always has a reason to keep it alive. Build your network before you need it. Also: when you see the tsunami coming, decide fast whether to ride it or get out of the way (Pattern 15: Admit Mistakes, Correct Fast). Don’t spend months slowly drowning.
7. Zombie Handoff
What it looks like: Your project’s survival depends on a single sponsor. That person leaves the company. The project dies instantly — not gradually, not after review, just gone.
The example: Oculus Japan — Boris connected with Hermes Pique, a Reality Labs Director, to start a small app localization team in Japan. The idea made it past all approvals. Then Hermes left Meta. No second sponsor, no backup plan, no project.
The defense — Pattern 8: Do What PMs Aren’t Doing + Pattern 9: Side Hustles. Never let your project depend on a single person’s continued employment. Build multiple stakeholders who independently benefit from the project’s success. Boris learned this: IGWWW survived because it had champions across Instagram Engineering, DevInfra, and management — losing any one of them wouldn’t have killed it.
The Progression
Read the two groups together, and a pattern emerges:
Your mistakes get more sophisticated as you get more senior:
E4: Skip homework → "I didn't check"
E5: Cart before horse → "I checked the wrong thing"
E6: Scope inflation → "I checked right but built wrong"
E7: Against better judgment → "I knew it was wrong and did it anyway"Environmental failures get less controllable as your projects get bigger:
Org friction → Predictable, preventable with upfront alignment
Priority tsunami → Predictable, survivable with a broad network
Zombie handoff → Unpredictable, only survivable with redundant sponsorsBoris’s biggest growth from 2017 to 2023: moving from “skip homework” failures to “prove the problem first” successes. The 16 success patterns exist precisely because each one is the antidote to a specific way of failing.
Source: Boris Cherny’s two Workplace career posts (~30,000 words combined) and the Ryan Peterman podcast interview (April 2026).