Velo Blog

Tag: 1on1s

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