Culture Document

Culture Document

When to Use

Use this skill when:

• A user asks to create a company culture document, values statement, or cultural manifesto from scratch
• A user needs to define or redefine organizational values with concrete behavioral definitions and examples
• A user wants to produce do/don't behavioral examples for each company value to use in hiring, onboarding, or performance conversations
• A user needs to articulate workplace culture for a specific functional purpose -- hiring filter, onboarding anchor, team alignment, or post-acquisition integration
• A user wants to refresh or evolve an existing culture document because the company has grown, pivoted, or changed leadership
• A user's team is experiencing alignment problems (people disagreeing on what "good" looks like) and needs a shared reference
• A user is building out a People Operations function and needs the culture document as a foundational artifact

Do NOT use this skill when:

• The user needs a brand voice or tone guide for external communications -- use voice-tone-guide instead, which governs how the company speaks to customers, not how employees behave internally
• The user wants to write a mission, vision, or purpose statement -- use mission-vision-writing instead; those are forward-looking declarations, not behavioral definitions
• The user needs an employee handbook -- that is a legal document requiring HR/legal review covering policies, benefits, and labor law compliance
• The user needs a code of conduct or ethics policy -- that is a compliance document with legal consequences, not a cultural aspiration document
• The user needs a manager effectiveness guide, a performance review framework, or a competency model -- those are talent management artifacts that reference the culture document but are not the culture document itself
• The user is asking about DEI statements or equity commitments -- those are often standalone documents that intersect with culture but require their own frameworks

Process

1. Gather Context Before Writing Anything

Do not begin drafting until you understand the full picture. Ask or infer from available information:

• Company stage and size: The culture document for a 12-person seed-stage startup and a 300-person Series C company serve fundamentally different purposes and must be written differently
• Industry and work type: A defense contractor, a consumer app startup, and a healthcare SaaS company will have radically different values hierarchies even if they use similar words
• Existing values: If the company has current values, get them. Ask what works about them, what feels hollow, and what is missing -- this tells you what problem the document needs to solve
• The genesis of the request: Someone asking for a culture doc because they just had a toxic team blowup needs a different document than someone building for Series A hiring
• Primary audience and use case: Will this document be used internally for existing employees, as a public recruiting asset, in new hire onboarding, or as a leadership alignment tool? The primary use determines tone, depth, and specificity
• 5-10 real behavioral examples: Ask the user: "Describe two or three people who embody what you value most in your team, and what they do specifically." Then ask: "Describe someone who looked good on paper but did not fit. What specifically did they do or not do?" These answers are the raw material for real values.
• The decision the document needs to enable: A good culture document makes specific decisions easier. Ask: "What are the three hardest trade-off decisions your team faces repeatedly?" The values should help resolve those.

2. Extract Candidate Values from Real Behaviors, Not Abstractions

Most companies make the mistake of starting with values words (integrity, innovation, excellence) and then backfilling examples. This produces generic, unbelievable documents. Work in reverse:

• Collect behavioral evidence first. From the information gathered in Step 1, list 15-20 specific behaviors that describe the best people at this company. Example: "Tomas writes a 1-pager before scheduling any meeting over 20 minutes." "Sarah sends a customer a Loom video the same day a bug is reported, even when there is no fix yet." These are raw culture data.
• Cluster behaviors into themes. Look for natural groupings. Three behaviors around documentation and async communication cluster into a potential value around "written-first communication." Five behaviors around customer contact cluster into a value about customer proximity.
• Apply the distinctiveness test. For each candidate value, ask: "Would 80% of companies in this industry claim this value?" If yes, it is not differentiating enough. "Customer focus" fails the test. "Treat customer problems like production outages" passes.
• Apply the tension test. Every real value implies something you are sacrificing. "We value speed" means you are explicitly trading off some thoroughness. "We value deep work" means you are explicitly trading off immediate responsiveness. If a candidate value has no opposite cost, it is not a real value choice -- it is a virtue.
• Apply the decision test. For each candidate value, construct a real dilemma: "We have a feature 80% done and the customer wants it shipped now, but there are two known bugs. What do we do?" If the value does not help resolve the dilemma, it is decorative.
• Target 4-6 values. Four is enough for a young company. Six is the maximum for any company before values become a wish list. If the user insists on more than six, help them identify which two or three are actually derivatives of the others and consolidate.

3. Write Each Value with Full Behavioral Specification

For each of the 4-6 selected values, develop the full specification before writing the final document. For each value:

• Name the value with a phrase, not a noun. "Default to Writing" is actionable. "Documentation" is not. "Disagree, Then Commit" is directional. "Respect" is not. The name should describe a behavior or a posture, not a character trait.
• Write a one-sentence operational definition that is specific to this company's context. This definition should not be interchangeable with any other company's definition of the same value.
• Define 3-5 specific behavioral indicators -- things you can observe in daily work. These should be verifiable: someone watching the person work could tick them off a checklist.
• Write 2-3 "Do" examples as concrete scenarios, not generic statements. Do not write "communicate proactively" -- write "when you hit a blocker on a customer deliverable, you send a heads-up Slack message to the account team before the customer asks, even if you think you can resolve it by tomorrow."
• Write 2-3 "Don't" examples with equal specificity. "Don't" examples are often more clarifying than "Do" examples because they define the boundary. Write them as scenarios, not prohibitions.
• Write a decision test question -- a single question that uses this value as a lens to resolve a real ambiguity the team actually faces. The quality of this question is the best test of whether the value is real.
• Write a one-sentence "who we are not" statement for this value. "This does not mean we never have meetings -- it means every meeting has a written purpose and a written outcome." These statements prevent misapplication of the values.

4. Map Value Conflicts and Hierarchy

This is the section most culture documents omit, and its omission is why most culture documents fail. Values only matter when they conflict. A culture document that lists values without addressing their tensions is an aspiration poster, not a decision tool.

• Identify the two or three most common conflicts among the values you have selected. For example, if the values include both "Move Fast" and "Customer Trust," there will be moments when shipping fast creates customer trust problems. If values include both "Radical Transparency" and "Psychological Safety," there will be moments when brutal honesty creates safety issues.
• Establish a hierarchy for each conflict pair. Do not say "both values are important." That is unhelpful. State which value takes priority under which conditions. "When speed and quality conflict on customer-facing features, quality wins. When speed and quality conflict on internal tools, speed wins." This specificity is what makes the document useful.
• Write 2-3 worked scenarios. Each scenario presents a real dilemma and walks through how the values hierarchy resolves it. These scenarios should be drawn from the company's actual experience or plausible near-future situations.
• Acknowledge the emotional cost of real values. If the company values autonomy over consensus, acknowledge that this means some people will feel unheard. If the company values speed over perfection, acknowledge that bugs will ship and that is a conscious choice. Pretending values have no downsides destroys credibility.

5. Embed Values in Organizational Practices

A culture document that is not connected to how people are hired, evaluated, rewarded, and exited is a piece of marketing, not a management tool. For each value, identify at minimum one organizational practice where it is applied:

• Hiring: Define the interview question or exercise that reveals whether a candidate demonstrates each value. For "Default to Writing," the practice might be: "We ask every candidate for a written work sample and evaluate it before any interview. We do not advance candidates who cannot produce clear writing, regardless of their verbal performance in interviews." Giving the interviewer a specific signal to look for (not just "does this person seem like a culture fit") is what makes values operational.
• Onboarding: Define the specific week-one or month-one experience where each value is introduced through practice, not lecture. A company that values "Customer Proximity" might require every new hire, including engineers, to shadow two customer calls in week one. Name the specific practice.
• Performance reviews: Define whether and how values-aligned behavior is evaluated separately from performance outcomes. Many companies evaluate "what you achieved" but not "how you achieved it." If values matter, they need their own dimension in the review.
• Recognition: Define the specific recognition mechanism -- an award, a shout-out format, a quarterly spotlight -- tied explicitly to values-aligned behavior. Recognition that is not tied to values teaches people that values are optional.
• Exit and accountability: This is the hardest and most important practice to define. If someone is achieving their numbers but consistently violating values, what happens? The answer must be explicit and must be followed. Companies that protect high performers from values accountability undermine the entire document within months.

6. Write for the Specific Audience and Tone

The same values content should be written differently depending on the primary audience and the cultural tone of the company:

• For internal use (existing employees): Write in direct, peer-to-peer language. Use "we" and assume shared context. Include examples that reference real situations the team has navigated. The document should feel like it was written by someone who works there, not an HR consultant.
• For recruiting and public use: Write to give candidates an honest picture of what it is actually like to work there -- including what is hard. The best culture documents for recruiting say something like: "People who struggle here typically find the lack of consensus-seeking exhausting." That kind of honesty attracts the right candidates and repels the wrong ones. This is more valuable than a document that tries to appeal to everyone.
• For onboarding: Write with more context and more examples. Pair each value with a "questions to discuss with your manager" section. Onboarding readers need enough specificity to translate the values into their specific role.
• Match tone to culture. If the company is a creative studio that values play and irreverence, the culture document written in corporate HR language will immediately signal that the values are not real. If the company is a clinical health data company that values precision and rigor, a whimsical culture doc will unsettle candidates. The document's voice is itself a demonstration of the culture.
• Aim for 1,500-3,000 words for the core document. Longer than 3,000 words means no one will read it. Shorter than 1,000 words means the behavioral definitions are probably too thin to be useful.

7. Build in the Evolution Mechanism

Culture documents that are not reviewed die. They become monuments to a past era, and the gap between the document and actual behavior erodes trust in the entire People function. Every culture document must include:

• A review cadence: Annual review is the standard for companies growing under 30% per year. Companies growing faster than 50% per year or undergoing significant structural change (acquisition, leadership change, pivot) should review every six months.
• A named owner: Someone is responsible for initiating and driving the review. Usually the Head of People, the CEO, or a People Committee.
• A defined input process: Who participates? What is the mechanism for gathering feedback? Employee surveys, focus groups, leadership retrospectives? The process should gather both "what is working" and "what no longer reflects reality."
• Change documentation: When a value is added, modified, or retired, record why. This institutional memory is valuable -- it explains why "we used to value X" and helps the team understand the company's development arc.
• A versioning convention: Culture Document v2.1, Last Updated Q3 2024, is more credible than a document with no date. Versioning signals that the document is a living artifact, not a monument.

Output Format

# [Company Name] Culture Document
*Version [X.X] -- Last Updated [Month Year]*

---

## Who We Are

[Paragraph 1: 4-6 sentences describing what the company does, who the team is, 
and what stage the company is at. Write in first-person plural. 
This is identity, not marketing.]

[Paragraph 2: 4-6 sentences describing who thrives here. 
Be specific about the work style, communication style, and orientation 
that succeeds. Name what makes this company's culture distinct from 
the default culture of its industry.]

[Paragraph 3: 3-4 sentences describing who struggles here. 
This is the most important paragraph in the "Who We Are" section 
and the one most companies omit. Be honest without being unkind.]

---

## Our Values

### [Value 1 Name: Written as a Phrase or Directive]
**Definition:** [One sentence. Specific to this company. Not interchangeable 
with any other company's version of this value.]

**What this means in practice:**
- [Observable behavioral indicator 1]
- [Observable behavioral indicator 2]
- [Observable behavioral indicator 3]
- [Observable behavioral indicator 4, if relevant]

| Do | Don't |
|----|-------|
| [Specific scenario showing the value in action] | [Specific scenario showing behavior that violates the value] |
| [Second scenario] | [Second violation scenario] |
| [Third scenario, if needed] | [Third violation scenario, if needed] |

**Decision test:** "[A question that uses this value to resolve a real 
dilemma this company actually faces]"

**This does not mean:** [One sentence clarifying the most common 
misapplication or misreading of this value]

---

### [Value 2 Name]
*(same structure as above)*

---

### [Value 3 Name]
*(same structure as above)*

---

### [Value 4 Name]
*(same structure as above)*

---

*(Repeat for Values 5 and 6 if applicable)*

---

## When Our Values Conflict

*Real values create real tensions. Here is how we navigate the most common conflicts.*

### [Value A] vs. [Value B]
**The tension:** [2-3 sentences describing when and why these two values 
pull in opposite directions. Give a real scenario.]

**How we resolve it:** [Which value takes priority under which conditions. 
Be specific. "It depends" is not an answer. Name the condition that 
tips the balance.]

**Worked example:** [A concrete situation and the decision the team made 
or would make, and why.]

---

### [Value C] vs. [Value D]
*(same structure)*

---

### [Value E] vs. [Value F] *(if applicable)*
*(same structure)*

---

## How We Live These Values

| Practice | What This Looks Like in Action |
|----------|-------------------------------|
| **Hiring** | [Specific interview practice, exercise, or signal for each value. Name the method, not just the intent.] |
| **Week One Onboarding** | [Specific experience or assignment that introduces new hires to the values through practice, not lecture.] |
| **Performance Reviews** | [How values-aligned behavior is evaluated. Is it a separate dimension? What does "meets expectations" look like for each value?] |
| **Recognition** | [Named recognition mechanism tied explicitly to values-aligned behavior. What is it called? How often does it happen?] |
| **Accountability** | [What happens when behavior consistently violates values. Who has the conversation? What is the process? What is the threshold?] |

---

## Evolution

- **Current version:** [X.X]
- **Last reviewed:** [Month Year]
- **Review cadence:** [Annual / Semi-annual / As triggered by structural change]
- **Review owner:** [Role -- not a name, roles persist; names change]
- **Input process:** [How feedback is gathered: survey, focus groups, leadership retrospective, combination]
- **Change log:**
  - [Version X.X, Date]: [What changed and why]
  - [Version X.0, Date]: [Original publication context]

Rules

1. Never write a value as a single abstract noun. "Integrity," "Excellence," "Innovation," and "Respect" are statements of virtue, not behavioral guidance. Every company claims them and none of them help anyone make a decision. Rewrite every abstract noun as a phrase that describes a posture or a behavior: "Earn Trust Daily," "Ship, Then Improve," "Say the Hard Thing."

2. Every value must pass the distinctiveness test. Before finalizing a value, ask: "Would 80% of companies in this industry claim this value on their website?" If yes, the value is not earning its place in the document. The test of a great value is not that it sounds good -- it is that it would surprise someone from a competitor company.

3. Every value requires both a Do and a Don't example, written as specific scenarios. A Do example without a Don't example is an aspiration. The Don't example defines the behavioral boundary. Write Don't examples as scenarios, not prohibitions. "Don't avoid hard conversations" is a prohibition. "When you disagree with a decision in a planning meeting but say nothing and then complain about it in a 1:1 afterward, that violates this value" is a scenario.

4. Values must create observable, evaluable behavior. For every value in the document, it must be possible for a manager to say "that behavior is consistent with this value" or "that behavior is not consistent with this value" based on what they actually observe. If a value only exists inside someone's head and cannot be observed in their actions, it is not a usable value.

5. The value conflict section is mandatory, not optional. Any company that claims to have values but does not address what happens when those values conflict does not actually have a values hierarchy -- they have a wish list. The conflict section is the most operationally useful part of the document. Do not skip it, do not abbreviate it.

6. Limit the document to 4-6 values. This is a hard ceiling, not a suggestion. A company with 8 values has 8 priorities, which means it has no priorities. When a user pushes back and wants to include more values, help them identify which values are derivatives of others and consolidate. "Transparency" and "Radical Candor" and "Direct Feedback" are three names for one value. Pick one name and define it richly.

7. The document's tone must demonstrate the culture it describes. This is a form of internal proof. A culture document that claims "We value warmth and humor" written in cold, bureaucratic HR language fails the proof test immediately. A culture document that claims "We are rigorous and precise" written with typos and vague language fails the proof test. The tone is the first behavioral evidence the reader encounters.

8. Every value must be connected to at least one named organizational practice. A value that is not embedded in hiring, onboarding, performance evaluation, or recognition is a decoration. If the company cannot name the specific mechanism by which a value is assessed or rewarded, that value will not survive six months of real organizational pressure. Push the user to name the practice. "We'll figure that out later" means the value is not real.

9. Include the "who struggles here" paragraph. This is the section most companies refuse to write, and it is the section that makes the entire document credible. A culture document that describes only people who thrive is a sales brochure. A culture document that honestly describes who does not fit helps candidates self-select accurately and helps managers have hard conversations with a shared reference.

10. Include a version number and review date. A culture document without a date is a document that cannot be trusted. It may describe a company that no longer exists. Version numbers and review dates signal that the document is maintained, that someone owns it, and that it reflects the current state of the company -- not the ideals of a founding moment that may be years in the past.

Edge Cases

Early-Stage Startup (Fewer Than 15 People)

At this stage, culture is implicit -- it lives in the founders' behavior, not in documents. The culture document's primary purpose is to externalize and test what the founders actually believe so it can become a hiring filter for the next 10-30 hires.

Keep the document short: one page is ideal, two pages is the maximum. Founders at this stage often try to write the culture document they wish they had, not the culture document that describes the company they actually built. Push them to write what is already true, not what they aspire to become.

Acknowledge explicitly in the document that values will evolve as the team grows. This is not weakness -- it is honesty, and candidates will respect it. Include a single sentence like: "This document reflects our values as a team of 12. We expect to revisit it at 40 and again at 100."

The most important question for a founding team to answer is: "What would cause us to not hire a candidate even if they were technically exceptional?" The answer to that question is the culture document.

Company Undergoing a Culture Change

This is the highest-stakes culture document scenario. A company that has survived a toxic period, a leadership change, or a significant values failure needs a culture document that acknowledges the past without being paralyzed by it.

Do not write a new culture document that ignores the old culture. Acknowledge what the company was, what caused the change, and what the new values replace. "We used to reward individual heroics over team coordination. We are explicitly moving away from that because it created burnout and inconsistency. Our new value [X] directly addresses this." This kind of explicit before/after language is credible in a way that a fresh-start document is not.

Identify which elements of the old culture should be preserved. Most cultural change is not total -- there are usually 1-2 values from the prior era that were genuinely good and should be honored in the new document. Continuity alongside change is more credible than a complete break.

Build in a 90-day check-in, not just an annual review. Culture change documents need a shorter feedback loop while the new norms are being established. Name who will conduct the check-in and what questions they will ask.

Post-Acquisition Integration

This is one of the most common and most botched culture document scenarios. The acquirer's instinct is to impose their culture document on the acquired team. This produces resentment, attrition of the acquired company's best people (who joined specifically because of the acquired company's culture), and the destruction of the thing that made the acquisition valuable in the first place.

Instead, run a values mapping exercise before writing any document. Identify: (a) values that both companies share with similar behavioral definitions -- these are easy wins and should anchor the integrated document, (b) values that both companies claim but define differently -- these are the most dangerous conflicts and need explicit reconciliation, and (c) values that are unique to each culture -- these need to be assessed: are they complementary, compatible, or genuinely incompatible?

Write an integration-phase document that is explicitly temporary -- "This document represents our values during the integration period. We will publish a unified culture document by [date]." This buys time for genuine integration rather than forced assimilation.

Remote-First or Async-First Company

Remote-first companies have an elevated dependency on written communication, explicit norms, and documented decisions because the ambient cultural transmission that happens in shared physical space -- overhearing how a manager handles a conflict, watching how a team celebrates a win -- does not happen naturally.

Values around communication, documentation, and autonomy become load-bearing in a way they are not for co-located teams. The culture document must be more specific about behavioral norms in these areas because the default behavior is not visible. "We trust each other to get things done" is an aspiration. "When you take on a task, you post a 24-hour update in the relevant channel even if there is nothing new to report" is a behavioral norm.

Address time zone equity explicitly. If the company spans multiple time zones, the culture document should name the norm around scheduling, response time expectations, and how decisions get made when the team is not all online simultaneously. This is often a genuine values question: does the company optimize for real-time collaboration and accept that this disadvantages people in certain time zones, or does it optimize for async-first and accept slower decision cycles?

Highly Regulated Industry (Healthcare, Finance, Legal, Defense)

Compliance is not a culture value. It is a legal minimum. Writing "we follow the rules" as a value insults the team and signals to regulators that the company does not understand the distinction between minimum standards and genuine culture.

In highly regulated industries, the culture document should address how the team operates with excellence within regulatory constraints -- the values that determine how the company goes beyond compliance. For example: "We document decisions not because the regulator requires it but because we believe transparency is how we build trust with each other and with our customers" is a culture value. "We comply with HIPAA" is a legal requirement that belongs in the compliance handbook.

Explicitly separate the culture document from the compliance handbook in the document itself: "This document covers how we work and who we are. It does not cover legal, regulatory, or compliance requirements. Those are covered in [link to compliance handbook]." This distinction protects the culture document from being read as a legal document and protects the company from the culture document being cited as a policy in legal proceedings.

Founder Who Wants to Document Their Own Personality as Company Culture

This is a common failure mode, especially at early-stage companies where the founder's behavior is the de facto culture. A culture document that is essentially a personality profile of the founder has a lifespan equal to the founder's tenure and often shorter.

When this pattern emerges -- often recognizable because all the values sound like compliments to the founder and every example is something the founder would personally do -- redirect toward values that would survive the founder's departure. Ask: "If you were hit by a bus tomorrow, which of these values would your team be able to carry forward on their own?" Values that depend on the founder's presence for definition are not organizational values -- they are management style preferences.

Separate the founder's personal operating style from the organizational values. The founder's preference for long-form memos may be a personal style. The organizational value might be "we respect each other's time by communicating with precision and context" -- which can survive many different formats.

Example

Input: "We're a 40-person remote SaaS startup, Series A, building compliance automation software for mid-market financial services companies. Our two founders came from Goldman Sachs and Plaid. We really care about: writing everything down (we're async-first across 4 time zones), shipping fast and learning from real users rather than planning forever, being radically direct in feedback (no politics, no passive aggression), and treating our customers as genuine partners in product decisions, not just users. We also have something around deep craft -- we want people who take genuine pride in the quality of their work, not just shipping features. Help us create our culture document. The primary audience is candidates we're hiring and new employees in onboarding."

Output:

Meridian Culture Document

Version 1.0 -- Last Updated January 2025

Who We Are

We are 40 people building software that removes compliance friction from financial services companies that have historically needed 10-person risk teams to do what our product handles automatically. We work across four time zones without a headquarters, which means everything important lives in writing, and the people who thrive here are the ones who have made writing a core professional skill -- not a chore.

We were built by people who came from institutions (Goldman Sachs, Plaid) and left because we believed the best work in financial technology comes from small, fast, opinionated teams who stay close to customers. We are not trying to become a Goldman Sachs. We are trying to build the thing those institutions cannot build because they are too large and too slow. That context shapes everything about how we work.

People who thrive at Meridian write before they talk, ship before they are certain, and say what they think directly -- to a customer, to a co-founder, to anyone. They take deep personal pride in the quality of their work and hold their colleagues to the same standard, not punitively but as a form of respect. They treat our customers as collaborators who know things we do not. People who struggle here find async communication isolating, prefer building in private until something is perfect, or find directness uncomfortable. This is not the right environment for every talented person -- and knowing that early saves everyone time.

Our Values

1. Write It Down, Write It Well

Definition: We default to written communication because it scales across time zones, creates a decision record, and forces clarity of thought that verbal communication rarely requires.

What this means in practice:

• Major proposals are written as 1-pagers before a meeting is scheduled, not after
• Decisions are documented in Notion within 24 hours of being made, even when everyone in the room already agreed
• Meeting notes with specific action items and owners are posted in the relevant Slack channel by the person who called the meeting
• "Let me set up a call" is not the default response to complexity -- the default is a written async update with a specific question at the end

Decision test: "If someone joins Meridian in 18 months and needs to understand why we made this decision, can they find a written record that explains the reasoning -- not just the outcome?"

This does not mean: Every interaction requires documentation. Casual Slack messages, quick questions, and social conversation do not need to be written up. Write It Down applies to decisions, proposals, and information that affects more than two people or that someone will need to reference later.

2. Ship to Learn, Not to Polish

Definition: We ship working software into the hands of real customers to generate learning, not to demonstrate perfection, because customer feedback is more reliable than internal conviction.

What this means in practice:

• A feature in front of 10 customers for one week teaches us more than 3 weeks of internal review
• Known non-critical issues (cosmetic bugs, edge cases that affect fewer than 5% of use cases, copy that is "good enough") do not block a release
• Every significant feature has a defined success metric agreed before shipping, so we know within two weeks whether the learning was positive or negative
• "Let's test it" is a legitimate answer to product debates that data cannot resolve in advance

Decision test: "Is this good enough for a real customer to use and give us honest feedback on? If yes, ship it. If no, what is the one thing blocking that threshold?"

This does not mean: We ship broken software or compromise on the things our customers depend on for their regulatory compliance. Financial services compliance software has a higher quality floor than most SaaS products. "Ship to Learn" applies to new features and UX improvements -- it does not apply to the accuracy of our compliance logic, which is never "good enough to test."

3. Say It Directly

Definition: We communicate disagreement, concern, and critical feedback directly to the person who needs to hear it, in a way that respects them as a professional capable of handling honesty.

What this means in practice:

• Feedback is given to the person, not about them to a third party
• "I think this is a mistake and here's why" is a complete, professional sentence -- it does not require softening into ambiguity
• Disagreement in a meeting is expressed in the meeting, not in a separate conversation afterward
• "Diplomatic but honest" is the target -- directness is not license for unkindness, condescension, or public humiliation

Decision test: "Am I saying this to the person who can act on it, and am I saying it clearly enough that they understand specifically what I am concerned about and why?"

This does not mean: Directness is a license for aggression, cruelty, or public criticism of individuals. "Say It Directly" operates with full respect for the person's dignity. Feedback about work performance is given privately unless the person explicitly invites public feedback. Directness and warmth are not opposites.

4. Customers Are Collaborators

Definition: We treat customers as partners who hold knowledge about their domain that we do not have, and we build in genuine dialogue with them -- not for them, not at them.

What this means in practice:

• Every product manager and engineer has at least two customer conversations per month -- not handed off to Sales or Customer Success, direct
• Customer objections and complaints are treated as product intelligence, not as support tickets to be closed
• When a customer asks for something, the first question is "what outcome are you trying to achieve?" before the second question is "how would you build it?"
• Beta customers receive early access with an explicit request for critical feedback, not a polished preview designed to impress them

Decision test: "Would our three most engaged customers be surprised by this decision, and if yes, have we given them the chance to weigh in before we committed to it?"

This does not mean: Every customer request becomes a feature, every customer complaint becomes a priority, or that the customer is always right about what they should build. "Collaborator" means we are genuinely in dialogue. It does not mean we outsource our product judgment to customers who do not see the full picture.

5. Take Pride in the Craft

Definition: We hol

…(truncated)