“Taste is knowing what to fix, what to leave, and what to kill.”
L6 is the great filter. Everything before this — stack fluency, shipping features, coaching builders — can be learned through discipline, practice, and AI mastery. Taste cannot. It requires a specific way of seeing systems: understanding why things are broken, which broken things matter, and which “fixes” would make everything worse.
Most talented builders can reach L5 with enough dedication. Not everyone crosses to L6. Some L5s are L5 forever — and that’s respected, well-compensated, and genuinely valuable to the system. The difference between L5 and L6 isn’t effort or intelligence. It’s the ability to look at a messy codebase, a tangled architecture, a product with 40 feature requests, and know which three things to do and which thirty-seven to ignore.
What the page won’t tell you: The judgment you develop at L6 — reading systems, weighing tradeoffs, making decisions with incomplete information — is the same judgment that powers L8 (Lead Product Owner) and L9 (Principal Product Owner). At those levels, you just stop looking at code and start looking at companies. But the muscle is the same: see the system, find the leverage point, act.
What You Do
- Architecture ownership — refactor, redesign, or defend the current architecture. You make the call on when to rebuild and when to leave it alone.
- Tech debt management — maintain a living inventory of tech debt. Prioritize what to pay down, what to accept, and what to let die with the feature it supports.
- System-level tradeoff decisions — performance vs. speed-to-ship, clean vs. good-enough, build vs. buy. You make these calls daily and own the consequences.
- Feature scoping with business context — you don’t just build what’s asked. You understand why it’s asked, who it serves, and whether it’s worth the cost.
- Code review authority — your review is the final gate. You set the quality bar for the codebase.
- Incident response ownership — when production breaks, you diagnose root cause and decide on the fix. Not the quick patch — the right fix.
- Cross-system impact assessment — before anything ships, you evaluate how it affects the rest of the product. You catch the second-order effects others miss.
AI Skills Required
- AI-powered architecture analysis — use AI to map dependencies, identify coupling, surface refactoring candidates across the codebase
- AI-assisted tech debt scoring — build systems that quantify and prioritize technical debt by business impact, not just code quality
- AI code review augmentation — AI catches the syntax issues so your reviews focus on design, naming, abstractions, and system-level concerns
- AI-driven impact modeling — model how a proposed change propagates through the system before you build it
- AI performance profiling — continuous performance monitoring with AI-generated optimization recommendations
- AI-powered incident analysis — root cause analysis, blast radius assessment, and fix recommendation in minutes, not hours
- Build AI development tooling — create AI-powered workflows that your team uses daily. If your builders aren’t faster because of tools you built, you’re not doing this part.
Self-Evaluation Checklist
- I’ve made an architecture decision that shaped the product for 6+ months — and it held up
- I can look at an unfamiliar codebase and identify the 3 most important things to fix within a day
- I’ve killed a feature or initiative that was already in progress because it was the right call
- My tech debt decisions are respected — the team trusts my judgment on what to pay down and what to leave
- I review code for design and system impact, not just correctness
- I can explain a complex technical tradeoff to a non-technical founder in 2 minutes
- I’ve shipped a refactor that made the team measurably faster without breaking anything in production
- I own 1+ product surfaces end-to-end — from architecture to deployment to monitoring
- I manage 3+ mentees actively and at least one is at L4+
Training Curriculum
Month 1–8: System Thinking
- Architecture Patterns — not textbook patterns. Real-world patterns: when monoliths are right, when microservices are premature, when the “wrong” pattern is the correct choice for this team at this stage.
- Tech Debt Taxonomy — learn to classify debt: deliberate vs. accidental, high-leverage vs. low-leverage, growing vs. stable. Build your scoring framework.
- Codebase Archaeology — practice reading unfamiliar codebases. Identify the load-bearing walls vs. the cosmetic damage. What would you touch? What would you leave?
- Tradeoff Journaling — document every significant tradeoff you make. Revisit quarterly. Were you right? What did you miss?
- Business Context Immersion — spend time with the founder, the users, the data. Your technical decisions must be grounded in business reality.
- AI Architecture Tooling — build your AI-powered analysis stack: dependency mapping, performance profiling, impact modeling.
Month 9–16: Taste Development
- Refactoring Under Pressure — practice refactoring production systems without downtime, without feature freezes, without the team noticing. This is the craft.
- Kill Decisions — practice recommending that features, projects, or approaches be killed. Build the case. Present it. Defend it. This is the hardest skill at L6.
- Cross-System Impact Analysis — for every change, map the blast radius. Practice until second-order effects are the first thing you see.
- Design Review Leadership — lead design reviews for the team. Set the bar for what “good enough” and “not good enough” look like.
- Incident Post-Mortems — lead post-mortems that find root cause, not blame. Build the team’s incident response muscle.
Month 17–24: Ownership Proof
- Architecture Case Study — prepare a detailed case study of an architecture decision you made: context, options, tradeoffs, decision, outcome, and what you’d do differently.
- Tech Debt Portfolio — present your tech debt inventory for the product you own. The panel evaluates your prioritization judgment.
- Mentee Development — your mentees should be demonstrably better builders because of your guidance. Document the evidence.
- Business Fluency — demonstrate that your technical decisions are informed by business metrics, user behavior, and company strategy. Not just code quality.
Ranking Standard
| Metric | Threshold | How It’s Measured |
|---|---|---|
| Architecture decisions | 2+ decisions that shaped product direction for 6+ months | Architecture decision records + outcome review |
| Tech debt management | Active inventory with business-impact scoring | Tech debt log audit |
| System-level code review | Final review authority on 1+ product surfaces | Review records + team confirmation |
| Kill decisions | 1+ feature/project killed or redirected based on your judgment | Decision log + outcome |
| Incident response | Led 3+ incident resolutions to root cause | Post-mortem records |
| Mentee advancement | 1+ mentee at L4+ | Rank records |
| Founder trust | Founder delegates technical tradeoff decisions to you | Founder confirmation |
Promotion to L7
Requirements
- Minimum 24 months at L6
- Pass L7 qualification assessment:
- Architecture case study — present a major architecture decision with full context, tradeoffs, and outcomes. The panel evaluates your reasoning, not just the result.
- Taste test — the panel presents an unfamiliar codebase or system. You have limited time to assess it and recommend what to fix, leave, and kill. They’re evaluating how you think.
- Tech debt portfolio review — present your tech debt management approach. The panel evaluates prioritization judgment and business alignment.
- Business fluency demonstration — explain how your technical decisions connect to business outcomes. If you can’t draw the line from architecture to revenue, you’re not ready.
- Mentee outcomes — present your mentees’ growth. At least one at L4+.
- Demonstrated ability to communicate technical tradeoffs to non-technical stakeholders
What the Panel Looks For
- Taste — does this person consistently make the right call on what to fix, leave, and kill? Not perfect — consistent.
- System vision — do they see the whole product, or just the part they’re working on?
- Restraint — do they resist the urge to rewrite everything? The best L6s know that most code should be left alone.
- Business grounding — are their technical decisions informed by business context, or do they optimize for elegance?
- Honesty — do they admit when a past decision was wrong? Do they update their mental models?
Mentorship at This Level
- You receive: L8+ mentor, bi-weekly check-ins. Focus on developing product-level judgment and business context.
- You give: 3 mentee slots (L1–L4). Active, not passive. Weekly check-ins minimum.
- Referral cut: 5% of mentee’s monthly rate for 12 months after placement.
- Panel duty: You serve on qualification panels for L1–L5 promotions. Your taste shapes the next generation’s standard.
What Unlocks at L7
- Roadmap ownership — you decide what gets built next, not just how it gets built
- Direct relationship with the business side: users, metrics, strategy
- The founder trusts your judgment on what to build
- 4 mentee slots (L1–L5)
- Referral cut: 6% for 12 months
- No fast-tracking past L7 — taste, trust, and judgment take time