People ask what it is like to work at CompassHQ. Usually people who have done the “remote” thing at a company that was really just an office with Zoom links. So I figured I would write it down. That impulse, write it down so anyone can find it later, is probably the best one-liner for how CompassHQ operates.
This is our culture doc. Not the aspirational poster version. The real one.
Remote-First, Not Remote-Allowed
There is a real difference between a company that allows remote work and one that was built around it. CompassHQ has been remote-first since the beginning. There is no headquarters. No “main office” that anyone dials into. Every process, tool, and communication habit is designed for remote by default.
Most “remote-friendly” companies still run on in-person habits. Decisions happen in hallway conversations. Context lives in someone’s head. Meetings become the default because that is what works when everyone is in the same building.
CompassHQ never had those habits to begin with. The defaults are async, written, and accessible regardless of timezone.
I think of culture as a set of tools that help you act and decide when nobody is telling you what to do. Not what you put on a slide deck. The operating system that runs when nobody is looking.
Async by Default, Sync When It Matters
There is a loose hierarchy for communication at CompassHQ:
-
Write it down. Design docs, decision records, project updates, technical proposals. If it matters enough to communicate it matters enough to write it.
-
Threaded discussion. When a written proposal needs input, discussion happens in threads. Linear comments, GitHub PR reviews, Slack threads. People get time to think before responding and everything stays searchable.
-
Quick sync. Some things really are faster as a five-minute call. Unblocking someone, debugging together over a screen share. The key is these are the exception, not the rule.
-
Scheduled meeting. Reserved for things that genuinely need real-time group discussion. Retros, planning, 1:1s. These always have agendas and always produce written outcomes.
Urgency and importance are different things. Slack is for urgent. Linear and docs are for important. Email is for formal. Most things that feel urgent are not, and most things that are important deserve more than a chat message.
In Practice
No “you up?” pings. If you need something from someone, write the full context. “Can you look at the PR for the survey aggregation refactor? Not sure about the approach for handling partial responses, left a comment on line 47.” Not “hey, got a sec?”
Public channels over DMs. Most work discussion happens in public Slack channels. If you solve a problem in a DM nobody else learns from it. If you solve it in a channel the next person with the same question finds it.
Status updates are written, not spoken. Weekly async check-in. What got shipped, what is next, anything blocking. Takes five minutes to write and keeps everyone informed without a standing meeting.
Documentation-First
This is the thing that makes everything else possible. In a remote async environment if something is not written down it does not exist. There is no watercooler. There is no “oh I overheard someone mention that.”
What Gets Documented
Architecture decisions. When a significant technical choice is made it gets written down. What was decided, why, and what alternatives were considered. Six months later when the question “why Rust for the backend?” comes up the answer already exists.
How things work. Every system has a brief doc explaining what it does, how to run it locally, and where to look when something breaks. Lightweight and updated when they drift.
Onboarding context. A new person should not need to chase down answers scattered across multiple heads to understand how the codebase fits together. It is written down once and kept current.
Meeting outcomes. If a sync meeting happens the decisions and action items get written up. If there is no written record the meeting did not happen.
The Compounding Part
In the short term writing things down feels slower. Writing takes more effort than talking. But over months the returns add up:
- New people ramp faster because answers exist already
- Decisions get more thought because writing forces clarity
- Context does not vanish when someone goes on vacation
- You can search institutional knowledge instead of chasing people on Slack
We build a product that helps engineering teams understand their delivery. It would be pretty hypocritical to run CompassHQ on gut feel and hallway conversations.
Transparency
Financial position is open. Revenue, runway, burn rate. What is being built and why is visible. Not just the next sprint but the quarterly direction and the reasoning behind it.
Default to public channels. Default to sharing context. Default to explaining the why behind decisions, not just the what.
This maps to our product philosophy. CompassHQ exists because engineering metrics should be honest. No vanity dashboards. No cherry-picked numbers. We hold ourselves to the same standard.
Problems left in the dark grow. Problems in the open get solved.
Staying Connected
Remote work has a real failure mode and it is isolation. People end up feeling like they are working in a vacuum. A few rituals help with this.
Weekly async updates. Short written update every Friday. What got shipped, what is next, and one non-work thing. The non-work bit is intentional. It fights the loneliness that comes with remote work. Sounds small but it works.
Tech talks. Regular sessions on a technical topic. A Rust pattern, a new approach to survey analysis, a walkthrough of a gnarly bug. Optional, recorded, low pressure.
1:1s. Regular, scheduled, focused on the person not the project. How are you doing. What is frustrating. What do you want to work on next.
In-person meetups. A few times a year. Not for status updates. For whiteboarding, building relationships, and eating good food. The stuff remote cannot replicate.
Tools
The toolset is small:
- GitHub for code, PRs, issues, CI/CD
- Linear for project management and async updates
- Slack for real-time when needed (not a replacement for docs)
- Google Docs for long-form writing and proposals
- Figma for design
Every tool has one job. If two tools overlap one gets dropped.
Developer-First, Even Internally
We build for engineering teams and I use CompassHQ every day. That has practical consequences for how the company operates.
Respect focus time. There is no expectation of instant responses to messages. If something is truly urgent, call. Otherwise it waits.
Minimize process. Every process has to earn its place. Standups are async. Sprint planning is lightweight. Retros happen but they are efficient. If a process does not make things better it gets dropped.
Trust over tracking. No monitoring of hours, keystrokes, or screen time. What matters is output and communication. If work is shipping and nobody is blocked, things are good.
Invest in the environment. Good equipment, quiet workspace, reliable internet. Not a perk. A prerequisite.
What We Look For
This doubles as context for anyone thinking about working with us.
Good writing. In a remote async documentation-first company writing is the primary medium of work. You do not need to be a great writer. You need to be clear and comfortable putting your thoughts down in text.
Self-direction. Nobody is going to hand you a ticket and check on you every few hours. You need to understand the goal, figure out the approach, and push it forward. Ask for help when you are stuck.
Technical depth with product sense. Care about craft but also understand why you are building what you are building. The best engineers I have worked with can explain the business impact of their technical decisions.
Comfort with ambiguity. Early-stage companies do not have everything figured out. Requirements change. Priorities shift. If you need a perfectly defined spec before you can start this is probably not the right fit.
Why This Is Public
Most companies keep their culture docs private. We are publishing ours for the same reason we believe metrics should be transparent. If you are evaluating whether to work here you deserve to know how we actually operate.
If you are building your own remote team maybe some of this is useful. And if you think we are doing something wrong, I would like to hear about it.
This doc will change as we do. But the core of it, remote-first, async-first, documentation-first, developer-first, that part is structural. Everything else we can rearrange.
If you want to talk about any of this reach out at hello@compasshq.com.