Initial commit

skills/alignment-values-north-star/SKILL.md

@@ -0,0 +1,163 @@
+---
+name: alignment-values-north-star
+description: Use when teams need shared direction and decision-making alignment. Invoke when starting new teams, scaling organizations, defining culture, establishing product vision, resolving misalignment, creating strategic clarity, or setting behavioral standards. Use when user mentions North Star, team values, mission, principles, guardrails, decision framework, or cultural alignment.
+---
+
+# Alignment: Values & North Star
+
+## Table of Contents
+
+- [Purpose](#purpose)
+- [When to Use This Skill](#when-to-use-this-skill)
+- [What is Values & North Star Alignment?](#what-is-values--north-star-alignment)
+- [Workflow](#workflow)
+  - [1. Understand Context](#1--understand-context)
+  - [2. Choose Framework](#2--choose-framework)
+  - [3. Develop Alignment Artifact](#3--develop-alignment-artifact)
+  - [4. Validate Quality](#4--validate-quality)
+  - [5. Deliver and Socialize](#5--deliver-and-socialize)
+- [Common Patterns](#common-patterns)
+- [Guardrails](#guardrails)
+- [Quick Reference](#quick-reference)
+
+## Purpose
+
+Create clear, actionable alignment frameworks that give teams a shared North Star (direction), values (guardrails), and decision tenets (behavioral standards). This enables autonomous decision-making while maintaining coherence across the organization.
+
+## When to Use This Skill
+
+- Starting new teams or organizations (defining identity)
+- Scaling teams (maintaining culture as you grow)
+- Resolving misalignment or conflicts (clarifying shared direction)
+- Defining product/engineering/design principles
+- Creating strategic clarity after pivots or changes
+- Establishing decision-making frameworks
+- Setting cultural norms and behavioral expectations
+- Post-merger integration (aligning different cultures)
+- Crisis response (re-centering on what matters)
+- Onboarding leaders who need to understand team identity
+
+**Trigger phrases:** "North Star", "team values", "mission", "vision", "principles", "guardrails", "what we stand for", "decision framework", "cultural alignment", "operating principles"
+
+## What is Values & North Star Alignment?
+
+A framework with three layers:
+
+1. **North Star**: The aspirational direction - where are we going and why?
+2. **Values/Guardrails**: Core principles that constrain how we operate
+3. **Decision Tenets/Behaviors**: Concrete, observable behaviors that demonstrate values
+
+**Quick Example:**
+
+```markdown
+# Engineering Team Alignment
+
+## North Star
+Build systems that developers love to use and operators trust to run.
+
+## Values
+- **Simplicity**: Choose boring technology that works over exciting technology that might
+- **Reliability**: Every service has SLOs and we honor them
+- **Empathy**: Design for the developer experience, not just system performance
+
+## Decision Tenets
+When choosing between options:
+✓ Pick the solution with fewer moving parts
+✓ Choose managed services over self-hosted when quality is comparable
+✓ Optimize for debuggability over micro-optimizations
+✓ Document decisions (ADRs) for future context
+
+## Behaviors (What This Looks Like)
+- Code reviews comment on operational complexity, not just correctness
+- We say no to features that compromise reliability
+- Postmortems focus on learning, not blame
+- Documentation is part of "done"
+```
+
+## Workflow
+
+Copy this checklist and track your progress:
+
+```
+Alignment Framework Progress:
+- [ ] Step 1: Understand context
+- [ ] Step 2: Choose framework
+- [ ] Step 3: Develop alignment artifact
+- [ ] Step 4: Validate quality
+- [ ] Step 5: Deliver and socialize
+```
+
+**Step 1: Understand context**
+
+Gather background: team/organization (size, stage, structure), current situation (new team, scaling, misalignment, crisis), trigger (why alignment needed NOW), stakeholders (who needs to align), hard decisions (where misalignment shows up), and existing artifacts (mission, values, culture statements). This ensures the framework addresses real needs.
+
+**Step 2: Choose framework**
+
+For new teams/startups (< 30 people, defining identity from scratch) → Use `resources/template.md`. For scaling organizations (existing values need refinement, multiple teams, need decision framework) → Study `resources/methodology.md`. To see examples → Review `resources/examples/` (engineering-team.md, product-vision.md, company-values.md).
+
+**Step 3: Develop alignment artifact**
+
+Create `alignment-values-north-star.md` with: compelling North Star (1-2 sentences, aspirational but specific), 3-5 core values (specific to this team, not generic), decision tenets ("When X vs Y, we..."), observable behaviors (concrete examples), anti-patterns (optional - what we DON'T do), and context (optional - why these values). See [Common Patterns](#common-patterns) for team-type specific guidance.
+
+**Step 4: Validate quality**
+
+Self-check using `resources/evaluators/rubric_alignment_values_north_star.json`. Verify: North Star is inspiring yet concrete, values are specific and distinctive, decision tenets guide real decisions, behaviors are observable/measurable, usable for decisions TODAY, trade-offs acknowledged, no contradictions, distinguishes this team from others. Minimum standard: Score ≥ 3.5 (aim for 4.5+ if organization-wide).
+
+**Step 5: Deliver and socialize**
+
+Present completed framework with rationale (why these values), examples of application in decisions, rollout/socialization approach (hiring, decision-making, onboarding, team meetings), and review cadence (typically annually). Ensure team can recall and apply key points.
+
+## Common Patterns
+
+**For technical teams:**
+- Focus on technical trade-offs (simplicity vs performance, speed vs quality)
+- Make architectural principles explicit
+- Include operational considerations
+- Address technical debt philosophy
+
+**For product teams:**
+- Center on user/customer value
+- Address feature prioritization philosophy
+- Include quality bar and launch criteria
+- Make product-market fit assumptions explicit
+
+**For company-wide values:**
+- Keep values aspirational but grounded
+- Include specific behaviors (not just values)
+- Address how values interact (what wins when they conflict?)
+- Make hiring/firing implications clear
+
+**For crisis/change:**
+- Acknowledge what's changing
+- Re-center on core that remains
+- Be explicit about new priorities
+- Include timeline for transition
+
+## Guardrails
+
+**Do:**
+- Make values specific and distinctive (not generic)
+- Include concrete behaviors and examples
+- Acknowledge trade-offs (what you're NOT optimizing for)
+- Test values against real decisions
+- Keep it concise (1-2 pages max)
+- Make it memorable (people should be able to recall key points)
+- Involve the team in creating it (not top-down)
+
+**Don't:**
+- Use corporate jargon or buzzwords
+- Make it so generic it could apply to any company
+- Create laundry list of every good quality
+- Ignore tensions between values
+- Make it purely aspirational (need concrete behaviors)
+- Set it and forget it (values should evolve)
+- Weaponize values to shut down dissent
+
+## Quick Reference
+
+- **Standard template**: `resources/template.md`
+- **Scaling/complex cases**: `resources/methodology.md`
+- **Examples**: `resources/examples/engineering-team.md`, `resources/examples/product-vision.md`, `resources/examples/company-values.md`
+- **Quality rubric**: `resources/evaluators/rubric_alignment_values_north_star.json`
+
+**Output naming**: `alignment-values-north-star.md` or `{team-name}-alignment.md`

skills/alignment-values-north-star/resources/evaluators/rubric_alignment_values_north_star.json

@@ -0,0 +1,135 @@
+{
+  "name": "Alignment Framework Quality Rubric",
+  "scale": {
+    "min": 1,
+    "max": 5,
+    "description": "1=Poor, 2=Fair, 3=Good, 4=Very Good, 5=Excellent"
+  },
+  "criteria": [
+    {
+      "name": "North Star Clarity",
+      "description": "North Star is inspiring yet specific and memorable",
+      "scoring": {
+        "1": "No North Star or completely generic/vague",
+        "2": "North Star exists but generic or unmemorable",
+        "3": "North Star is clear and somewhat specific",
+        "4": "North Star is compelling, specific, and memorable",
+        "5": "Exceptional North Star that team can recite and use for decisions"
+      }
+    },
+    {
+      "name": "Value Specificity",
+      "description": "Values are distinctive to this team, not generic corporate values",
+      "scoring": {
+        "1": "Generic values that could apply to any company",
+        "2": "Some generic values with minimal context",
+        "3": "Values have some specificity to this team/context",
+        "4": "Values are clearly specific to this team with context",
+        "5": "Exceptionally distinctive values that couldn't apply elsewhere"
+      }
+    },
+    {
+      "name": "Trade-off Transparency",
+      "description": "Values explicitly state what's being optimized FOR and what's de-prioritized",
+      "scoring": {
+        "1": "No trade-offs mentioned",
+        "2": "Vague mention of trade-offs",
+        "3": "Some values include trade-offs",
+        "4": "Most values explicitly state trade-offs",
+        "5": "All values clearly state what's gained and what's sacrificed"
+      }
+    },
+    {
+      "name": "Decision Tenet Utility",
+      "description": "Decision tenets provide actionable guidance for real decisions",
+      "scoring": {
+        "1": "No decision tenets or purely abstract",
+        "2": "Tenets exist but too vague to apply",
+        "3": "Tenets provide some practical guidance",
+        "4": "Tenets address real trade-offs with clear guidance",
+        "5": "Exceptional tenets that resolve actual team dilemmas"
+      }
+    },
+    {
+      "name": "Behavioral Observability",
+      "description": "Behaviors are concrete, observable, and measurable",
+      "scoring": {
+        "1": "No behaviors or purely aspirational statements",
+        "2": "Behaviors are vague (e.g., 'communicate well')",
+        "3": "Some behaviors are specific and observable",
+        "4": "Most behaviors are concrete and observable",
+        "5": "All behaviors are specific enough to recognize in daily work"
+      }
+    },
+    {
+      "name": "Immediate Applicability",
+      "description": "Someone could use this framework to make a decision TODAY",
+      "scoring": {
+        "1": "Framework is purely aspirational, no practical use",
+        "2": "Limited practical guidance",
+        "3": "Could inform some decisions",
+        "4": "Clear guidance for most common decisions",
+        "5": "Exceptional practical utility for daily decision-making"
+      }
+    },
+    {
+      "name": "Internal Consistency",
+      "description": "No contradictions between values, tenets, and behaviors",
+      "scoring": {
+        "1": "Major contradictions throughout",
+        "2": "Some contradictions between sections",
+        "3": "Mostly consistent with minor tensions",
+        "4": "Fully consistent with tensions acknowledged",
+        "5": "Perfect coherence with explicit resolution of value conflicts"
+      }
+    },
+    {
+      "name": "Distinctiveness",
+      "description": "Could clearly distinguish this team from others based on these values",
+      "scoring": {
+        "1": "Could apply to literally any team",
+        "2": "Minimal distinction from generic teams",
+        "3": "Some unique characteristics emerge",
+        "4": "Clear team identity and differentiation",
+        "5": "Unmistakably distinctive team culture"
+      }
+    },
+    {
+      "name": "Conciseness",
+      "description": "Framework is concise and memorable (1-2 pages ideally)",
+      "scoring": {
+        "1": "Too long (>5 pages) or too short (just platitudes)",
+        "2": "Either too verbose or too sparse",
+        "3": "Reasonable length but could be tighter",
+        "4": "Appropriately concise (2-3 pages)",
+        "5": "Perfect length (1-2 pages), highly memorable"
+      }
+    },
+    {
+      "name": "Anti-Pattern Clarity",
+      "description": "Explicitly states what the team does NOT do",
+      "scoring": {
+        "1": "No anti-patterns mentioned",
+        "2": "Vague or generic anti-patterns",
+        "3": "Some specific anti-patterns included",
+        "4": "Clear anti-patterns that set boundaries",
+        "5": "Exceptional anti-patterns that prevent common dysfunctions"
+      }
+    }
+  ],
+  "overall_assessment": {
+    "thresholds": {
+      "excellent": "Average score ≥ 4.5 (company-wide values should aim for this)",
+      "very_good": "Average score ≥ 4.0 (most alignment frameworks should achieve this)",
+      "good": "Average score ≥ 3.5 (minimum for team-level alignment)",
+      "acceptable": "Average score ≥ 3.0 (workable but needs improvement)",
+      "needs_rework": "Average score < 3.0 (revise before using)"
+    },
+    "scope_guidance": {
+      "team_level": "Team values (< 30 people): aim for ≥ 3.5",
+      "function_level": "Function/department values: aim for ≥ 4.0",
+      "company_level": "Organization-wide values: aim for ≥ 4.5"
+    }
+  },
+  "usage_instructions": "Rate each criterion on 1-5 scale. Calculate average. For team-level alignment, minimum is 3.5. For organization-wide values that will be used in hiring/performance reviews, aim for ≥4.5. Identify lowest-scoring criteria and improve those sections before delivering."
+}

skills/alignment-values-north-star/resources/examples/engineering-team.md

@@ -0,0 +1,343 @@
+# Platform Engineering Team Alignment Framework
+
+## Context
+
+**Why this matters now:**
+Our platform team has grown from 3 to 15 engineers in 12 months. We're seeing inconsistent architecture decisions, unclear ownership, and technical debt accumulating. Teams are blocked waiting for platform features. We need shared principles to enable autonomous decision-making while maintaining quality and consistency.
+
+**Who this is for:**
+Platform Engineering team (15 engineers, 3 teams: Infrastructure, Developer Tools, Observability)
+
+**Last updated:** 2024-11-15
+
+---
+
+## North Star
+
+**Build infrastructure that developers trust and love to use.**
+
+Every platform we build should make developers more productive, not add cognitive load. Systems should be so reliable that product teams never think about them.
+
+---
+
+## Core Values
+
+### 1. Simplicity Over Cleverness
+
+**What it means:**
+We choose boring, proven technology over exciting new tools. We value systems that operators can debug at 3 AM over systems that are technically impressive. Every abstraction must pay for itself in reduced complexity.
+
+**Why it matters:**
+Complex systems fail in complex ways. When product teams are down, they need fixes fast, not archaeology. Our 3 AM self will curse our 3 PM clever self.
+
+**What we optimize for:**
+- Debuggability and operational simplicity
+- Fewer moving parts
+- Standard solutions over custom code
+- Clear mental models
+
+**What we de-prioritize:**
+- Resume-driven development
+- Micro-optimizations that add complexity
+- Novel approaches when proven ones exist
+- Being first to adopt new tech
+
+**Examples:**
+- Use managed PostgreSQL instead of building our own database cluster
+- Choose nginx over a custom written load balancer
+- Pick Kubernetes standard patterns over clever custom operators
+
+### 2. Reliability Over Features
+
+**What it means:**
+Every service has SLOs and we honor them. We say no to features that compromise reliability. Reliability is a feature, not a phase. When in doubt, we prioritize preventing incidents over shipping features.
+
+**Why it matters:**
+One platform outage affects every product team. Our unreliability multiplies across the organization. Lost trust takes months to rebuild.
+
+**What we optimize for:**
+- SLO compliance (99.9%+ uptime for critical paths)
+- Graceful degradation
+- Observable systems
+- Rollback capability
+
+**What we de-prioritize:**
+- Shipping fast at the cost of stability
+- Features without monitoring
+- Experimentation that risks critical path
+- Tight coupling that prevents safe deploys
+
+**Examples:**
+- We run chaos engineering tests before Black Friday
+- New features launch behind feature flags with gradual rollout
+- We have automated rollback for all critical services
+
+### 3. Developer Experience is Not Optional
+
+**What it means:**
+APIs should be intuitive, documentation should exist, and errors should be actionable. If developers are frustrated, we've failed. We design for the developer using our systems, not just for the system itself.
+
+**Why it matters:**
+Friction in platform tools slows every product team. 100 developers × 10min friction = 1000min lost daily. Good DX multiplies productivity; bad DX multiplies frustration.
+
+**What we optimize for:**
+- Clear, actionable error messages
+- Comprehensive, up-to-date documentation
+- Simple onboarding (< 1 hour to first deploy)
+- Fast feedback loops
+
+**What we de-prioritize:**
+- Internal-only jargon in APIs
+- Optimization for our convenience over user experience
+- Tribal knowledge over documentation
+- Complex configurations
+
+**Examples:**
+- All APIs have OpenAPI specs and interactive docs
+- Error messages include links to runbooks
+- We measure "time to first successful deploy" for new services
+
+### 4. Ownership Means Accountability
+
+**What it means:**
+If you build it, you run it. Teams own their services end-to-end: development, deployment, monitoring, on-call. Ownership includes making your service operationally excellent, not just functionally correct.
+
+**Why it matters:**
+Throwing code over the wall creates unmaintainable systems. Operators who didn't build it can't improve it. Builders who don't operate it don't feel the pain of poor operational characteristics.
+
+**What we optimize for:**
+- End-to-end ownership
+- Operational maturity (monitoring, alerting, runbooks)
+- Empowered teams
+- Learning from production
+
+**What we de-prioritize:**
+- Separate "ops" team for platform services
+- Deploying without runbooks
+- Services without clear owners
+- Handoffs between teams
+
+**Examples:**
+- Infrastructure team is on-call for Kubernetes cluster
+- Developer Tools team owns CI/CD pipeline end-to-end
+- Each team has SLO dashboards they review weekly
+
+---
+
+## Decision Tenets
+
+### When Choosing Technology
+
+**When evaluating new tools:**
+- ✓ Choose managed services (RDS, managed K8s) over self-hosted when quality is comparable
+- ✓ Pick tools with strong observability out-of-the-box
+- ✓ Prefer tools our team has expertise in over "better" tools we'd need to learn
+- ✗ Don't adopt because it's trending or looks good on résumé
+- ⚠ **Exception:** When existing tools fundamentally can't meet requirements AND we have capacity to support
+
+**When building vs buying:**
+- ✓ Build when our requirements are unique or when vendors don't exist
+- ✓ Buy when it's undifferentiated heavy lifting (observability, databases)
+- ✗ Don't build for the joy of building
+- ⚠ **Exception:** Build when vendor lock-in risk outweighs development cost
+
+### When Making Architecture Decisions
+
+**When designing APIs:**
+- ✓ Choose RESTful JSON APIs as default (boring, widely understood)
+- ✓ Design for the developer experience, document before implementing
+- ✗ Don't create bespoke protocols without strong justification
+- ⚠ **Exception:** gRPC for high-performance internal services
+
+**When choosing between perfection and shipping:**
+- ✓ Ship with known minor issues if they don't affect SLOs
+- ✓ Document technical debt and schedule fixes
+- ✗ Don't ship if it compromises security, data integrity, or violates SLOs
+- ⚠ **Exception:** Never compromise on security, payments, or PII handling
+
+### When Prioritizing Work
+
+**When product teams request features:**
+- 🔴 **Critical:** SLO violations, security issues, data loss risks
+- 🟡 **Important:** Developer friction affecting >3 teams, technical debt preventing new features
+- ⚪ **Nice-to-have:** Single-team requests, optimizations, new nice-to-have features
+
+**When allocating time:**
+- 70% Product work (features product teams need)
+- 20% Platform health (tech debt, improvements)
+- 10% Innovation (experiments, R&D)
+
+---
+
+## Observable Behaviors
+
+### In Code Reviews
+
+- We comment on operational characteristics (What happens when this fails? How will we debug it?)
+- We ask "What's the runbook?" before approving infrastructure changes
+- We praise simplicity and question complexity
+- We flag missing monitoring/alerting
+
+### In Planning
+
+- First question: "What's the simplest thing that could work?"
+- We timeblock for operational work (not just features)
+- We say no to work that violates SLOs or has no monitoring plan
+- We ask "Who's on-call for this?"
+
+### In Incidents
+
+- Postmortems focus on learning, not blame
+- We fix systemic issues, not just symptoms
+- We update runbooks during incidents
+- We celebrate good incident response (fast mitigation, clear communication)
+
+### In Communication
+
+- We write Architecture Decision Records (ADRs) for significant choices
+- We document before we ship
+- We assume future readers lack our context
+- We use plain language, not jargon
+
+### In Hiring
+
+- We ask candidates to debug a system, not just build features
+- We evaluate for operational maturity, not just coding skills
+- We look for simplicity-minded engineers, not algorithm wizards
+- We ask: "Tell me about a time you chose boring tech over exciting tech"
+
+### In Daily Work
+
+- We check SLO dashboards daily
+- We improve documentation when we're confused
+- We automate toil we encounter
+- We share learnings in team channels
+
+---
+
+## Anti-Patterns
+
+### What We Explicitly DON'T Do
+
+✗ **Ship without monitoring** - even when deadline pressure is high
+   - **Because:** Reliability > Features. Can't fix what we can't observe.
+
+✗ **Optimize prematurely** - even when we see potential improvements
+   - **Because:** Simplicity > Performance. Measure first, optimize if needed.
+
+✗ **Build custom solutions for solved problems** - even when it seems fun
+   - **Because:** Maintenance cost exceeds initial development 10x. Use managed services.
+
+✗ **Skip documentation because "code is self-documenting"** - even when time is tight
+   - **Because:** Developer Experience matters. Future us will curse present us.
+
+✗ **Say yes to every feature request** - even when stakeholders insist
+   - **Because:** Ownership includes protecting platform quality. Our job is to say no to bad ideas.
+
+✗ **Deploy Friday afternoon** - even when it seems low-risk
+   - **Because:** Reliability matters more than shipping fast. Weekend incidents aren't worth it.
+
+---
+
+## How to Use This
+
+### In Decision-Making
+
+**When stuck between two options:**
+1. Check decision tenets above
+2. Ask "Which choice better serves our North Star?"
+3. Consider which value is most relevant
+4. Document decision in ADR with rationale
+
+### In Hiring
+
+**Interview questions tied to values:**
+- **Simplicity:** "Tell me about a time you refactored complex code to be simpler. What drove that decision?"
+- **Reliability:** "How do you decide when to ship vs. when to delay for quality?"
+- **Developer Experience:** "What makes a good API? Show me an API you love and why."
+- **Ownership:** "How do you approach on-call? What makes a service operationally mature?"
+
+### In Onboarding
+
+**Week 1:** New engineers read this document and discuss in 1:1
+**Week 2:** Shadow on-call to see ownership in practice
+**Week 3:** Pair on feature to see values in code review
+**Month 1:** Present one architectural decision using these tenets
+
+### In Performance Reviews
+
+We evaluate on:
+- **Simplicity:** Do they choose boring solutions? Do they reduce complexity?
+- **Reliability:** Do their services meet SLOs? How do they handle incidents?
+- **Developer Experience:** Is their code/APIs/docs easy to use?
+- **Ownership:** Do they own services end-to-end? Do they improve operations?
+
+### When Values Conflict
+
+**Simplicity vs Developer Experience:**
+- **Winner:** Developer Experience. Simple for *us* to maintain isn't valuable if developers can't use it.
+
+**Reliability vs Speed:**
+- **Winner:** Reliability. But use feature flags to ship safely.
+
+**Features vs Platform Health:**
+- **Default:** Follow 70/20/10 allocation. But SLO violations always win.
+
+---
+
+## Evolution
+
+**Review cadence:** Quarterly team retro discusses if values still serve us. Annual deep revision.
+
+**Who can propose changes:** Anyone. Discuss in team meeting, decision by consensus.
+
+**What stays constant:**
+- North Star (unless fundamental mission changes)
+- Core value themes (names might evolve, principles remain)
+
+**Recent changes:**
+- *2024-Q3*: Added "Developer Experience" value as team grew and internal customers increased
+- *2024-Q2*: Refined "Simplicity" to explicitly call out managed services
+- *2024-Q1*: Added 70/20/10 time allocation guideline
+
+---
+
+## Success Stories
+
+### Example 1: Chose PostgreSQL RDS over Self-Hosted
+
+**Situation:** Need database for new service. Self-hosted gives more control and learning opportunity.
+
+**Decision:** Chose AWS RDS PostgreSQL (managed service).
+
+**Values applied:**
+- ✓ Simplicity > Cleverness: Less operational burden
+- ✓ Ownership: Team doesn't have DB expertise yet
+- ✓ Reliability: AWS has better uptime than we'd achieve
+
+**Outcome:** Service launched in 2 weeks vs. estimated 6 weeks for self-hosted setup and learning. Zero database incidents in 6 months.
+
+### Example 2: Said No to Real-Time Features
+
+**Situation:** Product team requested real-time notifications (WebSockets) for dashboard.
+
+**Decision:** Said no, proposed 30-second polling instead.
+
+**Values applied:**
+- ✓ Simplicity: Polling is simpler than WebSocket infrastructure
+- ✓ Reliability: Don't risk stability for nice-to-have feature
+- ✓ Developer Experience: Team lacks WebSocket experience
+
+**Outcome:** Shipped in 1 week with polling. User research showed 30s delay was acceptable. Saved 6+ weeks of WebSocket infrastructure work.
+
+### Example 3: Invested Week in Documentation
+
+**Situation:** New API ready to ship, docs incomplete. Pressure to launch.
+
+**Decision:** Delayed launch one week to complete docs, examples, and migration guide.
+
+**Values applied:**
+- ✓ Developer Experience: Documentation is not optional
+- ✓ Ownership: We support what we ship
+
+**Outcome:** 12 teams adopted in first month (vs estimated 4-6 with poor docs). Near-zero support requests due to clear docs.

skills/alignment-values-north-star/resources/methodology.md

@@ -0,0 +1,494 @@
+# Alignment Framework Methodology for Scaling Organizations
+
+## Alignment Framework Workflow
+
+Copy this checklist and track your progress:
+
+```
+Alignment Framework Progress:
+- [ ] Step 1: Audit current state and identify gaps
+- [ ] Step 2: Refine values through stakeholder discovery
+- [ ] Step 3: Build multi-team alignment framework
+- [ ] Step 4: Create decision frameworks for autonomy
+- [ ] Step 5: Rollout and reinforce across organization
+```
+
+**Step 1: Audit current state and identify gaps**
+
+Document stated vs actual values, interview stakeholders, and analyze past decisions to identify values drift. See [Refining Existing Values](#refining-existing-values) for audit techniques.
+
+**Step 2: Refine values through stakeholder discovery**
+
+Evolve or replace values based on discovery findings, using stakeholder input to ensure relevance. See [Refinement Process](#refinement-process) for evolution patterns and rollout strategies.
+
+**Step 3: Build multi-team alignment framework**
+
+Create layered alignment across company, function, and team levels to prevent silos. See [Multi-Team Alignment Frameworks](#multi-team-alignment-frameworks) for nested framework structures.
+
+**Step 4: Create decision frameworks for autonomy**
+
+Build decision tenets and authority matrices to enable aligned autonomy. See [Building Decision Frameworks for Autonomy](#building-decision-frameworks-for-autonomy) for tenet patterns and RACI matrices.
+
+**Step 5: Rollout and reinforce across organization**
+
+Execute phased rollout with leadership alignment, cascading communication, and ongoing reinforcement. See [Rollout Strategy for Refined Values](#rollout-strategy-for-refined-values) and [Case Study: Company-Wide Values Refresh](#case-study-company-wide-values-refresh) for implementation examples.
+
+---
+
+## Refining Existing Values
+
+### Why Refine?
+
+Common triggers:
+- Values are vague ("be excellent") - no operational guidance
+- Values conflict with reality (say "innovation" but punish failures)
+- New priorities emerged (e.g., shift from growth to profitability)
+- Multiple acquisitions brought different cultures
+- Team doesn't reference values in decisions (not useful)
+
+### Audit Current State
+
+**Step 1: Document existing values**
+- What are stated values? (website, onboarding docs, walls)
+- What are *actual* values? (observed in decisions, promotions, conflicts)
+- Gap analysis: Where do stated and actual diverge?
+
+**Step 2: Interview stakeholders**
+
+Questions to ask:
+- "What do we truly value here? (not what we say we value)"
+- "Tell me about a tough decision - what guided it?"
+- "What behaviors get rewarded? Punished?"
+- "When have our values helped you? Hindered you?"
+- "What values are missing that we need?"
+
+**Step 3: Analyze decisions**
+
+Review past 6-12 months:
+- Hiring/firing decisions - what values were applied?
+- Product prioritization - what drove choices?
+- Resource allocation - what got funded/cut?
+- Conflict resolution - how were tradeoffs made?
+
+Look for patterns revealing true values.
+
+### Refinement Process
+
+**Option A: Evolve existing values**
+
+Keep core values but make them clearer:
+
+Before: "Customer obsession"
+After: "Customer obsession: We prioritize long-term customer success over short-term metrics. When in doubt, we ask 'what would create lasting value for customers?' and optimize for that, even if it delays revenue."
+
+**Add:**
+- Specific definition
+- Why it matters
+- Decision examples
+- Anti-patterns
+
+**Option B: Retire and replace**
+
+When existing values don't serve:
+1. Acknowledge what's changing and why
+2. Thank the old values for their service
+3. Introduce new values with context
+4. Show connection (evolution, not rejection)
+
+Example:
+- Old: "Move fast and break things" (startup phase)
+- New: "Move deliberately with customer trust" (scale phase)
+- Context: "We used to optimize for speed because we needed product-market fit. Now we optimize for reliability because customers depend on us."
+
+### Rollout Strategy for Refined Values
+
+**Phase 1: Leadership alignment (Week 1-2)**
+- All leaders can articulate values in their own words
+- Leadership team models values in visible decisions
+- Leaders prepared to answer "why change?" and "what's different?"
+
+**Phase 2: Cascading communication (Week 3-4)**
+- All-hands presentation (context, new values, Q&A)
+- Team-level workshops (apply to team decisions)
+- 1:1s address individual concerns
+
+**Phase 3: Integration (Month 2-3)**
+- Update hiring rubrics
+- Update performance review criteria
+- Reference in decision memos
+- Celebrate examples of values in action
+
+**Phase 4: Reinforcement (Ongoing)**
+- Monthly: Leaders share values-driven decisions
+- Quarterly: Audit if values are being used
+- Annually: Refresh based on feedback
+
+---
+
+## Multi-Team Alignment Frameworks
+
+### Challenge: Silos & Conflicting Priorities
+
+As organizations scale:
+- Teams optimize for local goals
+- Priorities conflict (eng wants stability, product wants speed)
+- Decisions require escalation (autonomy breaks down)
+- Values interpreted differently across teams
+
+### Layered Alignment Framework
+
+**Layer 1: Company-Wide North Star & Values**
+
+Company level (50+ people, multiple teams):
+- North Star: Aspirational direction for whole company
+- Values: 3-5 company-wide principles
+- Decision Tenets: Company-level tradeoff guidance
+
+Example:
+```
+Company North Star: "Empower every team to ship confidently"
+
+Company Values:
+1. Customer trust over growth metrics
+2. Clarity over consensus
+3. Leverage through platforms
+
+Company Decision Tenets:
+- When product and platform conflict, platforms enable more product value long-term
+- When speed and reliability conflict, we choose reliability for critical paths
+```
+
+**Layer 2: Function-Level Values & Tenets**
+
+Engineering, Product, Design, Sales functions each add:
+- Function-specific interpretation of company values
+- Function decision tenets (within company constraints)
+- Function behaviors
+
+Example (Engineering):
+```
+Engineering North Star: "Enable product velocity through reliable platforms"
+
+Engineering Values (extending company):
+1. Customer trust → "We treat production as sacred"
+2. Clarity → "We write decisions down before coding"
+3. Leverage → "We build platforms, not point solutions"
+
+Engineering Decision Tenets:
+- When feature velocity and platform health conflict, platform health wins
+- When local optimization and system optimization conflict, system wins
+- When urgency and testing conflict, we ship with tests (move test left)
+```
+
+**Layer 3: Team-Level Rituals & Practices**
+
+Individual teams implement values through rituals:
+- How we run standups
+- How we make architectural decisions
+- How we handle incidents
+- How we onboard new members
+
+Example (Platform Team):
+```
+Rituals embodying "Platform enables product velocity":
+- Weekly: Office hours for product teams (30 min slots)
+- Monthly: Platform roadmap review with product input
+- Quarterly: Platform usability study with product engineers
+```
+
+### Alignment Check: Nested Frameworks
+
+Test if layers are aligned:
+
+| Company Value | Function Interpretation | Team Practice |
+|---------------|------------------------|---------------|
+| Customer trust | Engineering: Production is sacred | Platform: 99.9% SLA, postmortems within 24hr |
+| Clarity | Engineering: Write before coding | Platform: RFC required for API changes |
+| Leverage | Engineering: Platforms not point solutions | Platform: Reusable libraries, not feature forks |
+
+If a team practice doesn't connect to function value → doesn't connect to company value → misaligned.
+
+---
+
+## Building Decision Frameworks for Autonomy
+
+### Problem: Alignment vs Autonomy Tension
+
+- Too much alignment → slow, needs approval for everything
+- Too much autonomy → teams diverge, duplicate work, conflict
+
+Goal: **Aligned autonomy** - teams make fast local decisions within clear constraints.
+
+### Decision Tenet Pattern
+
+**Format:**
+```
+When {situation with tradeoff}, we choose {option A} over {option B} because {rationale}.
+```
+
+**Characteristics of good tenets:**
+- Specific (not "be excellent")
+- Tradeoff-oriented (acknowledges what we're NOT optimizing)
+- Contextual (explains why this choice for us)
+- Actionable (guides concrete decisions)
+
+**Example Tenets:**
+
+Engineering:
+```
+When latency and throughput conflict, we optimize for latency (p95 < 100ms)
+because our users are professionals in workflows where milliseconds matter.
+```
+
+Product:
+```
+When power-user features and beginner simplicity conflict, we choose beginner simplicity
+because growing the user base is our current strategic priority (2024 goal: 10x users).
+```
+
+Sales:
+```
+When deal size and customer fit conflict, we choose customer fit
+because high-churn enterprise customers damage our brand and reference-ability.
+```
+
+### Decision Authority Matrix (RACI + Values)
+
+Map which decisions require escalation vs can be made locally:
+
+| Decision Type | Team Authority | Escalation Trigger | Values Applied |
+|---------------|----------------|-------------------|----------------|
+| API design for team features | Team decides | If cross-team impact | Platform leverage |
+| Production incident response | On-call decides | If customer data risk | Customer trust |
+| Prioritization within quarter | PM decides | If OKR conflict | Quarterly focus |
+| Hiring bar | Team + function | Never lower bar | Excellence standard |
+
+**Escalation triggers** (when to involve leadership):
+- Cross-team conflict on priorities
+- Values conflict (two values in tension)
+- Precedent-setting decision (will affect future teams)
+- High-stakes outcome (>$X, >Y customer impact)
+
+### Operationalizing Tenets in Decisions
+
+**Step 1: Frame decision with tenets**
+
+Bad decision memo:
+```
+We should build feature X.
+```
+
+Good decision memo:
+```
+Decision: Build feature X
+
+Relevant tenets:
+- "When power-users and beginners conflict, choose beginners" → Feature X is beginner-focused ✓
+- "When latency and features conflict, choose latency" → Feature X adds 20ms latency ✗
+- "Platform leverage over point solutions" → Feature X is platform component ✓
+
+Recommendation: Build feature X BUT optimize latency first (refactor API)
+Estimate: +2 weeks for latency optimization, worth it per tenets
+```
+
+**Step 2: Audit tenet usage**
+
+Quarterly review:
+- How many decisions referenced tenets?
+- Which tenets are most/least used?
+- Where did tenets conflict? (may need refinement)
+- Where did teams escalate unnecessarily? (need clearer tenet)
+
+---
+
+## Common Scaling Challenges
+
+### Challenge 1: Values Drift (Stated ≠ Actual)
+
+**Symptoms:**
+- Leaders say "we value X" but reward Y
+- Values posters on walls, but no one references them
+- Cynicism about values ("just marketing")
+
+**Diagnosis:**
+- Review promotions: Who gets promoted? What values did they embody?
+- Review tough decisions: Which values were actually applied?
+- Interview employees: "Do you use our values? When? How?"
+
+**Fix:**
+1. **Acknowledge drift** ("Our stated values haven't matched our actions")
+2. **Choose**: Either change stated values to match reality OR change behavior to match values
+3. **Leader modeling**: Leaders publicly use values in decisions
+4. **Consequences**: Promotions/rewards explicitly tied to values
+
+**Example:**
+```
+Stated: "We value work-life balance"
+Reality: Promotions go to those who work weekends
+
+Fix Option A (change stated): "We value high output and intense commitment"
+Fix Option B (change reality): "Promotions now require sustainable pace, not just output"
+```
+
+### Challenge 2: Values Conflict (Internal Tensions)
+
+**Symptoms:**
+- Teams cite different values for same decision
+- Paralysis (can't decide because values conflict)
+- Escalation overload (everything needs leadership tiebreak)
+
+**Diagnosis:**
+- Map values pairwise: When do Value A and Value B conflict?
+- Identify repeated conflict scenarios
+- Ask: Is this values conflict or unclear priority?
+
+**Fix: Priority tenets**
+
+When values conflict, state priority:
+```
+"Speed" and "Quality" both matter, but:
+- For customer-facing features: Quality > Speed (customer trust)
+- For internal tools: Speed > Perfection (iterate fast)
+- For platform APIs: Quality > Speed (leverage means hard to change)
+```
+
+### Challenge 3: Multi-Team Misalignment
+
+**Symptoms:**
+- Teams build conflicting solutions
+- Escalation required for every cross-team decision
+- "Not my priority" culture
+
+**Diagnosis:**
+- Map team goals: Do team OKRs align?
+- Check incentives: What does each team get rewarded for?
+- Review cross-team projects: How often do they succeed?
+
+**Fix: Nested alignment framework (see above)**
+
+Plus:
+- **Cross-team rituals**: Monthly
+
+ syncs on interdependencies
+- **Shared metrics**: At least one metric in common across teams
+- **Rotation**: Engineers rotate across team boundaries
+
+---
+
+## Case Study: Company-Wide Values Refresh
+
+### Context
+
+**Company**: SaaS product, 150 employees, 8 engineering teams
+**Trigger**: Rapid growth (30 → 150 people in 18 months), old startup values not working
+**Old values**: "Move fast", "Customer obsessed", "Scrappy"
+**Problem**: "Move fast" causing production incidents; "Scrappy" justifying technical debt that slows product
+
+### Process
+
+**Month 1: Discovery**
+- Interviewed 40 employees (all levels, all functions)
+- Reviewed 20 major decisions (what values were actually applied?)
+- Surveyed all employees: "What do we truly value? What should we value?"
+
+**Key findings:**
+- "Move fast" interpreted as "ship without testing" (not intended)
+- "Customer obsessed" unclear (speed to market vs quality vs support?)
+- "Scrappy" became excuse for poor tooling
+- **Missing value**: Reliability/trust (now serving enterprise customers)
+
+**Month 2: Leadership Workshop**
+- All directors + exec team (2-day offsite)
+- Reviewed discovery findings
+- Drafted new values + tenets
+- Pressure-tested against real decisions
+
+**New values (refined):**
+1. **Customer trust over growth metrics**
+   - Tenet: "When feature velocity and reliability conflict, reliability wins for core workflows"
+   - Evolution of "customer obsessed" (clarified: long-term trust, not short-term features)
+
+2. **Leverage through platforms**
+   - Tenet: "When team autonomy and platform standards conflict, we choose standards for leverage"
+   - Evolution of "scrappy" (still efficient, but via platforms not point solutions)
+
+3. **Clarity over consensus**
+   - Tenet: "When speed and buy-in conflict, we choose fast decision with clear rationale over slow consensus"
+   - New value (addresses decision paralysis)
+
+**Month 3: Rollout**
+- All-hands (CEO presented, Q&A, examples of how values applied to recent decisions)
+- Team workshops (each team applied to their context)
+- Updated hiring rubric (added values-based questions)
+- Updated performance review (added values section)
+
+**Month 4-6: Reinforcement**
+- Weekly exec team review: "What values-driven decisions did we make?"
+- Monthly all-hands: Celebrate values in action (shoutouts)
+- Quarterly survey: "Are we living our values?"
+
+### Results (6 months later)
+
+**Wins:**
+- Production incidents dropped 60% ("Customer trust" being applied)
+- Engineering happiness up 25% (better tooling via "leverage through platforms")
+- Decision velocity up (no more endless debates, "clarity over consensus")
+- Values referenced in 80% of decision memos (actual usage)
+
+**Challenges:**
+- Some engineers missed "move fast" culture (clarified: fast decisions, deliberate execution)
+- Sales initially confused ("customer trust" seemed to slow deals - clarified: long-term trust creates more deals)
+
+**Evolution (12 months):**
+- Added 4th value: "Default to transparency" (based on feedback)
+- Refined "leverage" tenet (too restrictive, added exceptions for experiments)
+
+### Lessons Learned
+
+1. **Co-create with leadership**: Top-down values fail, need buy-in from leaders who'll model them
+2. **Show the evolution**: Don't reject old values, show how they evolved (honors the past)
+3. **Operationalize fast**: Values are useless without tenets + integration into decisions
+4. **Celebrate examples**: Abstract values need concrete stories of values in action
+5. **Iterate**: Values are living, not static - update based on feedback
+
+---
+
+## Quality Checklist for Scaling Organizations
+
+Before finalizing alignment framework refresh, check:
+
+**Discovery**:
+- [ ] Interviewed stakeholders across levels/functions
+- [ ] Reviewed actual decisions (not just stated values)
+- [ ] Identified gap between stated and actual values
+- [ ] Understood why current values aren't working
+
+**Refinement**:
+- [ ] New values address root causes (not symptoms)
+- [ ] Values evolved from old (honored the past)
+- [ ] Values are specific and actionable (not vague platitudes)
+- [ ] Tenets operationalize values (guide concrete decisions)
+- [ ] Conflicts between values explicitly resolved (priority tenets)
+
+**Multi-Team Alignment**:
+- [ ] Company-wide values clear
+- [ ] Function-level interpretations add specificity
+- [ ] Team practices connect to function/company values
+- [ ] Decision authority matrix defined (what escalates vs local)
+- [ ] Cross-team conflicts have resolution process
+
+**Rollout**:
+- [ ] Leadership aligned and can model values
+- [ ] Communication plan (all-hands, team workshops, 1:1s)
+- [ ] Integration into systems (hiring, perf review, decision memos)
+- [ ] Examples prepared (values in action stories)
+- [ ] Feedback loops established (quarterly check-ins)
+
+**Reinforcement**:
+- [ ] Regular rituals (monthly values spotlights)
+- [ ] Values referenced in decisions (not just posters)
+- [ ] Consequences tied to values (promotions, rewards)
+- [ ] Audit usage quarterly (are values being applied?)
+- [ ] Iterate based on feedback (values evolve)
+
+**Minimum standard for scaling orgs**: All checklist items completed before rollout

skills/alignment-values-north-star/resources/template.md

@@ -0,0 +1,462 @@
+# Alignment Framework Template
+
+## Workflow
+
+Copy this checklist and track your progress:
+
+```
+Alignment Framework Progress:
+- [ ] Step 1: Draft North Star and core values
+- [ ] Step 2: Create decision tenets for common dilemmas
+- [ ] Step 3: Define observable behaviors
+- [ ] Step 4: Add anti-patterns and usage guidance
+- [ ] Step 5: Validate with quality checklist
+```
+
+**Step 1: Draft North Star and core values**
+
+Write 1-2 sentence North Star (where we're going and why) and 3-5 core values with specific definitions, why they matter, what we optimize FOR, and what we de-prioritize. Use [Quick Template](#quick-template) structure and [Field-by-Field Guidance](#field-by-field-guidance) for details.
+
+**Step 2: Create decision tenets for common dilemmas**
+
+Identify 5-10 real trade-offs your team faces and write "When X vs Y, we..." statements. See [Decision Tenets](#decision-tenets) guidance for format. Include specific reasons tied to values and acknowledge merit of alternatives.
+
+**Step 3: Define observable behaviors**
+
+List 10-15 specific, observable actions across contexts: meetings, code/design reviews, planning, communication, hiring, operations. See [Observable Behaviors](#observable-behaviors) for examples. Focus on what you could notice in daily work.
+
+**Step 4: Add anti-patterns and usage guidance**
+
+Document 3-5 behaviors you explicitly DON'T do, even when tempting, and explain which value they violate. Add practical guidance for using framework in decision-making, hiring, onboarding, performance reviews. See [Anti-Patterns](#anti-patterns) section.
+
+**Step 5: Validate with quality checklist**
+
+Use [Quality Checklist](#quality-checklist) to verify: North Star is memorable, values are specific with trade-offs, decision tenets address real dilemmas, behaviors are observable, usable TODAY, no contradictions, 1-2 pages total, jargon-free.
+
+## Quick Template
+
+Copy this structure to create your alignment framework:
+
+```markdown
+# {Team/Organization Name} Alignment Framework
+
+## Context
+
+**Why this matters now:**
+{What triggered the need for alignment? Growth, conflict, new direction?}
+
+**Who this is for:**
+{Team, organization, function - be specific}
+
+**Last updated:** {Date}
+
+---
+
+## North Star
+
+{1-2 sentences: Where are we going and why?}
+
+**Example formats:**
+- "Build {what} that {who} {value proposition}"
+- "Become the {superlative} {thing} for {audience}"
+- "{Action verb} {outcome} by {approach}"
+
+---
+
+## Core Values
+
+### Value 1: {Name}
+**What it means:** {Specific definition in context of this team}
+
+**Why it matters:** {What problem does honoring this value solve?}
+
+**What we optimize for:** {Concrete outcome}
+
+**What we de-prioritize:** {Trade-off we accept}
+
+### Value 2: {Name}
+{Same structure}
+
+### Value 3: {Name}
+{Same structure}
+
+*Note: 3-5 values is ideal. More than 7 becomes unmemorable.*
+
+---
+
+## Decision Tenets
+
+When making decisions, we:
+
+**When choosing between {X} and {Y}:**
+- ✓ We choose {X} because {specific reason tied to values}
+- ✗ We don't choose {Y} even though {acknowledge Y's merit}
+
+**When facing {common dilemma}:**
+- ✓ Our default is {approach} because {value}
+- ⚠ Exception: When {specific condition}, we {alternative}
+
+**When prioritizing {work/features/initiatives}:**
+- 🔴 Critical: {what always gets done}
+- 🟡 Important: {what gets done when possible}
+- ⚪ Nice-to-have: {what we explicitly defer}
+
+*Include 5-10 decision tenets that address real trade-offs your team faces*
+
+---
+
+## Observable Behaviors
+
+**What this looks like in practice:**
+
+**In meetings:**
+- {Specific behavior that demonstrates value}
+- {Specific behavior that demonstrates value}
+
+**In code reviews / design reviews:**
+- {What comments look like}
+- {What we praise / what we push back on}
+
+**In planning / prioritization:**
+- {How decisions get made}
+- {What questions we ask}
+
+**In communication:**
+- {How we share information}
+- {How we give feedback}
+
+**In hiring:**
+- {What we look for}
+- {What's a dealbreaker}
+
+**In operations / incidents:**
+- {How we respond to problems}
+- {What we optimize for under pressure}
+
+---
+
+## Anti-Patterns
+
+**What we explicitly DON'T do:**
+
+- ✗ {Behavior that violates values} - even when {tempting circumstance}
+- ✗ {Common industry practice we reject} - because {conflicts with which value}
+- ✗ {Shortcuts we don't take} - we value {what} over {what}
+
+---
+
+## How to Use This
+
+**In decision-making:**
+{Practical guide for referencing these values when stuck}
+
+**In hiring:**
+{How to interview for these values, what questions to ask}
+
+**In onboarding:**
+{How new teammates should learn these values}
+
+**In performance reviews:**
+{How values factor into evaluations}
+
+**When values conflict:**
+{Which value wins in common scenarios, or how to resolve}
+
+---
+
+## Evolution
+
+**Review cadence:** {How often to revisit - typically annually}
+
+**Who can propose changes:** {Process for updating values}
+
+**What stays constant:** {Core elements that shouldn't change}
+```
+
+## Field-by-Field Guidance
+
+### North Star
+
+**Purpose**: Inspiring but specific direction
+
+**Include:**
+- Who you serve
+- What value you create
+- What makes you distinctive
+
+**Don't:**
+- Be generic ("be the best")
+- Use corporate speak
+- Make it unmemorable
+
+**Length**: 1-2 sentences max
+
+**Test**: Can team members recite it from memory? Does it help choose between two good options?
+
+**Examples:**
+
+**Good:**
+- "Build developer tools that spark joy and eliminate toil"
+- "Make renewable energy cheaper than fossil fuels for every market by 2030"
+- "Give every student personalized learning that adapts to how they learn best"
+
+**Bad:**
+- "Achieve excellence in everything we do" (generic)
+- "Leverage synergies to maximize stakeholder value" (jargon)
+- "Be the world's leading provider of solutions" (unmemorable, vague)
+
+### Core Values
+
+**Purpose**: Principles that constrain behavior
+
+**Include:**
+- Specific definition in your context
+- Why it matters (what problem it solves)
+- Trade-off you accept
+- 3-5 values total
+
+**Don't:**
+- List every positive quality
+- Be generic (every company has "integrity")
+- Ignore tensions between values
+- Go beyond 7 values (unmemorable)
+
+**Structure for each value:**
+- Name (1-2 words)
+- Definition (what it means HERE)
+- Why it matters
+- What we optimize FOR
+- What we de-prioritize (trade-off)
+
+**Examples:**
+
+**Good - Specific:**
+- **Bias to action**: We'd rather ship, learn, and iterate than plan perfectly. We accept some rework to get fast feedback. We optimize for learning velocity over getting it right the first time.
+
+**Bad - Generic:**
+- **Excellence**: We strive for excellence in everything we do and never settle for mediocrity.
+
+**Good - Shows trade-off:**
+- **User delight over enterprise features**: We prioritize magical user experiences for individuals over procurement-friendly enterprise checkboxes. We'll lose some enterprise deals to keep the product simple.
+
+**Bad - No trade-off:**
+- **Customer focus**: We care deeply about our customers and always put them first.
+
+### Decision Tenets
+
+**Purpose**: Actionable guidance for real decisions
+
+**Include:**
+- "When choosing between X and Y..." format
+- Real dilemmas your team faces
+- Specific guidance, not platitudes
+- 5-10 tenets
+
+**Don't:**
+- Be abstract ("choose the best option")
+- Avoid acknowledging trade-offs
+- Make it too long (unmemorable)
+
+**Format:**
+
+```
+When choosing between {specific options your team actually faces}:
+- ✓ We {specific action} because {which value}
+- ✗ We don't {alternative} even though {acknowledge merit}
+```
+
+**Examples:**
+
+**Good:**
+```
+When choosing between shipping fast and perfect quality:
+- ✓ Ship with known minor bugs if user impact is low
+- ✗ Don't delay for perfection
+- ⚠ Exception: Anything related to payments, security, or data loss requires high quality bar
+```
+
+**Bad:**
+```
+When making decisions:
+- Always do what's best for the customer
+```
+
+### Observable Behaviors
+
+**Purpose**: Concrete manifestation of values
+
+**Include:**
+- Specific, observable actions
+- Examples from daily work
+- Things you could notice in a meeting
+- 10-15 behaviors across contexts
+
+**Don't:**
+- Be vague ("communicate well")
+- Only list aspirations
+- Skip the messy details
+
+**Contexts to cover:**
+- Meetings
+- Code/design reviews
+- Planning
+- Communication
+- Hiring
+- Operations/crisis
+
+**Examples:**
+
+**Good:**
+- "In code reviews, we comment on operational complexity and debuggability, not just correctness"
+- "In planning, we ask 'what's the simplest thing that could work?' before discussing optimal solutions"
+- "We say no to features that would compromise reliability, even when customers request them"
+
+**Bad:**
+- "We communicate effectively"
+- "We make good decisions"
+- "We work hard"
+
+### Anti-Patterns
+
+**Purpose**: Explicit boundaries
+
+**Include:**
+- Common temptations you resist
+- Industry practices you reject
+- Shortcuts you don't take
+- 3-5 clear anti-patterns
+
+**Format:**
+```
+✗ {Specific behavior} - even when {tempting situation}
+  Because: {which value it violates}
+```
+
+**Examples:**
+
+**Good:**
+- "✗ We don't add features without talking to users first - even when executives request them. Because: User delight > internal opinions"
+- "✗ We don't skip writing tests to ship faster - even when deadline pressure is high. Because: Reliability > shipping fast"
+
+**Bad:**
+- "✗ We don't do bad things"
+- "✗ We avoid poor quality"
+
+## Quality Checklist
+
+Before finalizing, verify:
+
+- [ ] North Star is memorable (could team recite it?)
+- [ ] Values are specific to this team (not generic)
+- [ ] Each value includes a trade-off
+- [ ] Decision tenets address real dilemmas
+- [ ] Behaviors are observable (not abstract)
+- [ ] Someone could make a decision using this TODAY
+- [ ] Anti-patterns are specific
+- [ ] No contradictions between sections
+- [ ] Total length is 1-2 pages (concise)
+- [ ] Language is clear and jargon-free
+
+## Common Patterns by Team Type
+
+### Engineering Team
+**Focus on:**
+- Technical trade-offs (simplicity, performance, reliability)
+- Operational philosophy
+- Code quality standards
+- On-call and incident response
+- Technical debt management
+
+**Example values:**
+- Simplicity over cleverness
+- Reliability over features
+- Developer experience matters
+
+### Product Team
+**Focus on:**
+- User/customer value
+- Feature prioritization
+- Quality bar
+- Product-market fit assumptions
+- Launch criteria
+
+**Example values:**
+- User delight over feature count
+- Solving real problems over building cool tech
+- Data-informed over opinion-driven
+
+### Sales/Customer-Facing
+**Focus on:**
+- Customer relationships
+- Deal qualification
+- Success metrics
+- Communication style
+
+**Example values:**
+- Long-term relationships over short-term revenue
+- Customer success over sales quotas
+- Honesty even when it costs a deal
+
+### Leadership Team
+**Focus on:**
+- Strategic priorities
+- Resource allocation
+- Decision-making process
+- Communication norms
+
+**Example values:**
+- Transparency by default
+- Disagree and commit
+- Long-term value over short-term metrics
+
+## Rollout & Socialization
+
+**Week 1: Draft**
+- Leadership creates draft
+- Test against recent real decisions
+- Revise based on applicability
+
+**Week 2-3: Feedback**
+- Share with team for input
+- Hold working session to discuss
+- Incorporate feedback
+- Ensure team authorship, not just leadership
+
+**Week 4: Launch**
+- Publish finalized version
+- Present at all-hands
+- Explain rationale and examples
+- Share how to use in daily work
+
+**Ongoing:**
+- Reference in decision-making
+- Include in onboarding
+- Use in hiring interviews
+- Revisit quarterly, revise annually
+- Celebrate examples of values in action
+
+## Anti-Patterns to Avoid
+
+**Vague North Star:**
+- Bad: "Be the best company"
+- Good: "Build developer tools that eliminate toil"
+
+**Generic values:**
+- Bad: "Integrity, Excellence, Innovation"
+- Good: "Simplicity over cleverness, User delight over feature count"
+
+**No trade-offs:**
+- Bad: "Quality is important to us"
+- Good: "We optimize for reliability over shipping speed, accepting slower feature velocity"
+
+**Unmemorable length:**
+- Bad: 10 pages of values, tenets, behaviors
+- Good: 1-2 pages that people can actually remember
+
+**Top-down only:**
+- Bad: Leadership writes values, announces them
+- Good: Collaborative process with team input and ownership
+
+**Set and forget:**
+- Bad: Write values in 2020, never revisit
+- Good: Annual review, update as team evolves