Velo Blog

Category: Leadership

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

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