Keep an orgtology.

Your company has context. It’s just not written down.

Orgtology is the practice of maintaining a living document - orgtology.md - that maps how your organization actually works. Plain markdown. One file. Always current.

orgtology.mdUpdated 2h ago
Palette
# orgtology.md
> Last updated: 2026-02-07 | Maintained by: Palette
> Version: Weekly - auto-synced from Linear, Slack, Notion, Calendar, GitHub

---

## Organization

| Field | Value |
|-------|-------|
| **Company** | Acme Corp |
| **Stage** | Series A (raised $12M, Aug 2025) |
| **Headcount** | 47 |
| **Business Model** | B2B SaaS - project management for construction teams |
| **HQ** | Copenhagen, Denmark |
| **Work Policy** | Remote-friendly, core hours 10-15 CET |
| **Founded** | 2022 |

### What We Do

**Product:** Project management platform purpose-built for construction teams - scheduling, resource tracking, permit management, and subcontractor coordination.

**Target Users:** Mid-size construction firms (50-500 employees) managing multiple active job sites.

**Problem Solved:** Replaces spreadsheets, WhatsApp groups, and disconnected tools with a single platform that works from the office and the job site.

### Stage Evidence

47-person team across 4 departments, Series A closed Aug 2025 at $12M. Revenue growing ~15% MoM with 120+ paying accounts. Board includes partners from Nordic Capital and Seedcamp.

---

## People

### Team Directory

| Name | Role | Team | Current Focus |
|------|------|------|---------------|
| **Anna Lindqvist** | CEO | Leadership | Strategy, fundraising, enterprise sales |
| **David Osei** | CTO | Leadership | Architecture, hiring, technical direction |
| **Maria Santos** | VP Product | Leadership | Roadmap, customer research, prioritization |
| **Sarah Chen** | Engineering Lead | Core Platform | API v2, data model, team management |
| **Jess Park** | Design Lead | Design | Enterprise UX, design system refresh |
| **Tom Bakker** | Sales Lead | Go-to-Market | Enterprise pipeline, demos |
| **Priya Mehta** | Marketing Lead | Go-to-Market | Content strategy, launch campaigns |
| **Erik Nørgaard** | Senior Backend | Core Platform | Permit integration, API performance |
| **Amira Hassan** | Frontend Engineer | Growth | Onboarding flow, activation metrics |
| **Lucas Virtanen** | iOS Engineer | Mobile | Native app, offline sync |

### Working Styles

- **Anna Lindqvist:** External-facing, high-context communicator. Runs weekly enterprise calls. Writes detailed post-meeting summaries in Notion.
- **David Osei:** Technical leader, ships decisions in Linear comments. Prefers async, reserves calls for architecture reviews.
- **Sarah Chen:** Collaborative lead - runs sprint planning, unblocks cross-squad dependencies. Active in #engineering and #core-platform daily.
- **Jess Park:** Design-oriented, runs critique sessions Fridays. Documents all design decisions in Figma with annotations.

### Organizational Dynamics

- **Leadership:** 3-person exec team with clear domain ownership (Business, Tech, Product)
- **Recent Changes:** 2 senior backend roles in final interview rounds. 1 candidate at offer stage.
- **Key Risk:** David is sole architecture decision-maker - knowledge concentration risk (0.82)

---

## Teams

> **Note:** Teams below reflect actual human groupings inferred from collaboration patterns, not just tool structure. Linear "teams" are project areas, not real teams.

### Core Platform ⚙️

**Purpose:** API, data model, integrations - the foundation everything depends on

**Members:** Sarah Chen (Lead), Erik Nørgaard, + 3 engineers

**Rituals:** Daily standup 10:15 CET, weekly architecture review Thursday

**Current Focus:** Enterprise tier + API v2 (0.95 - Linear)

**Collaboration Pattern:** Tight loop with Design on enterprise UX. Async handoffs via Figma comments + Linear links.

### Growth 📈

**Purpose:** Onboarding, activation, self-serve conversion

**Members:** 4 engineers including Amira Hassan

**Current Focus:** Reduce onboarding drop-off from 40% to 20% (0.85 - Linear)

**Health:** On track - new guided setup flow shipping next sprint

### Mobile 📱

**Purpose:** iOS + Android native apps for job-site use

**Members:** Lucas Virtanen + 2 engineers

**Current Focus:** Offline sync reliability - critical for construction sites with poor connectivity

### Workstreams (Linear)

> These are project areas in Linear, not human teams.

| Workstream | Purpose | Primary Team |
|------------|---------|--------------|
| Enterprise | Enterprise tier features | Core Platform + Design |
| Platform | Infrastructure, API | Core Platform |
| Activation | Onboarding, conversion | Growth |
| Mobile | Native apps | Mobile |

---

## How We Work

### Rituals & Cadences

| Cadence | Ritual | Who |
|---------|--------|-----|
| **Daily** | Automated morning brief via Palette (0.94) | Everyone |
| **Weekly** | All-hands Monday 10am CET | Everyone |
| **Weekly** | Team syncs (varies by squad) | Per-team |
| **Bi-weekly** | Sprint planning + retro | Engineering + Product |
| **Wednesday** | No-meeting day (loosely enforced) (0.71 - calendar data) | Everyone |
| **Thursday** | Ship day - production deploys for major features | Engineering |

### Communication

| Channel | Purpose |
|---------|---------|
| **Slack** | Primary communication, async by default |
| **#decisions** | Anything affecting >1 team (0.92) |
| **#enterprise** | Enterprise tier coordination |
| **#engineering** | Technical discussions, deploy notifications |
| **Notion** | Specs, meeting notes, hiring docs |
| **Linear** | Issue tracking, sprint management, roadmap |

**Culture:** Slack-first, async by default. Calls for complex discussions only. Decisions made in Linear comments or Slack threads. Meetings require written follow-up within 24h or the decision doesn't count (0.88 - team norm).

### Decision Making

- **Pattern:** DRI (Directly Responsible Individual) model. Domain leads own decisions in their area.
- **Escalation:** Cross-team decisions go to #decisions channel, exec team breaks ties.
- **Documentation:** Major decisions logged in Notion with context and alternatives considered.

### Execution Patterns

- **Deploy cadence:** 5-7 deploys/day. Feature flags for major changes. Rollback within 15 min if metrics dip (0.94 - GitHub + Datadog)
- **Planning:** 6-week cycles loosely inspired by Shape Up. CTO + VP Product set bets, leads shape solutions (0.82)
- **Sprint structure:** 2-week sprints, ships Thursdays

---

## Projects & Initiatives

### Active (High Priority)

#### Ship Enterprise Tier
- **Lead:** Sarah Chen + Jess Park
- **Status:** In Progress - target March 15
- **Description:** Multi-seat plans, SSO, audit logs, advanced permissions
- **Why it matters:** CEO + board priority. Sales pipeline depends on this. 3 enterprise prospects waiting.
- **Health:** On track but tight (0.97 - Linear, Slack #enterprise)

#### Reduce Onboarding Drop-off
- **Lead:** Amira Hassan
- **Status:** In Progress
- **Description:** New guided setup flow replacing current self-serve onboarding
- **Target:** 40% → 20% drop-off rate
- **Health:** Shipping next sprint (0.85 - Linear)

#### API v2
- **Lead:** Erik Nørgaard
- **Status:** In Progress
- **Description:** RESTful API redesign with better pagination, webhooks, rate limiting
- **Why it matters:** Enterprise customers need reliable integrations with their ERP systems

### Planned

#### SOC 2 Compliance
- **Lead:** Ops lead (TBD)
- **Status:** Planned - target Q2
- **Description:** Auditor selected, evidence collection started (0.74 - Notion)

### Completed (Recent)

#### Stripe Billing Migration
- **Completed:** 2026-02-05
- **Description:** Moved from in-house billing to Stripe Billing for enterprise tier

### Discovered Work (Not in Linear)

| Name | Type | Evidence | People | Suggested Action |
|------|------|----------|--------|------------------|
| GDPR Data Residency | Compliance | Slack #enterprise: "Danish clients asking about EU data hosting" | David, Anna | Create Linear project - blocking enterprise deals |
| Subcontractor Portal | Feature | 3 customer interviews mention "subcontractor access" as top request | Maria, Jess | Create Linear initiative for Q2 planning |
| CI Pipeline Overhaul | Infrastructure | Slack #engineering: "builds taking 20min, was 8min in December" | Sarah | Track in Linear - affecting deploy velocity |
| Construction Expo Booth | Event | Calendar: "Byggeri '26 Planning" recurring weekly | Tom, Priya | Create Linear issue for preparation |

---

## Product

**Description:** Project management platform purpose-built for construction teams. Handles scheduling, resource allocation, permit tracking, and subcontractor coordination from both office and job site.

**Stage:** Post-PMF, scaling to enterprise segment

### Key Features

| Feature | Description | Who Uses It |
|---------|-------------|-------------|
| **Job Site Scheduling** | Visual timeline for multi-site project scheduling | Project managers |
| **Permit Tracker** | Automated permit status monitoring with municipality integrations | Compliance teams |
| **Subcontractor Hub** | Coordination portal for external teams | PMs + subcontractors |
| **Mobile Field App** | Offline-capable native app for on-site updates | Field workers |
| **Resource Planner** | Cross-project resource allocation and conflict detection | Operations leads |

### Tech Stack

**Integrations:** Procore, Autodesk, Microsoft Project, SAP

**Core Tech:** Node.js, React, React Native, PostgreSQL, Redis

**Infrastructure:** AWS (eu-north-1), Datadog, LaunchDarkly, GitHub Actions

---

## Customers

**Current Stage:** 120+ paying accounts, expanding to enterprise segment

### Target Segments

| Segment | Characteristics | Deal Size |
|---------|-----------------|-----------|
| **Mid-market contractors** | 50-200 employees, 5-20 active sites | $2-5K/mo |
| **Enterprise construction firms** | 200+ employees, needs SSO + compliance | $10-25K/mo |

### Discovered Needs

- Automated progress reports for building inspectors (mentioned in 4 customer calls)
- Cross-project resource conflict detection (Slack #product: "customers keep asking")
- Subcontractor self-serve access without full licenses (top request in Intercom)

---

## Strategy

### Current Priorities

1. **Ship enterprise tier by March 15** - Board priority. Revenue milestone tied to next fundraise. (0.97)
2. **Reduce onboarding drop-off from 40% to 20%** - Growth squad, shipping next sprint. (0.85)
3. **Hire 2 senior backend engineers** - 4 candidates in final rounds, 1 at offer stage. (0.78)
4. **SOC 2 compliance by Q2** - Auditor selected, evidence collection started. (0.74)

### Key Bets

- Enterprise is the path to $10M ARR - mid-market alone won't get there
- Mobile-first for field workers is the moat competitors can't easily copy
- Construction-specific integrations (permits, inspections) lock in customers

---

## Organizational Intelligence

### Dynamics & Patterns

- **High deployment velocity** (5-7/day) indicates strong CI/CD culture and engineering confidence
- **Cross-functional overlap** between Product and Design on enterprise work - tight collaboration but potential bottleneck
- **Async-heavy culture** reduces meeting load but #decisions channel has low adoption (only 40% of cross-team decisions posted there)

### Health Indicators

**Positive:**
- Engineering shipping consistently on sprint cadence
- Customer NPS trending up (62 → 71 last quarter)
- New hires ramping faster since onboarding doc overhaul

**Watch Areas:**
- David (CTO) is single point of failure for architecture decisions - no deputy
- "No meeting Wednesday" only enforced ~71% of the time
- Mobile squad blocked 3x last month waiting on Core Platform API changes
- No dedicated QA process visible - relying on developer testing + feature flags

### Predictions & Risks

- **March 15 enterprise deadline is tight** - Design system refresh running parallel may create resource conflict
- **Mobile squad dependency on Core Platform** will worsen as API v2 work intensifies
- **SOC 2 evidence collection** needs engineering time not currently budgeted in sprints

---

## What's Missing (Needs Human Input)

| Field | Reason |
|-------|--------|
| org.mission | Mission statement requires founder articulation - not evident in tool data |
| org.vision | Long-term vision needs leadership input - current work shows *what* but not *why* |
| org.values | Core values must come from founders - behavior patterns visible but not explicit values |
| people.reporting_structure | Flat structure assumed but formal reporting lines unclear |
| strategy.long_term | Only Q1-Q2 2026 visible - 2-3 year strategy needs leadership input |
| customers.churn_reasons | Support data shows churn but reasons not systematically tracked |

---

## Confidence Summary

| Section | Confidence | Sources |
|---------|------------|---------|
| Company identity | 0.95 | Linear, Slack, Notion |
| People & roles | 0.92 | Linear users, Slack profiles, project assignments |
| Team structure | 0.85 | Collaboration patterns, Slack channels, sprint data |
| Active projects | 0.94 | Linear projects, sprint boards |
| Discovered work | 0.72 | Slack threads, calendar events, customer calls |
| Product features | 0.90 | Notion specs, Linear epics, GitHub repos |
| How we work | 0.88 | Slack patterns, calendar data, Linear cadence |
| Customer segments | 0.78 | Intercom, Notion CRM, Slack #sales |
| Strategy | 0.82 | Notion board notes, Linear initiatives, Slack #leadership |
| Org intelligence | 0.75 | Cross-source synthesis |

---

## Recent Snippets

### Week 06, 2026

#### Highlights
- Enterprise SSO integration passed security review
- Onboarding redesign A/B test showing 28% improvement in activation
- 2 enterprise demo calls converted to pilot agreements

#### Wins
- API v2 pagination shipped - 3x faster for large datasets
- Mobile offline sync reliability hit 99.2% (up from 94%)

#### Challenges
- Design system refresh competing for Jess's time with enterprise UX
- CI build times creeping up - now 20min avg (was 8min in Dec)

#### Next Week
- Enterprise permissions model finalization
- Guided onboarding flow staging deploy
- SOC 2 evidence collection kickoff

---

## Recent Decisions

- **2026-02-05** - Chose Stripe Billing for enterprise tier over building in-house.
  Speed to market > control. Revisit at 500 customers. (0.95 - Slack #enterprise)
- **2026-02-03** - Paused mobile app redesign to focus enterprise.
  Mobile squad doing API work instead. Revisit March. (0.92 - Linear, sprint planning)
- **2026-01-28** - Switched from Segment to in-house event tracking.
  Cost savings + more control over data pipeline. (0.88 - Slack #engineering)
- **2026-01-20** - Approved 2026 hiring plan: 8 new hires.
  4 engineering, 2 sales, 1 design, 1 ops. (0.90 - Notion board meeting notes)

---

## Tools & Systems

| Tool | Used for | Adoption |
|------|----------|----------|
| Linear | Issue tracking, sprints, roadmap | High |
| Slack | Communication, decisions, alerts | High |
| Notion | Docs, specs, hiring, knowledge base | High |
| GitHub | Code, PRs, deploys | High |
| Figma | Design, prototypes | High |
| Intercom | Customer support, feedback | High |
| Google Calendar | Scheduling | High |
| Datadog | Monitoring, alerting | High |
| LaunchDarkly | Feature flags | Medium |
| Stripe | Billing, subscriptions | Medium |

This is an excerpt of an orgtology. One file. Everything that matters about how a company works right now. Updated continuously. Readable by humans and AI.

Here’s why this works - and how to build your own.

What is an orgtology?

An orgtology is a single markdown file - orgtology.md - that captures the essential context of your organization: who works here, what they’re doing, how things actually work, and what matters right now.

Not a wiki. Not a database. Not a 40-page strategy doc nobody reads. One file, maintained weekly, written in plain English.

Why keep an orgtology?

Your company’s knowledge is scattered.

It lives in Slack threads that scroll away, Notion docs nobody updates, Linear tickets that tell half the story, and people’s heads. When someone’s on vacation, so is their context.

Decisions get relitigated.

“Didn’t we already decide this?” Yes. Three months ago. In a Slack thread nobody can find.

AI tools are useless without company context.

You can’t ask Claude about your roadmap if Claude doesn’t know your roadmap. An orgtology gives any AI tool the context it needs to actually help.

New hires shouldn’t need archaeology skills.

The first month at a new company is spent figuring out how things work. Most of that information exists - it’s just not written down in one place.

What does a good orgtology look like?

It describes reality, not aspirations.

An orgtology documents how your company actually works - not how you wish it worked.

## How We Work

- Decisions are made in Linear comments or Slack threads,
  never in meetings without a written follow-up
- Deploy cadence: 5-7 deploys/day, feature flags for major changes
- Communication: Slack-first, async by default, calls for complex discussions

This isn’t a culture deck. It’s an honest map.

It tracks what matters right now.

Not last quarter’s priorities. Right now.

## What Matters Right Now

1. Ship enterprise tier before March - CEO priority, 3 teams involved
2. Reduce onboarding time from 4 weeks to 1 - product-led growth bet
3. Hire 2 senior engineers - 4 candidates in final rounds

Every week, these shift. Your orgtology should shift with them.

It shows its work.

Every claim should have a confidence score and a source. If you don’t know how current something is, say so.

### Platform Team
- Lead: Marcus Rivera (0.95 - org chart, confirmed last week)
- Current sprint: API rate limiting + webhook reliability (0.88 - Linear)
- Hiring: 1 senior backend role, 3 candidates in pipeline (0.72 - Notion, may be stale)

0.95 means you’re sure. 0.72 means it’s probably right but check. This honesty is what makes an orgtology trustworthy.

It covers the right sections.

A good orgtology has five core sections:

## Core Sections

- **People & Teams** - Who works here. Team structure. Who leads what.
- **How We Work** - Real practices. Meeting cadence, communication norms, deploy process.
- **Current Priorities** - The 3-5 things that matter most. Company and team level.
- **Tools & Systems** - What you use and how. Slack for X, Linear for Y, Notion for Z.
- **Recent Decisions** - Last 5-10 significant calls. What, why, and by whom.

How do I make one?

Start small.

You don’t need to document everything on day one. Start with People & Teams and Current Priorities. Those two sections alone will be more useful than most internal wikis.

Update every session.

Every day, your tools and AI sessions generate context - decisions made, problems solved, priorities shifted. Pull those signals in automatically so the orgtology stays current without anyone thinking about it.

Recap every Friday.

Collect recaps from every team on the things not captured in tools. Weekly is the right cadence. Daily is noise. Monthly is archaeology.

Source from two places.

Your tools show what happened (commits, tickets, messages). Your people know what it means (context, priorities, decisions). An orgtology needs both.

Be honest about what you don’t know.

If something might be stale, mark it. A confidence score of 0.6 is more useful than a bold claim that might be wrong.

Keep it in one file.

The constraint is the feature. A wiki grows until nobody reads it. One file forces you to prioritize what’s actually essential. If it doesn’t fit in orgtology.md, it probably belongs somewhere else.

Grab the template and start:

The orgtology.md starter template is on GitHub →. Fork it, fill it in, make it yours.

Or, if you want it maintained automatically - Create with Palette →

FAQ

Isn’t this just a README?

A README describes a codebase. An orgtology describes an organization. Similar format, completely different scope. Your README doesn’t track who’s working on what, what was decided last week, or which priorities shifted.

What about Notion / Confluence / wikis?

Wikis grow. That’s the problem. Fifty pages that nobody reads is worse than one page everyone does. An orgtology is deliberately constrained to a single file because the constraint forces prioritization.

Does this scale past 50 people?

The format scales fine - you just get more sections and teams. The hard part is keeping it current. At 10 people, one person can maintain it in 30 minutes a week. At 200, you either need dedicated effort or automation.

Why markdown?

It’s the most portable format that exists. Paste it into Claude, Cursor, ChatGPT, an email, a wiki, a terminal. No vendor lock-in. No special viewer. It’s just text - and that’s the point.

Why confidence scores?

Because “we use two-week sprints” and “we use two-week sprints (0.91 - Linear sprint history)” are very different claims. One is hearsay. The other is evidence. Confidence scores make an orgtology trustworthy instead of aspirational.

How is this different from a company handbook?

A handbook is what you want to be true. An orgtology is what’s actually true right now. Handbooks describe policy. Orgtologies describe reality - and they update every week.