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.