Velo Blog

Blog

  • How our Friday demo became a sales asset

    How our Friday demo became a sales asset

    Every Friday at 3pm, two engineers and one PM run a ten minute demo of what shipped that week. For a year it lived inside a private Loom folder shared with the rest of the team. Six weeks ago, we started publishing the recording to our customer-facing changelog.

    We did not plan for it to become a sales asset. That part surprised us.

    What the demo looks like

    It is not polished. We record on Zoom, trim the top and tail in Descript, and post the file next to the changelog entry in our docs site. The rules we set for ourselves are short:

    • Ten minutes hard cap. If we run over, we cut.
    • Show the feature working in a real workspace, not a demo tenant.
    • One engineer walks through the code path or the migration. The PM narrates why.
    • Mention the Linear ticket number on screen so viewers can search for context.
    • No slides.

    The first public recording covered a small change to how we render org charts. The engineer showed the diff on GitHub, then flipped to the browser and dragged a node around. Fifty-two seconds. That was the whole segment.

    How sales found it

    Two weeks in, a rep on our AE team dropped a link in Slack. She had forwarded that week’s demo to a prospect who kept asking whether we shipped fast enough to keep up with their internal roadmap. The prospect replied within an hour and asked to move the next call forward.

    Then it happened again. And again. By week four, three reps were routinely attaching the changelog demo to follow-up emails. One of them told us the video did something a case study could not: it showed the people building the product talking about a specific decision they made on a Tuesday.

    The prospect wrote back saying they wanted to work with a team that ships like this.

    What we changed after that

    We did not restructure the demo. We did tighten a few things:

    • We now include the engineer’s name and role on screen for the first five seconds of their segment.
    • We added a short written summary above the video in the changelog so readers can skim.
    • The PM tags the relevant Datadog dashboard when we talk about a performance fix, and shows the graph.

    The recording still takes forty minutes of prep and ten minutes to run. It is the same meeting we were already having on Friday. The only difference is that it is public now.

  • Three questions we ask in every 1:1

    Three questions we ask in every 1:1

    Our Tuesday 1:1s used to be a walkthrough of the Linear board. The manager already knew which tickets had moved. The report already knew which tickets had moved. Thirty minutes went by, nobody learned anything new, and the meeting notes in Notion read like a changelog with feelings.

    We killed the status update. In its place, we ask three questions, in this order, every week.

    The three questions

    1. What is the hardest thing about your work right now? Not the busiest thing. The hardest. The thing they think about in the shower.
    2. What could I be doing better as your manager? Asked directly, then followed by silence. No qualifiers, no “if anything.”
    3. What would you like more clarity on? Strategy, priorities, their scope, someone else’s scope, the roadmap for Q3. Anything.

    That is the meeting. If a status update is genuinely needed, GitHub, Linear, and the weekly Friday summary in Slack cover it better than a human voice does.

    Why these three

    Each question surfaces information that only the report has, and that they will not volunteer without an explicit invitation.

    The first question separates volume from difficulty. An engineer can close twelve tickets and still be stuck on the one that matters. A designer can ship four Figma flows and be quietly demoralised by the fifth. Asking about hardness, not throughput, is how we find out.

    The second question is the one managers dread and reports dread more. The first few weeks, the answer is almost always “nothing, you’re doing great.” We wait. By week four or five, something real comes out: we are too vague in code review, we defend the wrong decisions in leadership meetings, we schedule 1:1s at 5pm on Fridays. We write it down and act on one thing before the next 1:1.

    The third question is the cheapest lever we have. Most of what looks like a motivation problem or a performance problem is a clarity problem. If someone does not know how their Datadog dashboard maps to the company’s revenue goal, no amount of coaching will fix that. Telling them will.

    A 1:1 is not a meeting where the report proves they worked. It is a meeting where the manager finds out what they cannot see.

    Try it for a month. Delete the status template from your Notion page. Paste the three questions at the top. See what changes.

  • The 25-minute meeting

    The 25-minute meeting

    Six weeks ago we changed the default meeting length in Google Calendar from 30 minutes to 25. Nobody voted on it. Our head of ops flipped the setting on a Tuesday and sent a two-line note in Slack. We expected complaints. We got three, all in the first week, all from the same person.

    What those five minutes were doing

    We tracked what happened in the last five minutes of our standing 30-minute meetings for two weeks before the change. Someone volunteered to note the pattern at the end of every call they joined. The log lived in a Notion page called “tail time.” Here is what filled that window, ranked by frequency:

    • Small talk about weekend plans or a Netflix show, roughly 40% of the time.
    • Someone re-explaining a decision that had already been made, 25%.
    • Waiting for a person to find the right Figma link or Linear ticket, 20%.
    • Actual new work, 15%.

    The contrarian read: those minutes were not a buffer for depth. They were a tax on focus, paid so nobody had to end a call early and feel awkward about it.

    What we replaced it with

    Every recurring meeting now ends with a two-line summary posted in the meeting’s Slack thread within ten minutes. Line one is the decision. Line two is the owner and the date. No preamble, no thank-yous.

    Decision: ship the billing migration behind a flag on Nov 18. Owner: Priya, checkpoint Nov 15.

    The wrap-up ritual moved from voice to text, and the small talk moved to the first two minutes of the next call, where it belongs and where late joiners do not miss it.

    What we noticed after a month

    Our engineering weekly used to run 30 minutes and consistently ended at 32. It now runs 25 and ends at 24. The Monday product review, historically our worst offender, dropped from 60 to 50. We booked 14% fewer follow-up meetings across the org in October, measured against September’s baseline, because the Slack summaries closed the loop that the tail time used to leave open.

    The uncomfortable part: nobody misses the five minutes. We thought people would grieve the small talk. They did not. They grieved the recap, which is a different problem, and the two-line summary solved it in writing.

    If you want to try it, do not announce a policy. Change the default, post one summary after your next meeting, and see who copies you by Friday.

  • 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 three-frame Figma rule

    The three-frame Figma rule

    Every Monday at our design review, someone opens Figma and scrolls. And scrolls. Twenty frames, six alternate flows, a stray Miro embed, three sticky notes with question marks. By frame nine, nobody remembers what the proposal is for.

    We made a rule. Three frames. That is the budget.

    Why three frames

    Three frames force a story: state, action, result. You cannot fake that shape. If you cannot show the current state, the moment of change, and the outcome inside three frames, the idea is not ready. It might be interesting, but it is not buildable yet.

    We use the rule for anything that lands in our Linear “Ready for eng” column. Before a ticket moves out of Design, the linked Figma file needs:

    • Frame 1: the state the user is in when this matters
    • Frame 2: the action or decision point
    • Frame 3: what changes, what breaks, what they see next

    Three frames is not a rule about fidelity. Lo-fi wireframes count. Screenshots with red boxes count. Three annotated hand drawings count. The constraint is narrative, not craft.

    What the rule caught

    The first month we tried this, our design lead pulled six proposals back to discovery. One of them was a payments refactor that had ninety-two frames and no clear before or after. When she asked the designer to pick three, he could not. The empty state was fine. The success state was fine. The middle was a fog of edge cases and dependency guesses. That fog was the real work, and it was invisible under all the surface polish.

    Now, when a designer says they cannot get under three frames, we treat it as a signal, not a failure. It tends to mean one of these:

    1. The problem is two problems glued together, and we should split the ticket
    2. The team has not agreed on which user is being served
    3. We are drawing solutions before we have named the decision

    When we break it

    We break the rule for onboarding flows, migration paths, and anything with a compliance step that legal needs to review verbatim. Those are storyboards, not proposals. The distinction matters. A storyboard documents a sequence. A proposal argues for a change. Three frames is for the arguing.

    We keep the frame counter in the corner of every design review agenda. Nobody enforces it. It sits there, and the room reads it.

  • How we run design reviews without a design lead

    How we run design reviews without a design lead

    We do not have a design lead at Velo. We have four product designers, six engineers, two PMs, and a shared Figma library that grows about eight components per week. For a long time our design reviews were a bottleneck. One person owned the calendar, the queue, and the taste. When they were on PTO, everything stalled for a week.

    Six months ago we scrapped that model. We now run a weekly design review every Thursday at 2pm, rotating facilitator, and we ship through roughly ten designs per hour. Here is how it works.

    The three questions on every draft

    Every design that enters the queue answers three questions before anyone speaks. We put them at the top of the Notion review doc, and the designer fills them in when they submit.

    1. What is the smallest unit of behavior this changes? A button state, a full flow, or a shared component?
    2. What did we consider and reject? We ask for two rejected options with one sentence each.
    3. What are we not sure about? The designer flags the specific decision they want feedback on.

    The last question does the heavy lifting. Before we added it, reviews drifted into whatever the loudest person felt like discussing. Icon choice on a screen whose real question was permissions logic. Copy on a modal whose real question was the empty state upstream. Now the designer sets the target. If someone wants to raise something outside that target, they add a comment in the Figma file and we move on.

    We also cap each entry at 250 words of context and three frames of the design itself. If it needs more, it is two designs, and it splits into two queue entries.

    Who shows up

    The room is small on purpose. Five people, always:

    • The designer whose work is under review
    • A rotating facilitator, drawn from the design pod
    • One engineer from the squad that will build the work
    • One PM, usually the one who wrote the ticket in Linear
    • One outsider from a different squad

    The outsider is the piece we fought about the longest. Early on we ran reviews with only the squad that owned the work, and every review turned into a status meeting. People agreed with each other because they had agreed with each other three days ago. Adding one person who had no context forced the designer to explain the thing they had stopped seeing.

    We rotate the outsider through a Slack workflow. Every Monday morning a bot posts in #design-review with the week’s roster, drawn from a list of eleven people across four squads. If you get tagged and cannot make it, you swap with someone else in the thread. No one has skipped in eight weeks.

    The facilitator’s job is not to have opinions. It is to keep the clock, read the three questions aloud, and cut off tangents. We rotate facilitators every week so that the role does not calcify into a proxy design lead.

    How we hit ten designs per hour

    Six minutes per design, hard cap. The facilitator sets a timer in Slack, visible to everyone. When the timer hits zero, we stop, capture the decision or the follow-up in the Notion doc, and move on.

    Six minutes sounds absurd until you try it. What we found:

    • Most designs need one or two decisions, not twelve. The three questions narrow the surface.
    • The engineer catches feasibility issues in the first ninety seconds. If a design assumes a field we do not have in our GraphQL schema, that comes out fast.
    • The PM catches scope creep. If a design has quietly grown a new setting screen, the PM flags it and we decide whether the ticket needs a split in Linear.
    • The outsider catches the assumptions everyone in the squad shares. This is the highest value input we get, and it usually shows up in the last minute.

    If a design cannot be resolved in six minutes, it goes into a longer 30 minute slot on Friday. About one in six designs ends up there. We track this in a Notion database, and if the ratio climbs above 25 percent for a month, we know something is off in how designs enter the review, and we tune the three questions.

    What we gave up

    We gave up consistency of taste. Without a single lead, our components sometimes drift. We catch this with a monthly audit that anyone on the design pod can run against the Figma library, and we open a GitHub PR to reconcile the drift. It takes about three hours.

    We also gave up the comfort of a single person who says yes or no. Decisions in our reviews are made by the designer, informed by the room. The facilitator will push back if a decision is being avoided, but no one else has veto power. This felt scary for the first month. It stopped feeling scary once we noticed the queue kept moving.

  • Skip-level 1:1s done well

    Skip-level 1:1s done well

    We ran skip-level 1:1s badly for two years. They drifted into status updates, or they became grievance intake, or they quietly disappeared from calendars. Last spring we rebuilt the format. Thirty minutes, every eight weeks, two questions, and nothing gets written down as an action item while the meeting is happening. It has held up across three quarters.

    The format

    Each engineering director meets with every report of their direct reports on a rolling eight-week cadence. Meetings sit on Tuesday or Wednesday afternoons, never Monday, never Friday. The invite goes out from Notion with a two-line agenda and a note that says: no prep required, no slides, camera on.

    We ask the same two questions every time:

    • What is something your manager is doing well that you want them to keep doing?
    • What is one thing that would make your next eight weeks better, and who owns it?

    That is the whole script. The rest of the thirty minutes is follow-up, tangents, and listening. We used to open with “how are things going,” which produced thirty minutes of pleasant nothing.

    Why we banned in-meeting action items

    The old version of this meeting generated a Linear ticket or two per session, which felt productive and taught everyone the wrong lesson. People started curating what they said based on what they wanted to see filed. The signal degraded.

    Now the director takes no notes in the room. After the meeting, they spend ten minutes writing a private summary in Notion, then decide what, if anything, becomes a follow-up. Sometimes it is a Linear ticket. Sometimes it is a quiet word with the manager. Sometimes it is nothing, and that is the correct answer.

    The best skip-level we ran last quarter produced zero tickets and one changed mind about a promotion case.

    What we track

    We keep a single Notion database with one row per skip-level. Fields are minimal:

    1. Date and attendees.
    2. A one-sentence temperature reading: green, yellow, or red.
    3. A private summary field, visible only to the director and their manager.

    Two yellows in a row on the same manager triggers a conversation between the director and that manager within the week. Three reds anywhere in a quarter goes to the head of engineering. We have used the red rule twice. Both times it caught something we would have missed for another two months.

    The point of a skip-level is not information. It is trust. Thirty minutes, two questions, and the discipline to stop writing tickets long enough to hear the answer.

  • 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.