How to build engineering culture remotely from day 1

To build engineering culture remotely from day 1, write nine decisions down before hire #1: values, decision-record format, async-default rule, comms stack, on-call expectations, Friday demo cadence, 1:1 cadence with the founder, vacation policy, and salary transparency. The artifacts come first; the rituals come after. A new engineer who joins on Monday should be able to read your handbook on Sunday and ship code without asking how anything works.

Most founders skip this. They hire three people, watch the defaults form by accident, then spend the next two years trying to undo them. The fix is cheap: two hours of writing, one public document, before there is anyone to enforce it on.

Why culture-from-day-1 is a writing problem, not a hiring problem

Founders treat culture like recruiting: pick the right people and the rest will sort itself out. That works when you can see everyone in a room. Remote, it doesn't. The "right people" make different assumptions about how work happens, and without a written default, the loudest person's habits become company policy by week three.

GitLab's Sid Sijbrandij figured this out before hire #2. He wrote the handbook first, then hired against it. By the time GitLab had 50 employees, the handbook was over 2,000 pages and the company ran from it. Today GitLab has more than 2,500 all-remote employees and the handbook is still the source of truth, open-sourced at handbook.gitlab.com. You can fork it.

You shouldn't fork all of it. You need 9 decisions on a single page. The GitLab handbook is what you grow into, not what you start with.

The principle holds: the artifact precedes the ritual. A daily standup is a ritual; the document that says "we don't do daily standups, we post async updates in #standup at the start of your day" is the artifact. Hires copy artifacts. They argue with rituals.

The 9 decisions to lock before hire #1

Here is the entire founder-stage engineering handbook, in one table. Each row is one paragraph in your public Notion or GitHub repo. The whole thing fits on one page.

Decision	Default at Day 1	Why this default	When to revisit
Values doc	1 page, 5 bullets	Honest founder voice	Hire 25
Decision records	ADRs	One-page Markdown, low overhead	Hire 30 (move to RFCs)
Async rule	No meeting without 24hr written agenda	Forces written thought	Series A
Comms stack	Slack + Linear + GitHub + Loom	Scales to 50, under $20/engineer	Hire 100
On-call	None	Avoids pre-PMF trauma	First paid outage
Friday demo	4pm, 5 min/person, recorded	Visible progress, low ceremony	Never
1:1 cadence	Weekly, 30 min, founder-led	Trust plus signal	Hire 15 (delegate)
Vacation	25-day minimum	Engineers actually rest	Series B (formalize)
Salary transparency	Band published in handbook	8x application volume (Buffer's data)	Never

The next three sections walk through each decision. None of them take more than an hour to write.

Decision 1-3: Values, decision records, and the async rule

The values doc that survives contact with hire #5

Five bullets. No jargon. Written in the founder's own voice in a single sitting. If you find yourself reaching for words like "alignment" or "passion," delete the bullet and try again.

Good examples are concrete and slightly opinionated:

• "We ship to production every day, even on Fridays. Reverting is cheap; not shipping is expensive."
• "Decisions are written down in an ADR before they're acted on. If it's not in /docs/adr, it didn't happen."
• "Every engineer is AI-native. Cursor or Claude Code is part of the workflow, not a tool you 'try'."

The bad version is the one every Series-B startup has on its careers page: "We value excellence, ownership, and customer obsession." Those are not values. Those are aspirations any company would claim. Yours need to actually exclude some hires, or they aren't doing work.

This document gets edited. The first version will be wrong. That's fine. The point is that hire #1 is reading something specific, not making it up.

ADRs over RFCs at fewer than 10 engineers

An Architecture Decision Record is a one-page Markdown file in /docs/adr with a fixed structure: context, decision, consequences. Nat Pryce's adr-tools ships a template you can install in 30 seconds. The whole format reads in 90 seconds.

RFCs are heavier. They include problem statements, proposed solutions, alternatives considered, open questions, and a multi-day comment period. Uber's RFC process is famous, but Uber didn't have a formal RFC process until they were past 200 engineers. At hire #1 to hire #10, RFCs are overhead that produces nothing a one-paragraph ADR couldn't capture in five minutes.

The rule: ADRs at hire #1. Switch to RFCs around hire 30, when async review actually needs structure to scale. Until then, the format you pick is less important than the fact that decisions get written down before they get acted on.

The "no meeting that could be a doc" rule

This is the single most valuable cultural rule a remote-first founder can set. Every meeting requires a written agenda posted 24 hours in advance. If the agenda fits in a Slack message, the meeting is canceled and the answer goes in the thread.

The first month, you will resent this. The second month, you will resent meetings that violate it. By month three, hire #1 will start enforcing the rule on you, which is the point.

For deeper context on how this scales, our piece on building a remote-first engineering culture covers the patterns once you're past 10 engineers and the async rule needs more structure.

Decision 4-6: Comms stack, on-call, and the Friday demo

The boring comms stack that scales to 50

Pick four tools. Don't add a fifth.

• Slack for chat. $7.25 per user per month on the Pro tier.
• Linear for work tracking. $8 per user per month on Standard.
• GitHub for code review. The team plan is $4 per user per month.
• Loom for screen recording. Free tier covers 5-minute videos, which is enough for the Friday demo.

The total runs under $20 per engineer per month, and this stack scales cleanly to 50 engineers without rearchitecture. Resist the urge to add Notion, Confluence, Coda, Reflect, Asana, Jira, Monday, ClickUp, or any other tool a vendor pitches you in the first six months. If you need a wiki, use a private GitHub repo with Markdown files. If you need video calls, Slack Huddles are included.

For deeper picks on the toolchain, the best tools for remote dev teams breakdown goes through the trade-offs by company stage.

Why on-call is a Month-12 problem, not a Month-1 problem

Founders set up PagerDuty in week two because it feels professional. It isn't. Pre-product-market-fit on-call is just trauma without revenue: you wake your engineers up to fix outages on a product no one is paying for yet.

The actual default: no on-call until you have a paying customer who has filed an outage ticket. Until then, the founder takes the pages on a personal phone. This forces the founder to feel every reliability issue first-hand, which is the right incentive for someone setting the architecture.

When the first paid outage lands, write the on-call ADR that week. PagerDuty starts at $19 per user per month. One-week rotations work fine for a team of four; do not try to staff a follow-the-sun rotation until you have at least three people in three timezones.

The Friday demo at 4pm

Every engineer shows what shipped this week. Five minutes maximum per person. Recorded in Loom for anyone who can't make it. This is the only standing meeting that survives all 9 decisions. If a Friday demo conflicts with a hire's timezone, they record their demo asynchronously and post it in #demos by Friday noon their time.

The demo is the highest-signal cultural ritual you can run for under $0. It does four things at once: forces engineers to ship something demoable each week, creates a public record of momentum, surfaces blockers without a separate "blockers" meeting, and lets the founder see actual product progress instead of Linear ticket counts.

Don't water it down. No "what I'm working on" demos; only shipped artifacts. If hire #2 has nothing to demo two Fridays in a row, that's the conversation for the next 1:1.

Decision 7-9: 1:1 cadence, vacation, salary transparency

Weekly 1:1 with the founder, 30 minutes, no agenda required

Until hire #15, the founder runs every 1:1. Weekly. Thirty minutes. The engineer brings the agenda, or there is no agenda and you talk about whatever is in their head.

This sounds obvious; almost no founder actually does it. The default failure mode is to schedule the first 1:1, skip it twice for "fundraising emergencies," and then never reinstate it. The cost is invisible: hires don't quit when 1:1s die, they just stop telling you when something is wrong, and the first signal is a resignation email.

Weekly 1:1s also build trust faster than any retreat. Defer the team retreat until month 18. Until then, 30 minutes of undivided attention every week is the relationship-building budget. If you can't do weekly, the engineering team is too big and you should already be delegating, not skipping.

For the rest of the management surface, our guide on how to manage a remote engineering team effectively covers what comes after the 1:1 cadence is established.

Vacation as a minimum, not unlimited

Unlimited vacation is a trap. Buffer studied it; engineers on unlimited PTO take fewer days off than engineers on a 25-day plan, because the social pressure to look productive overrides the policy.

The fix is two sentences in the handbook: "25 days minimum per year. If you have not booked time off by November 1, the founder books it for you." You don't need an HR person to write that. You don't need a vacation tracking tool. You need the founder to actually book the time off when November 1 passes, which is the part that creates trust.

This is also the cheapest signal you can send that the company isn't a death march. Hire #1 reads "25 days minimum" and hears "they expect me to take vacation." That is a recruiting advantage worth a 5% salary premium.

Publish the salary band before hire #1

Buffer published its salaries in 2013 and saw inbound applications jump roughly 8x. The reason: salary opacity is the single biggest source of friction in early-stage hiring conversations, and removing it converts ambivalent candidates into committed ones.

You don't need to publish individual salaries. Bands by tier are enough. Cadence does this on the marketplace itself: junior $500 per week, mid $1,000 per week, senior $1,500 per week, lead $2,000 per week. Every engineer and every founder sees the same numbers. Pay disputes don't happen because the price is on the menu.

Whatever your bands are, write them in the handbook before hire #1 reads it. If you can't commit to a band publicly, you don't have one yet, and you'll negotiate every offer from a position of weakness.

The Day-1 to Month-3 timeline

The whole sequence fits in a 90-day calendar.

Day 1. Open a Notion page or a public GitHub repo. Write the 9 decisions in one sitting. Two hours, max. Do not over-edit. Hire #1 will read this.

Week 1. Hire #1 reads the handbook before signing the offer letter. The first edit they suggest goes in by week 2. Their first ADR ships in week 2 as well.

Month 1. First Friday demo runs even if it's just two people on Zoom. First on-call alert (if any) gets written up as an ADR. The handbook has been edited five to eight times.

Month 3. The handbook has been edited 30+ times by the team. New hires read it cover-to-cover during their 48-hour trial. The 9 decisions have ossified into the operating system. You stop being the source of every cultural answer because the handbook is.

If you ship hire #1 by Day 30 and hire #3 by Day 90, that 90-day window is when culture either becomes durable or becomes accidental. The 9 decisions are the difference.

How Cadence engineers plug into a Day-1 culture

Every engineer on Cadence is AI-native by default. That means Cursor, Claude Code, and Copilot are part of their daily workflow, vetted in a voice interview before they unlock the platform. They don't need to be onboarded onto AI tools, which removes one of the highest-friction parts of hire #1 setup at a remote-first company.

The handbook becomes the briefing. A Cadence engineer reads your 9 decisions on Sunday and ships a PR Monday morning, against your ADRs, in your comms stack, on your async rules. Median time to first commit across the platform is 27 hours from booking. The 12,800-engineer pool means you can match against your handbook on Friday and have the engineer in your repo by Monday.

Weekly billing is the cultural-fit safety valve. If hire #1 doesn't read the handbook, doesn't ship demos, or doesn't engage with 1:1s, you replace them at the end of the week. That single property, no notice period, no termination process, removes the founder's biggest excuse for hiring slowly. You can run the 9-decision experiment on a real engineer in 48 hours via the free trial.

If you want to skip the recruiter loop entirely and book a vetted engineer against your Day-1 handbook, start the founder onboarding and you'll have shortlists in two minutes.

For deeper coverage on what comes next, the post on pair programming remotely is a good follow-up once your handbook covers the core 9 decisions and you're scaling rituals.

Try the 9-decision handbook this week: write the doc on Monday, post it publicly on Tuesday, and book a Cadence engineer Wednesday with a 48-hour free trial. By Friday you'll know whether your handbook reads cleanly to a stranger. That feedback loop is worth more than the next month of recruiter calls.

FAQ

Should I copy the GitLab handbook?

Fork it as a starting point, then strip 90% of it. Their handbook fits 2,500 employees; you need 9 decisions on one page. The GitLab version is what you grow into over five years, not what you start with on Day 1.

ADRs or RFCs at hire #1?

ADRs. They are one-page Markdown files in /docs/adr, low ceremony, and any engineer can write one without process training. Move to RFCs around hire 30 when async review needs to scale across multiple teams. Until then, RFCs are overhead.

What if my first hire is in a wildly different timezone?

Apply the 3% per timezone-hour rule popularized by ByFounders: budget that share of working time for explicit overlap. Avoid hires more than six timezone hours from your core team at this stage; the overlap math gets brutal once you're past six hours of difference.

Do I need an HR person to write a vacation policy?

No. Two sentences in the handbook works: "25 days minimum per year. If you have not booked time off by November 1, the founder books it for you." That is the policy. Add formal HR around Series B when headcount makes self-service untenable.

Should I publish exact salaries or just bands?

Bands by tier are enough at this stage. Cadence does this publicly on the marketplace: junior $500, mid $1,000, senior $1,500, lead $2,000 per week. Bands force honest hiring conversations without exposing every individual offer, and they remove the negotiation-from-weakness dynamic that kills inbound application rates.