| name | culture-document |
| description | Creates a company culture document with organizational values, behavioral definitions, do and don't examples for each value, and practical application guidelines. Use when the user asks about culture documents, company values, organizational culture, values definition, or behavioral standards.
Do NOT use for employee handbooks, code of conduct, brand voice guides (use voice-tone-guide), or mission and vision statements (use mission-vision-writing).
|
| license | Apache-2.0 |
| metadata | {"author":"foundry-skills","version":"1.0.0","tags":"template strategy planning guide branding","category":"business-strategy","subcategory":"human-resources","depends":"","disclaimer":"none","difficulty":"intermediate"} |
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.]
[Which value takes priority under which conditions.
Be specific. "It depends" is not an answer. Name the condition that
tips the balance.]
[A concrete situation and the decision the team made
or would make, and why.]
---
---
---
| Practice | What This Looks Like in Action |
|----------|-------------------------------|
| | [Specific interview practice, exercise, or signal for each value. Name the method, not just the intent.] |
| | [Specific experience or assignment that introduces new hires to the values through practice, not lecture.] |
| | [How values-aligned behavior is evaluated. Is it a separate dimension? What does "meets expectations" look like for each value?] |
| | [Named recognition mechanism tied explicitly to values-aligned behavior. What is it called? How often does it happen?] |
| | [What happens when behavior consistently violates values. Who has the conversation? What is the process? What is the threshold?] |
---
[X.X]
[Month Year]
[Annual / Semi-annual / As triggered by structural change]
[Role -- not a name, roles persist; names change]
[How feedback is gathered: survey, focus groups, leadership retrospective, combination]
[Version X.X, Date]: [What changed and why]
[Version X.0, Date]: [Original publication context]
Rules
-
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."
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
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
| Do | Don't |
|---|
| Write a 300-word Notion doc summarizing a product decision before you Slack the team about it | Make a significant architectural or product decision in a DM thread that the rest of the team cannot find in six months |
| Post a written status update on a long-running project every Monday, even when nothing has changed -- "no change, still on track for Friday" is useful information | Schedule a 30-minute team meeting to share information that could have been a 200-word async update |
| When you disagree with a proposal in a Slack thread, write your objection as a complete argument -- not "I'm not sure about this" but "I think this approach creates a compliance documentation problem because X, here's an alternative" | Take important feedback to a verbal conversation and then let it disappear without a written record of what was said and agreed |
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
| Do | Don't |
|---|
| Ship an audit log feature to 20% of customers on Thursday with a known UI inconsistency that does not affect functionality, measure engagement over 5 days, and use the data to decide whether to invest in refinement | Spend three weeks perfecting a compliance dashboard before any customer has seen it, then discover in user research that they navigate from a different entry point |
| Release a beta invite to your three most engaged customers for a feature you are 70% confident in, with an explicit "we want your feedback before we finalize this" framing | Hold a launch because the error message copy is not finalized or the empty state illustration is not ready |
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
| Do | Don't |
|---|
| In a product review, say "I think we're solving the wrong problem here -- our customers have told us X is the friction point, not Y. Can we talk about pivoting this sprint?" | Nod along in the product review, then message a colleague afterward: "I really don't think that's going to work" |
| Tell a candidate during hiring debrief "I don't think they can do this job at the level we need -- here are the three specific things that gave me that signal" | Say "I have some concerns" without naming them, or let a weak hire through because you did not want to create friction in the debrief |
| When a customer asks for a feature that you think is the wrong solution to their problem, say "We could build exactly what you're asking for, but I think it will create a different problem. Can I show you what we're seeing from customers with the same underlying issue?" | Build what the customer asked for without raising the concern, then be surprised when they do not use it |
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
| Do | Don't |
|---|
| When three customers ask for the same feature, schedule a working session with all three to map the underlying workflow problem before writing a single line of spec | Take three identical feature requests, build the feature as literally described, ship it, and wonder why adoption is low |
| When a customer reports a compliance edge case your software handles incorrectly, treat it as critical product intelligence -- schedule a call that week, understand the regulatory context, fix it, and share the learning with the product team | Classify the report as a support ticket, assign it to a queue, resolve the technical issue without investigating the underlying regulatory gap |
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 hold ourselves to a quality standard that goes beyond "does it work" to "does it reflect the level of precision and care our customers trust us to apply to their compliance programs."
What this means in practice:
- Code review comments address not just correctness but clarity -- is this code that the next engineer will understand in 18 months?
- Documentation written for customers is held to the same standard as documentation written for regulators -- because for our customers, they may be the same thing
- When you find a problem adjacent to the one you were assigned to fix, you fix it or flag it -- you do not close the ticket and move on
- "Good enough to ship" (Value 2) and "take pride in the craft" are both true: we ship fast on scope, but we do not compromise on quality within that scope
| Do | Don't |
|---|
| Spend 20 extra minutes to refactor a brittle function while you are already in that part of the codebase, because you know it will break in six months when the compliance logic expands | Merge code that you know has a structural problem because "we can fix it in the next sprint" -- and the next sprint comes and the fix never does |
| When you receive a customer-facing error message in a bug report, fix the underlying bug and improve the error message copy so the next customer understands what happened and what to do | Fix the bug, close the ticket, and leave the error message as "Unexpected error occurred" |
Decision test: "If a compliance officer at one of our customers saw how we built this -- not just what it produces but how we built it -- would they trust us more or less?"
This does not mean: We spend unlimited time on perfection before shipping. "Take Pride in the Craft" is about the standards we apply within the scope we have committed to. It is not a license to expand scope indefinitely in pursuit of an ideal version that never ships.
When Our Values Conflict
These are the tensions we actually navigate. The resolutions below are our defaults -- not rules, but the starting point for decision-making.
Shipping Fast (Value 2) vs. Taking Pride in the Craft (Value 5)
The tension: Moving fast to generate learning sometimes means shipping with known rough edges. Taking pride in craft means holding to a quality standard. These two values are in direct tension on almost every feature we build.
How we resolve it: The distinction is between scope and quality. We ship fast on scope -- we cut features, reduce surface area, limit the initial use cases. We do not compromise on quality within the scope we commit to. A feature with half the functionality built precisely is better than a feature with all the functionality built sloppily. When in doubt, ship less -- not worse.
Worked example: We were building an audit export feature with three export formats (PDF, CSV, Excel). Two weeks into the sprint, PDF and CSV were solid; Excel had known formatting issues in edge cases. We shipped PDF and CSV, cut Excel from the initial release, and shipped Excel three weeks later when it was right. We did not ship Excel in a broken state because "it mostly works."
Say It Directly (Value 3) vs. Customers Are Collaborators (Value 4)
The tension: Direct communication means telling customers when they are wrong -- that their feature request solves the wrong problem, that their compliance interpretation is off, that what they are asking us to build will not achieve what they want. But treating customers as collaborators means honoring their domain expertise and building in genuine partnership. These values conflict when the customer is wrong about something they believe they know.
How we resolve it: Directness comes before deference, but always paired with genuine curiosity. "I think you might be approaching this from the wrong angle -- here's what I'm seeing from your workflow. Can you help me understand if I'm missing something?" This is direct (we are raising a challenge) and collaborative (we are inviting their expertise to correct us). We never stay silent about a disagreement with a customer to preserve the relationship. We raise it. We do it respectfully.
Worked example: A customer asked us to build a manual override feature that would allow their compliance team to mark a transaction as reviewed without actually completing the review workflow. We believed this would create a regulatory documentation gap that could expose them in an audit. We told them directly: "We think this creates a risk you don't want. Here's the specific regulatory provision we're concerned about." They pushed back. We scheduled a call with their General Counsel. The GC agreed with our read. We built a different solution. The customer thanked us six months later.
Write It Down (Value 1) vs. Ship to Learn (Value 2)
The tension: Thorough written documentation before shipping -- decision records, proposal docs, post-mortems -- takes time that slows down the learning cycle. Sometimes the fastest way to learn is to just ship and observe.
How we resolve it: Documentation is required for decisions (what we chose and why) but not for explorations (what we tried to see if it worked). The rule: if a decision will be hard to reverse or will affect more than five people, write it down before you execute. If you are running an experiment to generate learning, ship first, document the learnings after. The writing requirement applies to the decision layer, not the exploration layer.
How We Live These Values
| Practice | What This Looks Like at Meridian |
|---|
| Hiring | Every candidate for any role submits a written work sample as part of the application -- a writing prompt relevant to the role. We do not advance candidates who cannot produce clear, precise writing regardless of their verbal performance in interviews. During debrief, we require each interviewer to state a specific "yes" signal and a specific "concern" signal -- "they seem great" is not a valid debrief contribution. |
| Week One Onboarding | Every new hire -- engineer, designer, PM, and GTM -- joins two customer calls in their first 10 days. Not to observe Sales, but to listen to customers describe their compliance problems in their own words. New hires also write a "First Impressions" Notion doc in week two: what was unclear, what surprised them, what seemed off. This is a core input into improving onboarding. |
| Performance Reviews | We evaluate on two dimensions separately: what you delivered (output) and how you worked (values). A high performer who consistently delivers but violates values -- especially directness and craft -- does not receive a full performance rating. The values dimension uses specific behavioral evidence gathered over the review period, not impressions. |
| Recognition | Monthly "Craft Moment" spotlight in the all-hands: one example per month of someone demonstrating a value in a specific, observable way. Nominated by peers, described with behavioral specificity. "Sarah gets this month's Craft Moment for rewriting three customer-facing error messages the same week she resolved the underlying bugs -- the kind of detail that doesn't make the sprint notes but matters to our customers." |
| Accountability | When behavior consistently violates a value -- especially Say It Directly (passive aggression, political behavior) or Take Pride in the Craft (repeated cutting of corners) -- the manager has a direct conversation within one week of identifying the pattern, naming the specific behaviors. If the pattern continues after two documented conversations, it becomes part of the formal performance process. High output does not protect against values accountability. |
Evolution
- Current version: 1.0
- Last reviewed: January 2025
- Review cadence: Annual, with an additional review triggered by any of: headcount exceeding 100, a leadership change at the co-founder or executive level, a significant product pivot, or acquisition
- Review owner: Head of People, in partnership with the founding team
- Input process: Company-wide values survey (anonymous) in November, focus groups with 3-4 cross-functional groups of 6-8 people in December, leadership synthesis session in January
- Change log:
- v1.0, January 2025: Initial publication. Five values established. Reflects culture of 40-person remote team post-Series A.
