smithery.ai

Culture-as-Product Operating System

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.

Installation

$ npx skills add https://smithery.ai

Similar popular skills

Related neighbors and high-traction skills in the same topics — useful to compare before installing.

Also in this package

Other skills from smithery.ai · top by installs.

npx skills add https://smithery.ai

Browse all from smithery.ai

More details

Agent compatibility

Declared targets from SKILL.md / docs. Unmarked agents are not listed — the skill may still install via the CLI.

Claude Code Not declared
Cursor Not declared
Codex Not declared
GitHub Copilot Not declared
Windsurf Not declared
Gemini CLI Not declared
Cline Not declared
OpenCode Not declared

Package contents

Files included with this skill beyond the listing page.

  • skill md SKILL.md 3,714 B
  • docs SUMMARY.md 215 B

History

  1. First recorded snapshot · 1 installs

SKILL.md

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

┌─────────────────────────────────────────────────────┐
│              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

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