AgentSkillsCN

Culture-as-Product Operating System

将企业文化视为一款专为员工打造的产品，通过反馈循环不断迭代优化，及时发现并修复“漏洞”，而非一味固守某一静态版本。

SKILL.md
--- frontmatter
name: Culture-as-Product Operating System
description: Treat company culture as a product you build for employees. Iterate on it using feedback loops (NPS), identify bugs, and evolve it—don't try to preserve a static version.

Culture-as-Product Operating System

"Every company builds two products: one is the product they build for their customers, and the other is a product they build for their team. That's what culture is." — Dharmesh Shah

What It Is

Treat company culture as the "product" you build for employees (your customers). Just as you wouldn't freeze code on a product, you shouldn't freeze culture.

When To Use

  • •Scaling beyond the founding team
  • •When employee sentiment begins to drift
  • •Culture feels like "HR fluff" or posters on walls
  • •Need to evolve culture while preserving core values

The Operating System

code
┌─────────────────────────────────────────────────────┐
│              CULTURE-AS-PRODUCT OS                  │
├─────────────────────────────────────────────────────┤
│  INPUT: Employee Feedback (NPS surveys)             │
│     ↓                                               │
│  TRIAGE: Identify "bugs" in the culture             │
│     ↓                                               │
│  DECISION: Fix or mark "Works as Designed"          │
│     ↓                                               │
│  OUTPUT: Updated cultural practices                 │
├─────────────────────────────────────────────────────┤
│  FEDERAL LAWS: Non-negotiable core values           │
│  STATE LAWS: Team-specific adaptations              │
└─────────────────────────────────────────────────────┘

Core Principles

1. Run Employee NPS

Measure satisfaction quantitatively (0-10) and qualitatively (Why?).

2. Identify Bugs

Treat cultural complaints as "bugs" in the product. Acknowledge them publicly.

3. Fix or "Won't Fix"

Commit to fixing valid bugs, OR explicitly state "It works as designed" (e.g., "Yes, transparency is uncomfortable, but it's a feature, not a bug").

4. Federal vs. State Laws

  • •Federal Laws: Non-negotiable core values (e.g., transparency)
  • •State Laws: Team-level adaptations (e.g., Sales floor noise vs. Engineering quiet)

How To Apply

code
STEP 1: Measure Regularly
└── Quarterly eNPS surveys
└── Anonymous feedback channels

STEP 2: Triage at All-Hands
└── "Here are the bugs you reported..."
└── Public acknowledgment builds trust

STEP 3: Categorize Each Bug
└── Will Fix: Prioritize and timeline
└── Won't Fix: Explain why it's intentional
└── Feature Request: Add to backlog

STEP 4: Ship Updates
└── Announce culture changes like product releases
└── Measure impact in next survey

Common Mistakes

❌ Thinking the job is to preserve culture (it's to evolve it)

❌ Ignoring feedback because "culture can't be changed"

❌ Making everything a "Federal Law" (no team autonomy)

Real-World Example

HubSpot's transparency policy (making everyone an "insider") was a Federal Law, but seating arrangements evolved from lottery-based to team-based as the company scaled.

Source: Dharmesh Shah, Lenny's Podcast