The first version of this note organized Boris Cherny’s patterns by career stage — useful if you want to know what to focus on at your level. This version is different. It arranges the same 16 patterns as a causal chain, where each one enables the next. The point isn’t “do these things.” It’s “these things are connected, and doing them out of order is why they don’t work.”
The Chain
1. Always Start with Code
Everything begins here. Not because coding is the most important skill, but because it’s the only reliable way to discover problems. Senior ICs who stop coding lose intuition for their codebase. They start making decisions based on what they remember, not what’s true now.
Boris shipped 868 diffs in 2023 — his most productive year — as an E7 going to E8. Not because senior engineers should be measured by diff count, but because every important thing he did that year started with something he noticed while writing code.
What this enables: If you’re not coding, you can’t see the problems that matter. And if you can’t see them, the next five patterns are impossible.
2. Outsider’s Advantage
When you join a new team, you briefly see problems insiders are blind to. They’ve stopped coding (Pattern 1), they’re habituated to the warts, or they take pride in being productive with broken tools.
Within weeks of joining Instagram, Boris saw that the Python stack was “10x worse than Meta’s Hack stack across pretty much every dimension.” Engineers who’d been there for years didn’t see it. Their comfort with the codebase made it hard to see the forest for the trees.
Why it follows Pattern 1: You can only see what insiders miss if you’re actively writing code in their codebase. If you ramp up by reading docs and attending meetings, you’ll habituate before you notice anything.
The expiration date: By 2021, after 3+ years in Facebook Groups, Boris’s own outsider advantage had faded. His diff count dropped, he was in consulting mode. Use it before you lose it.
3. Prove the Problem Before Proposing a Solution
You’ve seen a problem no one else sees. Now what? If you jump to a solution, you’ll get resistance — “it’s always been this way,” “it’s not that bad,” “we have bigger priorities.”
Boris didn’t propose IGWWW. He first built consensus that the status quo was broken:
- Quantitative: Pulled Phabricator and HR data on which stacks engineers actually use
- Qualitative: Interviewed 40 top ICs one-on-one about their pain points
- Broad survey: Confirmed the findings weren’t biased by his sample
Only after all three pointed the same direction did he start discussing solutions. When he presented the data, senior engineers were surprised — they didn’t realize how much the stack had deteriorated.
Why it follows Pattern 2: The outsider advantage gives you the sight. This pattern gives you the proof. Sight without proof is just complaining. Proof without sight means you’re proving someone else’s problem, not yours.
4. Follow Latent Demand
You’ve proven the problem exists. But what should you build? Not what you think users need — what they’re already doing.
- Facebook Marketplace: 40% of Groups posts were buying and selling
- Facebook Dating: 60% of profile views were opposite-gender non-friends
- GroupSync (failure): tried to create behavior users weren’t already doing
“You can never get people to do something they do not yet do. You can find the intent they have and steer it to let them better capitalize on that intent.”
Why it follows Pattern 3: Proving the problem tells you something is broken. Latent demand tells you what to build instead. Without Pattern 3, you don’t know where to look. Without Pattern 4, you build the wrong thing.
5. Scrappy MVPs with Hypothesis-Driven Iteration
You know the problem, you’ve found the demand. Now validate fast.
Chats in Groups: 3 engineers, no PM, no designer, no UXR, no DS. Designs in Sketch. Guerilla usability testing with cafeteria workers. Funnel logging for days-fast feedback instead of weeks-long Deltoid waits. Half a dozen experiments shipped per week. 1 million Meaningful People in months.
Communities as the New Organizations: pitch deck, Zuck review, 120 headcount, then went looking for a problem. Almost every workstream canceled.
Why it follows Pattern 4: Latent demand gives you the hypothesis. Scrappy MVPs test it. If you skip Pattern 4, you’re iterating on the wrong thing — fast iteration on the wrong idea just gets you to failure faster.
6. Build Product and Infra in Parallel
Your MVP is working. Now you need to scale it. The mistake is to stop and “build proper infrastructure first.” The right move is to build both at the same time.
Instagram Profile took 8 seconds to load. Boris didn’t build a GraphQL framework first and find adopters later. He fixed Profile performance (product) while writing a custom GraphQL executor (infra) simultaneously. The A/B test showed -42% latency. Today that executor processes a quarter of Instagram’s CPU.
Why it follows Pattern 5: The MVP shows the product works. Building infra in parallel means the infra solves real problems you’re hitting right now, not hypothetical problems you imagine. The product keeps the infra honest.
7. Get Ahead of Platform Shifts
Your product-infra combo is working. But you’re building on someone else’s platform. When that platform changes, you have a choice: wait and adapt, or get there first and shape it.
Boris heard about Comet and immediately pushed Groups to be the next surface on it. His technical conventions — Actor Framework, oncall enforcement, $key suffix for Relay fragments, CanViewerDo for GraphQL — became the defaults for the entire platform. They’re still in the code today.
Why it follows Pattern 6: If you’ve been building product and infra in parallel (Pattern 6), you already have the technical depth to make good decisions on a new platform. If you haven’t, you’ll be the person following conventions, not setting them.
The principle: Platform shifts create a power vacuum. The first people to write code define the rules everyone else follows.
8. Do What PMs Aren’t Doing
You’ve built things, you understand the platform, you have technical credibility. Now look around: what product opportunities exist that no one is driving?
Meta has a low PM-to-engineer ratio. Boris spotted Groups SEO when his PM Hasan was stretched too thin. Boris did the opportunity sizing, wrote the pitch deck, convinced the director, and catalyzed the Meta SEO team in Tel Aviv.
Why it follows Pattern 7: By this point you have the technical depth, the platform knowledge, and the credibility to spot and own product opportunities. Without those, “doing PM work” is just scope creep.
9. Side Hustles Build Networks and Influence
Your main work creates direct impact. Side hustles create the network that makes future impact possible.
Boris biked between MPK buildings for a month doing 30-40 Undux tech talks. He started the world’s largest TypeScript meetup and wrote O’Reilly’s first TypeScript book. These weren’t distractions — they connected him to the React team, Flow team, DevInfra, Joe Pamer. Every one of those relationships paid off when he needed cross-org support for IGWWW years later.
Why it follows Pattern 8: Side hustles are most valuable when you already have a main project with traction (Pattern 5-7). They extend your reach beyond your immediate team. Without a strong main project, side hustles look unfocused.
10. Present Three Options (Anchor to the Middle)
You have the network, the credibility, the track record. Now you need resources. Learn to pitch.
When pitching Groups on Comet to VP Jenn Dulski, Boris asked for “6-14 engineers depending on how fast we want to get it done.” Jenn picked the middle option. For SEO: PM director first, then Fidji Simo. Three options, escalating audiences.
The rule: 80% of the time they pick the middle one. Make the middle one what you actually want.
Why it follows Pattern 9: Pitching is about credibility as much as content. The network you built (Pattern 9) determines who will take your meeting, and whether they trust your numbers.
11. Delegate What You Love, Not What You Hate
Your impact is growing. You’re generating more ideas than you can execute. You must delegate — but how?
Boris delegated work he understood deeply: Bloks migration, lint rules, large test objects. Because he knew the domain, he could monitor quality and course-correct. The engineers he delegated to got full execution credit and many went on to spin out their own projects.
From Andy Grove: “You always delegate the thing you do want to do and that you know well because then you can monitor the progress.”
Why it follows Pattern 10: You’ve secured resources (Pattern 10). Now you need to deploy them wisely. Delegating what you love means you stay connected to the quality of execution. Delegating what you hate means you can’t tell if it’s going well.
12. Step Back to Let Others Grow
Delegation (Pattern 11) is giving someone a task. Stepping back is giving someone the space to redefine the task.
After recruiting Jake Bolam to TL IGWWW, Boris noticed: “The more I stepped back, the better Jake’s work got.” Jake used a completely different approach — formal teams, conferences, investing in dev tools first — that was better suited for scale than Boris’s volunteer model.
Why it follows Pattern 11: First you learn to delegate tasks well (Pattern 11). Then you learn to delegate direction. The second is harder because it requires letting go of your approach, not just your time.
13. Street Cred Before Mentorship
Eventually you’ll change teams, orgs, or companies. Everything resets.
Boris asked Tim and Yoshi about their growth plans in his first Instagram conversations. Blank stares. A year later, an E8 asked Boris the same questions and his reaction was: “Who is this person to ask me that?”
Why it follows Pattern 12: Patterns 11-12 teach you to lead through others. Pattern 13 reminds you that this only works after you’ve earned trust through code. Leadership techniques without street cred are just noise.
14. Know When to Say No
This is the hardest pattern, and it only works if you’ve internalized everything before it.
Lightweight Groups v2: Boris knew from day one they should simplify existing Groups, not build a new product. But leadership wanted it, so he executed. A year later, the project was killed. “I probably would not have taken on the project.”
The distinction: GroupSync failed because of skipped homework (Pattern 3). LG v2 failed because he went against better judgment. The latter is more damaging.
Why it’s near the end: Saying no requires the judgment to know which projects matter (Patterns 3-4), the credibility to push back (Patterns 7-9), and the self-awareness to separate your ego from the work (Patterns 11-12). Without those, “saying no” is just not doing your job.
15. Admit Mistakes, Correct Fast
You said yes (or no), and you were wrong. Now what?
Boris debated with Bob Baldwin about splitting the membership data model. Boris lost the debate. A year later, 99% of callsites used the two assocs identically. Boris proactively reversed his own decision — a painful six-month migration, but the right call.
Eric Schmidt’s framework: First decide if the decision is reversible. If yes (99% of cases), speed matters more than correctness. Decide fast, correct later.
Why it follows Pattern 14: Saying no (Pattern 14) means you’ll sometimes be wrong. This pattern is the safety net. The faster you admit and correct, the less damage from a wrong call.
16. Build for the Model Six Months From Now
The final pattern. It’s not about AI — it’s about building for a future you can see but can’t prove yet.
At Anthropic, Boris’s manager Ben Mann pushed: “Don’t build for the model of today, build for the model six months from now.” Claude Code was mediocre for months — about 10% of Boris’s coding. Then Sonnet/Opus 4 dropped and usage exploded, because the product was already ready.
Competitors who optimized for current capabilities had to rebuild. Boris’s bet on the agentic paradigm was a bet on future models.
Why it’s last: This pattern requires all the others. You need the technical intuition to see what’s coming (Pattern 1), the conviction to bet on it before the data exists (Pattern 14), and the willingness to look wrong for months (Pattern 15). It’s the ultimate expression of the chain: see → prove → build → scale → judge → leap.
The Chain, Compressed
See the problem → 1. Code → 2. Outsider's Eye → 3. Prove It
Find the solution → 4. Latent Demand → 5. Scrappy MVP → 6. Product + Infra
Scale the impact → 7. Platform Shifts → 8. PM Gaps → 9. Side Hustles → 10. Pitch
Multiply yourself → 11. Delegate → 12. Step Back → 13. Re-earn Trust
Master judgment → 14. Say No → 15. Correct Fast → 16. Build for the FutureEach row is a phase. Each pattern enables the next. Doing them out of order is why smart people struggle: they try to pitch without credibility (10 before 9), delegate without understanding (11 before 6), or say no without judgment (14 before 3).
The chain is the system. The patterns are just the parts.
Source: Boris Cherny’s two Workplace career posts (~30,000 words combined) and the Ryan Peterman podcast interview (April 2026).