Velo Blog

Tag: culture

  • Async by default is not silent

    Async by default is not silent

    We work async by default at Velo. That phrase gets thrown around a lot, and it tends to mean whatever the person saying it wants it to mean. For us, it has a narrow definition: writing is the medium, and meetings are the exception. If a decision can live in a document, it lives in a document. If a status can be read in Linear, it does not need a standup.

    The trap most async teams fall into is treating async as a synonym for quiet. A silent async team is a team that has stopped talking. Ours has not stopped talking. It writes constantly, and it meets on purpose, twice a week.

    Two synchronous windows, on purpose

    Tuesday morning we run a 45 minute product review. Everyone who touched a shipping surface that week walks through the change in Figma or a Linear ticket. We pick the calls we could not have made in writing: tradeoffs where three people disagree, prototypes that need a room to react to them, hires we are debating. The agenda goes into Notion by Monday at 5pm. If you cannot get your item on the agenda, it waits a week.

    Thursday afternoon is engineering pairing. Two rotating pairs sit together (video on, screens shared, sometimes a live VS Code session) and knock out something gnarly: an on-call runbook, a Datadog alert that keeps false-positiving, a migration nobody wants to own alone. We rotate the pairs so the same two senior engineers do not always end up together.

    That is it. Two calendar blocks a week. The rest of the time runs on Notion docs, GitHub PR comments, and Slack threads that expect a reply within 24 hours, not 24 minutes.

    What breaks when you go async

    Here is the part nobody warns you about. Async does not break shipping. It does not break planning. It does not even break onboarding, if you write your docs well. What it breaks is the thing you cannot see on a dashboard: weak ties.

    Weak ties are the relationships you have with people you do not work with directly. The designer on the growth team you would have chatted to at the coffee machine. The infra engineer whose PRs you review once a quarter. The new hire in a different timezone whose face you would recognize but whose voice you have never heard.

    In an office, weak ties get maintained for free. You bump into each other, you overhear a joke, you end up in the same lunch line. In a fully async company, if you do nothing, weak ties wither. And when they wither, three things go wrong:

    • Cross team collaboration gets more expensive because trust is not pre-loaded.
    • People feel lonely, and they leave, and the exit interview says “culture” and you never figure out what that meant.
    • Good ideas from the edges of the company stop reaching the center. The designer who spotted a pattern in support tickets does not think to mention it to the PM she has never met.

    We tried ignoring this for about seven months. Then we noticed that our internal survey score on “I feel connected to people outside my team” had dropped from 8.1 to 5.4. We stopped ignoring it.

    The coffee lottery

    Every Monday at 9am UTC, a Slack bot we wrote (three hours of GitHub Actions and Python, nothing fancy) picks pairs of people at random and pings them both. The message is short: You have been matched for coffee this week. Book 30 minutes together whenever works. No agenda. Talk about anything. If you would rather skip, react with a wave and we will re-roll.

    A few design choices we made deliberately:

    1. Opt out, not opt in. Everyone is in the pool by default. If you skip three weeks in a row, you get quietly removed until you rejoin. Opt-in versions of this die because the people who most need weak ties are the least likely to raise their hand.
    2. No agenda, ever. The moment we add “discuss one work topic” it becomes another meeting. The point is that it is not a meeting.
    3. Cross team weighting. The bot deprioritizes pairs who are on the same squad or who have already been matched in the last 90 days. You are more likely to meet someone you would never otherwise talk to.
    4. 30 minutes, not 60. Short enough that nobody dreads it. Long enough to get past small talk.

    Attendance sits around 70% most weeks. We are fine with that number. The 30% who skip are not failing anyone; they are managing their week. The 70% who show up are keeping the network alive on behalf of everyone else.

    Async by default does not mean silent. It means the loud things are chosen.

    What we would tell a team about to go async

    Pick your synchronous windows before you cut everything else. Ours are Tuesday product review and Thursday engineering pairing. Yours will be different. What matters is that they are deliberate, load bearing, and small in number.

    Then, separately, budget for weak ties. Do not assume they will happen on their own. They will not. A coffee lottery is one option. Team offsites are another. A shared reading channel where people react with real thoughts, not emoji, is a third. Pick one and defend it.

    The teams we watch fail at async are not the ones who forget to write docs. They are the ones who forget that a company is a network of people who like each other enough to help each other on a Tuesday when they did not have to.

  • The day 1 onboarding checklist we finally trust

    The day 1 onboarding checklist we finally trust

    Our first attempt at onboarding was a Google Doc that nobody updated. Our second was a Notion database with fourteen owners and no owner. This is the third version, which has run through nine hires without a rewrite, and which our last four joiners have said was the first day at a job that felt planned.

    The rule we work backwards from: nobody sits idle. Not the new hire, not the buddy, not the manager. Every hour on day 1 has a defined output, and we can point at the output the next morning.

    The twelve items

    We track this as a Linear project cloned from a template. Each item is a ticket assigned to the person responsible, with a due time in London hours. If a ticket slips, it pages the hiring manager in Slack. Nothing here is aspirational; every item has failed at least once, which is why it made the list.

    1. Laptop imaged and on the desk by 08:30. IT owns this. If shipping is late, we send a loaner from the office by courier the night before.
    2. Accounts provisioned in Okta. Google, GitHub, Linear, Slack, Notion, Datadog, Figma, 1Password. Provisioned the Friday before, tested by IT with a throwaway login so we catch a missing SSO group before Monday.
    3. Buddy assigned and confirmed. Named two weeks in advance, blocked on the calendar for the whole day, not a stretch assignment for someone already underwater.
    4. Welcome standup at 09:15. Fifteen minutes with the immediate team. Names, what each person is shipping this sprint, one question the new hire wants answered.
    5. Dev environment running by 11:00. We keep a bootstrap script in the main monorepo that clones, installs, seeds the database, and runs the test suite. If it fails on a fresh machine, that is a P1 for the platform team.
    6. First PR opened by 14:00. Every team keeps a small backlog of tickets tagged good-first-issue. Copy tweaks, config renames, a missing test. The point is to touch the pipeline.
    7. First commit merged by end of day. The buddy reviews, the CODEOWNERS bot approves, CI runs green, and it deploys through our normal path. No ceremony, no exemption from the release train.
    8. Three intro coffees on the calendar. Not scheduled by the new hire. The manager picks three people outside the immediate team and books thirty minutes each across the first two weeks.
    9. Engineering handbook read. Sixty pages in Notion. It covers how we branch, how we write RFCs, how we run incidents. We ask two questions about it at the retro.
    10. Shadow the 15:30 standup for the sister team. We want new joiners to see how another team runs before their own becomes familiar.
    11. Post in #intros. A short paragraph and a photo of something the person likes. Not a policy, but a norm every hire has followed for two years.
    12. End of day retro with the buddy. Twenty minutes. What worked, what was confusing, what the new hire wants to change tomorrow. Written up in the Linear ticket and read by the manager the next morning.

    Why the first commit matters

    People argue this one with us. They say it puts pressure on the new hire, or that the commit is trivial and doesn’t prove anything. Both criticisms are fair, and both miss the point.

    The first commit is not a test of the new hire. It is a test of us. If a fresh joiner cannot ship a one line change on day 1, we have broken something: the bootstrap script, the CODEOWNERS file, the CI pipeline, the deploy access, or the buddy’s calendar. When we started measuring this, we found that on average two of those five were broken for any given hire. Now it is closer to zero.

    The first commit is a test of us, not of the new hire.

    The commit itself is often a typo fix in the marketing site or a colour token in Figma renamed in code. What matters is that the person walked the full path, saw the review comments, watched CI go green, and got the Slack notification when their change went live in production.

    What we cut

    The first version of this list had twenty six items. We cut fourteen. The pattern for cutting was consistent, and worth naming.

    • Anything that could wait until week two, waited until week two. Payroll paperwork, benefits enrollment, the security training module, the office tour with facilities. None of these help someone feel oriented on day 1.
    • Anything that produced no artifact came off. A “meet the CTO” slot without a follow up was noise. The CTO now joins the Friday demo instead, which is a real meeting with a real output.
    • Anything owned by more than one team came off. Shared ownership meant nobody chased it. Every remaining item has exactly one accountable owner, listed in the Linear ticket.

    We run this checklist every Monday and most Tuesdays. Nine hires in, the pattern holds. The buddy is tired by 17:00, the new hire is tired by 17:30, and the manager has a written retro to read on Tuesday morning. Nobody sat idle.

  • A take-home task that respects candidates

    A take-home task that respects candidates

    What we ask

    Our take-home is capped at two hours. We say two hours, we mean two hours, and we check on it. If a candidate spends four, we treat that as our fault for scoping poorly, not theirs for being slow.

    The prompt is a real problem we hit last March: a Linear webhook was dropping payloads under load, and our on-call channel in Slack filled with duplicate alerts. We strip the business context, sanitize the payload shape, and hand candidates a repo with the failing test already written.

    What we pay

    Two hours of senior engineering time is not free. We pay 200 pounds per completed submission, regardless of outcome. Finance flagged it as unusual the first time; now it runs through the same expense flow as contractor invoices.

    A short list of what the pay covers:

    • The two hours of coding.
    • The 20 minute walkthrough call afterward.
    • Any follow up questions we send over email.

    The rubric lives on GitHub

    Our scoring rubric sits in a public repo, versioned like code. Candidates read it before they start. We grade on four axes: correctness of the fix, quality of the test coverage, clarity of the pull request description, and whether the candidate flagged the ambiguities we planted.

    If you cannot show a candidate how you will grade them, you do not have a rubric. You have a mood.

    We do not hide the trick either. There is a race condition in the retry logic that most candidates miss. That is fine. Missing it is not disqualifying; pretending it does not exist in the walkthrough call is.

    Why bother

    The hiring market tells engineers their time is worth nothing until an offer lands. We think that assumption poisons the relationship before day one. When someone joins us on a Tuesday, they have already seen how we write tickets, how we scope work, and how we handle disagreement. Nothing about the first week is a surprise.

    Two candidates last quarter turned down our offer. Both cited compensation. Neither cited the interview. We will take that trade.

  • The manager doc, a one-page contract with your team

    The manager doc, a one-page contract with your team

    Every new manager at Velo writes a one-page document about how they work. We call it the manager doc. It lives in Notion, gets linked from the team’s home page, and each report reads it in their first week.

    We started doing this two years ago after a retro where three engineers said the same thing in different words: they could not predict what their manager wanted. One thought skip-level meetings were off-limits. Another assumed silence on a PR meant approval. A third had been sitting on a concern for six weeks because they were waiting for the right 1:1 slot. None of these were failures of intent. They were failures of shared context.

    The doc fixes that by making the invisible visible. Here is how we write it, what goes in it, and how we keep it from rotting.

    What goes in a manager doc

    We keep the doc to a single page. If it needs a scrollbar, something is wrong. The format is prose with short sections, not a bulleted resume. It reads like a letter to the team.

    We ask every manager to cover six things:

    • How I run 1:1s. Cadence, format, who owns the agenda, whether we take notes, where those notes live. One of our staff managers writes: “We meet Tuesdays at 2pm for 30 minutes. You own the agenda in our shared Notion page. I will always ask about one thing outside work. I take rough notes in the same doc.”
    • When to escalate to me, and when to go around me. This one is uncomfortable to write and the most useful to read. We name specific cases: a production incident on a service the team owns, a conflict with another team, a concern about a peer’s behavior, anything that touches compensation or headcount.
    • How I handle disagreements. What happens when a report thinks a decision is wrong. Do we debate in the 1:1, in Slack, in a written doc? What is the tie-breaker? Most of our managers land on some version of “disagree in the room, commit in the hallway,” but we ask them to say it in their own words.
    • How to give me feedback. Where, when, in what form. We ask managers to name a channel they will watch. One of our design managers wrote: “DM me on Slack or drop it in the feedback section of our 1:1 doc. I will not react in the moment. I will respond within 48 hours.”
    • What I care about beyond shipping. What good work looks like on this team. What behaviors get someone promoted. What gets a quiet conversation.
    • What I am bad at. This is the hardest section and the one that builds the most trust. Not false modesty. Real patterns. “I default to writing when I should be talking. Push back if I send you a wall of text instead of hopping on a call.”

    We do not prescribe a template beyond those six prompts. The voice matters. A doc that sounds like a policy manual gets ignored. A doc that sounds like the person gets reread.

    Keeping the doc alive

    A written statement is worth nothing if it drifts from reality. We tie the doc to the quarterly cycle.

    At the start of each quarter, every manager updates their doc and posts the diff in their team channel. Even a small change counts. Last quarter one of our platform managers updated exactly one line: her escalation policy for on-call incidents, after our Datadog paging rules changed. She still posted the diff. That signal matters more than the edit itself.

    We also run three checkpoints:

    1. New hire week one. The new report reads the doc, brings questions to their first 1:1. The manager updates the doc based on those questions. New eyes catch stale claims fast.
    2. Quarterly retro. During team retro, one prompt is: “Where did the manager doc match reality this quarter, and where did it not?” We surface the gaps in the room.
    3. Manager changes. When someone moves teams or gets a new manager, the incoming manager sends their doc within the first week. We treat this as non-negotiable.

    The docs live in a single Notion database with a last-updated column. Our head of engineering scans it monthly. If a doc has not been touched in six months, she pings the manager. Not to scold, to ask what changed. Usually something did, and the doc did not catch up.

    What we noticed after a year

    Two patterns showed up that we did not predict.

    First, the docs made lateral moves easier. When an engineer was considering switching teams, they read the target manager’s doc before the coffee chat. The conversations got sharper. Fewer people joined a team and then discovered the manager ran things in a way that did not fit them.

    Second, the docs became a mirror for the managers themselves. Writing “how I handle disagreements” forced people to notice that they did not have a consistent approach. Several managers told us the writing changed their behavior more than any training we had run.

    The manager doc is not a framework. It is one page of honest prose that a team can point at when something feels off.

    That is enough.

  • Why we stopped tracking hours

    Why we stopped tracking hours

    We killed the timesheet in March. Nobody misses it. What replaced it made our finance team nervous for about six weeks, and then it stopped making them nervous. Here is what happened.

    What we track now

    We stopped asking engineers, designers, and PMs to log hours against project codes in Harvest. It rewarded the wrong thing: presence. A person could sit on a Linear ticket for three days, log 24 hours to it, and produce nothing shippable. The timesheet said the work was funded. The product said otherwise.

    We now track two things per squad, weekly, in a Notion database that pulls from Linear and GitHub:

    • Shipped units of work: tickets that closed the loop, meaning code merged, feature flagged on for at least one real customer, and no rollback within seven days.
    • Cycle time: median days from “In Progress” to “Shipped” on Linear, per squad, broken out by ticket size (S, M, L).

    That is it. No story points. No hours. If a squad shipped four medium tickets in a week with a cycle time of 3.2 days, that is the artifact. We review it every Thursday in a 25 minute meeting called Ship Review.

    What finance pushed back on

    Our CFO’s first question was fair: how do we capitalize engineering costs for the R&D credit if nobody is logging hours to projects? HMRC wants a defensible allocation. Auditors want a paper trail. “The vibes were good on Thursday” is not a paper trail.

    Her second question was harder. If a contractor bills us for 40 hours and we have no internal hours to compare against, how do we know we are not being overcharged?

    What we told them

    We proposed a trade. Finance gets a defensible model. Squads keep their calendars.

    1. Every squad has a fixed roster, and every roster maps to one or two product areas in a Notion table. Payroll cost per squad is known. That is our allocation basis, reviewed quarterly.
    2. Contractors still log hours in Harvest, because they bill by the hour. Employees do not, because they do not.
    3. The Ship Review output feeds a monthly note to finance: shipped units, cycle time trend, and any squad where cycle time doubled without a headcount change. That flags stuck work faster than a timesheet ever did.

    Six months in, our R&D claim went through without a query. Cycle time on our payments squad dropped from 8.1 days to 4.4. Nobody has asked to bring hours back.

    A timesheet measures whether you showed up. A shipped ticket measures whether the customer got something.

    We know which one we would rather report on.

  • Salary transparency, eighteen months in

    Salary transparency, eighteen months in

    In January of last year, we pushed a Notion page live to the whole company. It listed every role at Velo, the band it sat in, the floor, the ceiling, and the multiplier we used to convert level to base. We wrote about it on a Wednesday afternoon in Slack. By Friday, three people had asked for a chat.

    Eighteen months later, that page is still up. Some of what we expected happened. Most of what mattered did not. We wanted to write down what we published, what we held back, and one thing that broke.

    What we put on the page

    The Notion doc has six tabs. It contains everything a new hire or a curious teammate would ask us in a one to one:

    • Level definitions for engineering, design, product, and go to market, with three example projects per level.
    • Base salary bands for every level, in GBP and EUR, refreshed each January using Radford and our own market pulls.
    • The formula that turns level into offer: floor plus a location factor, capped at the ceiling.
    • Equity grants as a range of shares, plus a plain English note on our 409A and the strike price at the last round.
    • The rubric we use in promotion committee, including the four criteria and how we score them.
    • A change log at the bottom, so people can see when a band moved and why.

    We linked it from the onboarding checklist in Linear and pinned it in the #comp channel. New hires get a Loom walkthrough on day two.

    What we did not publish

    We were honest with ourselves about the gaps. A few things stayed off the page on purpose:

    • Individual salaries. We publish bands, not names. Two teammates asked for a fully open sheet in month four. We said no, and wrote a short doc explaining why.
    • Bonus targets for the two people on commission. Their plans are bespoke, and putting a range on them would have misled the rest of the team.
    • The one off retention grants we handed out during a rough patch last summer. Three people got them. We told each of them the same thing: this is not part of the standard rubric.
    • Founder salaries for the first year. We added those in month nine, after a Datadog outage weekend where the on call engineer asked, in a Slack DM, whether the founders were still on a discount. It was a fair question and we should have answered it sooner.

    We are still uneasy about the retention grants. If you publish a rubric and then quietly step outside it, you owe people an explanation. The next time we do one, it will show up in the change log with a category, even if the individual amounts do not.

    The hire that fell through

    In April, we were close to signing a senior backend engineer out of Berlin. She had spent an hour on a Figma review with our design lead and shipped a small GitHub PR against a starter repo. The team was ready.

    Our offer was the top of the L5 band. She had a competing offer that was twenty two percent higher, from a US company hiring in Europe. She sent us a screenshot of the other letter. We said no to the counter, because raising for one hire would have blown a hole through the band we had just published.

    She took the other job. It was the right call and it stung. If our page had been private, we would have found a way to say yes and moved on. Publishing the numbers meant we could not privately break our own rules without someone finding out on their first day. That constraint cost us a good hire.

    The point of writing something down is that it becomes harder to walk away from. That cuts both ways.

    The quiet compression

    The thing we did not predict was what happened to the bands themselves.

    Before publishing, our L4 engineering range spanned roughly forty percent floor to ceiling. Managers used the full width. Two people at the same level, hired six months apart, could sit twelve thousand pounds apart based on how the negotiation went.

    Once the numbers were visible, the top of the band became a promise. Anyone below the midpoint asked, reasonably, why. Over three review cycles, the width of that band shrank to about eighteen percent. Not because we changed the policy on paper, but because managers stopped defending the low end and stopped offering the high end without a clear promotion signal.

    The average went up. The variance went down. Our comp spend for the L4 cohort grew by nine percent year over year, and we lost the flexibility we used to have to reward a rare skill without moving someone a level.

    We are not sorry about it. It made every one to one about pay shorter, and it turned promotion committee, which meets the second Thursday of each month, into an argument about evidence rather than an argument about numbers. Two people got promoted last cycle who would have been talked out of it under the old system, because the manager could no longer say, quietly, that they were already paid like the next level.

    What we would do again

    If we were starting over, we would publish sooner and narrower. Wider bands look generous on paper. They also give managers room to make decisions they cannot defend in daylight. We would rather have the argument up front.

    The Notion page is still open in a tab on our screens most Fridays. It has not fixed hiring. It has made the conversation we have about pay a smaller, calmer thing. Given where we started, that is enough.

  • The quarter we shipped no features

    The quarter we shipped no features

    Last October, three days after our Q4 planning offsite, we made a decision that felt reckless at the time. We were going to spend the entire quarter without shipping a single new feature. No new modules, no new integrations, no new dashboards. Only bugs, docs, and the internal tools our engineers had been asking for since spring.

    Our head of sales, Mira, found out on a Monday morning during our weekly go-to-market sync. She went quiet for about eight seconds, then asked whether we were serious. We were.

    What sales was worried about

    Mira had four deals in the pipeline that hinged on a specific promise: a Snowflake connector we had been talking about since June. Two of those deals were mid-market, one was a renewal expansion, and one was a competitive replacement worth around 180k in annual contract value. She pulled up the deal notes in Notion and walked us through each one.

    The fear was reasonable. If we froze features for 90 days, three things could happen:

    • Prospects would walk to competitors who kept shipping.
    • Existing customers waiting on requested features would churn at renewal.
    • The sales team would lose narrative ammunition on discovery calls.

    We agreed to review the freeze monthly. If any of those signals showed up in the data, we would call it off. Mira asked us to write down what “showed up in the data” meant, so we did: net revenue retention below 108%, gross churn above 1.4% monthly, or two consecutive weeks of stalled pipeline movement on flagged deals.

    What we shipped instead

    The engineering team split into three squads. One squad, which we called Fixit, worked exclusively through Linear tickets tagged with the “customer-reported” label. Another squad, Docs, sat with our support lead every Tuesday to identify the top ten most-hit help center pages and rewrite them. The third squad, Tooling, built the internal admin console engineers had been begging for.

    By week six we had closed 247 bugs, some of which had been open for over a year. The Datadog dashboard we cared about, the one tracking p95 API latency, dropped from 840ms to 310ms after two engineers rewrote a query planner in the reporting service. Our support team went from 34 open Zendesk tickets on any given Friday to 9.

    The internal admin console was the surprise. Before Q4, resolving a customer-reported billing issue took an engineer about 40 minutes: pull data from three tables, reconcile in a Google Sheet, patch, verify. After the tooling squad shipped the console, our support engineers were doing the same work in under 4 minutes. They did not need to page anyone.

    By the end of week ten, our on-call rotation had gone from one incident per shift to one incident every six shifts. Two engineers told me they were sleeping better. One of them had been talking about leaving.

    What happened to churn

    Here is the part nobody predicted. Gross churn went down. Not by a huge amount, but measurably: from 1.2% monthly at the start of Q4 to 0.7% by December. Net revenue retention held at 114%.

    Mira’s Snowflake deals: three of the four closed anyway. The connector question came up on discovery calls, and the answer we gave, which was that we were spending the quarter on reliability instead of new surface area, played better than we expected. One of the buyers, a VP of data at a healthcare company, told us he had never heard a vendor say that out loud. He signed in November.

    Two effects we did not model

    First, our NPS moved from 42 to 51. We got unsolicited notes in Slack from customer success managers whose accounts had stopped filing tickets. Second, our engineering hiring pipeline got healthier. Three candidates in December mentioned during their onsite loop that they had read our internal writeup about the freeze and wanted to work at a place that took reliability seriously.

    What we would do differently

    We got lucky on a few things and would not repeat every choice.

    1. We underestimated how disorienting the freeze would feel to product managers. Two of them felt sidelined for six weeks before we figured out how to give them meaningful work reviewing customer feedback and shaping the Q1 roadmap.
    2. We should have communicated the freeze to customers on day one, not week three. When we finally sent the note explaining what we were doing, the response was overwhelmingly positive. We could have banked that goodwill earlier.
    3. We did not set clear exit criteria beyond the churn and NRR thresholds. When Q1 planning arrived, some of us wanted to extend the freeze another month, and we did not have a decision framework for that conversation.

    We are not going to do this every quarter. Growth still matters, and a company that only fixes bugs is a company that gets displaced. But we now know the shape of what a deliberate pause looks like, what it costs, and what it returns. Next time we consider one, the conversation will be shorter, and the fear in the room will be smaller.

  • What happened when we replaced standup with a doc

    What happened when we replaced standup with a doc

    The reason we cancelled the 9:15

    Our morning standup ran for eleven months before we killed it. Fifteen minutes on paper, twenty-two in practice, five people on video, one person still chewing toast. We tracked the cost for a quiet month: eleven engineers, four days a week, roughly nine hours of collective time each week vaporized into “yesterday I worked on the invoice bug, today I will keep working on the invoice bug.”

    The trigger was Linear. We had migrated our ticket board over from Jira, and the state of every ticket was suddenly legible without a human reading it aloud. Whatever the standup had been for, it was no longer for status.

    We wrote a shared Notion page called Daily. Each morning, before 10:00, you posted three lines: what shipped, what you are on, what is blocking you. That was the whole ritual. No meeting.

    Week one and two: something went wrong

    The first Monday felt like a small miracle. Everyone got the extra half hour, the doc filled up by 09:47, and we all stayed at our desks. By Thursday, two things were off.

    The doc was thinner than we expected. People wrote “same as yesterday” or copied their previous line and edited the date. The prose that had felt lively when spoken went dead when typed. Morale dipped too, in a way we did not predict. Not a crash, more like the room got quieter. Our head of design put it best in the retro:

    I did not realize how much of my sense of the team came from watching Priya groan about her PR review queue and Marcus talk about his kid’s soccer game. The doc has none of that. It reads like a receipt.

    Slack traffic went up during those two weeks, in a way that surprised us. Random channels filled with the small talk that had been living, uninvited, inside standup. We had removed the container without moving the contents anywhere. The contents leaked.

    The other loss was harder to measure. In standup, someone would say a sentence and someone else would say “wait, back up,” and a small course correction would happen in ninety seconds. In the doc, that same correction became a threaded Slack conversation that took two hours and ended with “let’s hop on a quick call.” We had traded one meeting for many smaller ones.

    Week three onward: the writing got serious

    Around the third week, the doc improved. A few things changed at once:

    • The team stopped treating the entry as a chore and started treating it as a note to a colleague. Entries got longer, more specific, funnier.
    • Blockers became first class. If you wrote “blocked on the Stripe webhook signature bug,” someone unrelated would read it over coffee and drop a link to the fix.
    • Async engineers in Lisbon and Toronto stopped feeling like second tier attendees. Their entries carried the same weight as the ones written in the London office.

    The deeper win was the writing itself. Engineers who had been quiet in meetings wrote sharp, thoughtful updates. One of them told us she had spent every standup rehearsing her sentence and missing what other people said. The doc gave her back that attention. Our design docs improved in the same period. We are not sure the two are causally linked, but it felt like a muscle getting more reps.

    The Wednesday sync, and why it stayed

    We tried holding out on the meeting free plan for a full month. It did not last. By week five we had put one meeting back on the calendar: a thirty minute sync on Wednesday at 10:00, camera on, no agenda beyond “how is the week going.” We call it Wednesday. That is the whole name.

    Wednesday is not a status meeting. If you tried to give a status update in it, someone would gently redirect you to the doc. It is where the soccer game goes, where the “I hate this ticket” goes, where the “I think we should reconsider the pricing page rewrite” goes. It has run for fourteen months now and we have cancelled it twice, both times for a company offsite.

    The compromise on paper:

    1. Monday through Friday: the Daily doc, posted by 10:00.
    2. Wednesday at 10:00: the thirty minute human sync.
    3. Friday afternoon: a short written retro in the same Notion space, three prompts, no meeting.

    Time saved per engineer, measured against the old standup, is roughly six hours a month. That number is real. What is less measurable, and what we think matters more, is that our written record of what happened each week is now searchable. When a new hire joins, we point them at three months of Daily entries and they get context that used to live only in people’s heads.

    What we would tell a team about to try this

    Two things. First, the social contract of standup is doing work you cannot see. If you remove the meeting without replacing the social part, the team will feel it within a week and blame the doc. Put the social part somewhere on purpose. Second, the doc will be bad for two weeks. Do not judge it before then. The writing muscle needs reps, and the first entries will read like receipts because the team is still thinking in bullet points from the meeting they no longer have.

    This setup would not work for a sales team, or a team spread across more than three time zones, or a team that responds to Datadog pages every hour. It works for eleven engineers and four designers who write for a living anyway. Your mileage will vary. Ours has not, in a year and change.