Set direction and written expectations

Supports: Developer, week 4 (Defend the roadmap), and the Master Developer review. Time: about two and a half hours. Rung on the agent ladder: mostly delegate, with a first look at govern.

1. Why this matters

When a team has no written direction, every person guesses. One guesses fast and builds the wrong thing. Another guesses carefully and waits for you. A third asks you the same question every day. All three are doing their best. The fault is in the missing page.

Agents make this more urgent, not less. A person who does not understand the goal will often stop and ask. An agent usually will not. It will pick a reading of your words and build it quickly. So the quality of your written direction now decides how much wrong work you can get in one afternoon.

This lesson is about the part of leadership that happens before anyone starts work: where we are going, what good looks like, how we work together and who decides what. In the Dojo, you write these things in your git repository, in plain words, so that a new colleague, a sponsor and an agent can all read the same page.

A Product Development Manager (PDM) owns this page. An agent can help you tidy it. It cannot know what your sponsor fears, what your team is tired of or which trade-off you are willing to make. Those are your decisions. People write the epics and the roadmap, and people write the direction too.

What the PDM decides here

You decide	You may delegate to an agent	You verify	Other disciplines involved
Where the team is going and why, what counts as success, which working rules apply and who owns each kind of decision	Tidying your draft, checking it for unclear words, drafting questions a new reader might ask, keeping the pages in the repository in sync	A new reader can say the goal, the check and the owner without asking you; the pages match the roadmap and the decision log	Finance (budget and time limits), operations (cover when someone is away), security and privacy (who may see what), design and engineering (where their judgement rules)

2. Key ideas, explained

Direction is not a plan

A plan says what happens, in order. A direction says where we are heading and why, so that people can choose well when the plan meets the real world. Plans change every week. A good direction changes a few times a year.

A one-page direction has five short parts:

1. Purpose. Who we help and what problem we solve.
2. Goal for this period. One result, in a sentence.
3. How we will know. One to three checks that a person can look at.
4. What we are not doing. The things we say no to for now.
5. Limits. Time, money, rules and promises we must keep.

If you have already written your roadmap and your not-doing list, you have most of this. The direction page is the short version that people read first.

A goal needs a check

“Make café owners happy” is a wish. “Two cafés run the return process alone for two weeks” is a goal, because anyone can look and say yes or no. The same idea sits behind the OKR method: an objective says where you want to go, and key results are the numbers or facts that show you got there. Google’s re:Work guide and Atlassian’s pages on goals show worked examples. You do not need the whole method. You need the habit: every goal comes with a check.

A useful test is to ask, “Could two people look at the same evidence and disagree about whether we reached it?” If yes, write the check again.

Three layers of expectation

Most people hear “expectations” and think of tasks. There are three layers, and each one needs words.

Layer	The question it answers	Example
Outcome	What result do you want from me?	“A café report that a café owner can read in five minutes.”
Ways of working	How do we work together?	“I reply to messages within one working day.”
Limits	What must I never do without asking?	“No new paid tools without the sponsor.”

Outcomes belong to a person or to an agent’s brief. Ways of working belong to the team, and everyone should help write them. Limits belong to you, and you must be able to explain each one.

Structure and clarity matter

Google’s team research, which you can read in the re:Work guide on team effectiveness, found five things that mattered most for teams at Google: whether people felt safe to take a risk in front of each other, whether they could depend on each other, whether they had structure and clarity, whether the work had meaning and whether they could see its impact. The third one is the subject of this lesson. The guide says people need to understand what is expected of them, the steps to get there and what follows from the result. This is one company’s data, so treat it as a strong hint and not a law. It still matches what most teams say when they are asked.

One owner for each decision

Many decisions go wrong because everyone thinks someone else is deciding, or because three people think they are. A simple fix is to name roles for each kind of decision. The DACI play from Atlassian is a short, free example. It uses four roles:

• Driver: the person who moves the decision forward and collects the facts.
• Approver: the one person who decides.
• Contributors: people who know the subject and give advice, but do not decide.
• Informed: people who are told after the decision.

The important word is “one” in “one approver”. If two people can say no, nobody can say yes. Write a short decision-rights table and keep it in your repository.

Working agreements

A working agreement is a short, shared page about how the team behaves. How fast we answer. Which channel for what. When we meet and when we write instead. How we disagree. What “done” means. The Atlassian play on working agreements gives a free workshop format. The value is not the page itself. The value is that the team talked, and that each person’s habits are now visible.

Agents need a version of this too. The page that tells an agent how to behave in your project (its rules, its limits and its definition of done) is a working agreement with a different reader. The same writing rules apply: short, plain, testable.

Give problems, not only tasks

Teams do better work when they are given a problem and the limits, and are allowed to choose the way. SVPG describes this as an empowered team, compared with a team that only builds a list of features. The idea applies to people and to agents, with one difference. A person may question the problem and come back with a better one. An agent will mostly do what the words say. So with an agent you give the problem, the limits and the checks, and you keep the right to change the problem yourself.

3. Step by step: write the pages

Step 1: Write the purpose in two sentences

Who do we help? What is hard for them today? If you cannot say it in two sentences, you do not know yet. Go back to your discovery notes.

Step 2: Choose one goal for this period

Pick the one result that matters most for the next four to eight weeks. Resist a list. If you have three goals, you have none.

Step 3: Write the checks

For the goal, write one to three checks. Each check names something a person can look at: a number, a file, a test with a real person. Add a date.

Step 4: Write the not-doing list and the limits

Copy the not-doing list from your roadmap. Add time, money and rules. Write why for each limit. A limit with no reason will be ignored or resented.

Step 5: Draft the working agreements with the team

Ask each person to bring three notes: how I work best, what helps me, what I find hard. Put them side by side. Choose five to eight shared rules and write them down. If you work alone, write the rules for your agents and for yourself.

Step 6: Write the decision-rights table

List the ten decisions that come up most: scope, order of epics, spending, release, customer promises, privacy questions, security questions, hiring and brand wording. For each, write the driver, the one approver, who gives advice and who is told. Keep it to one page.

Step 7: Test the pages on a reader

Give the pages to one person who was not involved. Ask them to say, without looking, the goal, the check and who decides on spending. Fix what they cannot say. Then give the pages to an agent and ask the same questions (see below).

Step 8: Review on a rhythm

Put a date in the pages for the next review. Direction pages that nobody reviews slowly become fiction.

4. Worked example: TrailMug

TrailMug is a fictional product: reusable cups for cafés. The team in this example is invented. It has the founder (the PDM), a part-time designer called Ana, a helper in support called Sam and several AI agents that draft and build under briefs.

Direction page (excerpt):

Purpose. We help small cafés give customers a cup they can bring back, without extra work for staff. Goal, until 18 December. Two cafés run the return process alone for two weeks. How we will know. (1) Both cafés finish at least ten returns each week without our help. (2) Staff say, in a short interview, that returns take them less effort than paper cups. (3) We have a written list of every time we had to step in. Not doing. Loyalty points. A phone app. More than two cafés. Limits. No new paid tools without a note to the sponsor. No customer data leaves the shared drive. Nothing is promised to a café in writing without the founder reading it.

The numbers here are examples to show the shape. They are not real results.

Decision rights (excerpt):

Decision	Driver	Approver	Advice	Told
Which cafés join the trial	Founder	Founder	Sam, sponsor	Ana
Wording on the café sign	Ana	Founder	Sam	Cafés
Any spending over the monthly limit	Founder	Sponsor	Finance adviser	Ana, Sam
What an agent may send to a café	Founder	Founder	Sam	Ana

Notice the last line. The answer is that an agent sends nothing alone. The founder reads and sends.

Working agreements (excerpt):

1. We answer messages within one working day. If you are away, say so.
2. Decisions go in the decision log the same day.
3. “Done” means the checks in the issue pass and a person has looked at the real product.
4. We disagree in writing first, then talk. The approver listens, then decides.
5. Agents work only from a written brief. Every agent change gets a person’s review before it joins the main branch.

What a first test found. Sam read the pages and could state the goal and the check. But when asked “who decides to let a third café join?”, Sam said “probably Ana”. The founder had not written that decision in the table. She added it, with herself as approver, and added a line to the not-doing list.

5. Working with AI agents on this

Delegate:

• Reading as a stranger. Give the agent the three pages and ask it to answer five questions a new colleague would ask. If it answers wrongly or says the pages do not say, you have found a gap.
• Finding unclear words. “List every sentence in this direction that two people could read differently.”
• Turning checks into a template. “From these three checks, draft a short table with the evidence to collect each week. Do not invent numbers.”
• Keeping the pages in step. “Compare the direction page with the roadmap. List any not-doing item that appears as an epic.”

Do yourself:

• Choose the purpose, the goal and the limits.
• Decide the checks and what counts as success.
• Choose who approves each decision, and tell the people.
• Hold the working-agreements conversation with the team.
• Decide when the direction is wrong and must change.

A brief you can adapt:

You are a new colleague who has never heard of this product. Read
the three files: direction.md, decision-rights.md and
working-agreements.md. Then answer, using only these files:
1. What is the goal, and by when?
2. How will we know we reached it?
3. Who decides on spending over the limit?
4. What are we not doing?
5. What must you never do without asking?
If a file does not say, answer "not stated" and name the file that
should say it. Do not guess. Then list every sentence that two
readers could understand in different ways.

How to check the output. Compare each answer with what you meant. “Not stated” answers show missing pages. Wrong answers show unclear words. Then do the same test with a person, because an agent often fills a gap with a plausible guess and sounds sure.

Where this sits on the ladder. Writing the direction page is the start of delegate: a task you hand over needs a goal, a check and a limit, and this page supplies them. The working agreements already begin to govern, because they are a written rule that holds when you are not in the room. When you later run several agent sessions at once (orchestrate), the same page tells each session what it may and may not do, and the decision-rights table tells it when to stop and wait for a person.

Disclose. If an agent helped you tidy the pages, say so at the foot of the file: “Drafted by me; tidied with an AI agent; I reviewed every line.” Read Disclose AI use.

6. Common mistakes

• A direction that is a slogan. “Delight our customers” tells no one what to do on Monday.
• A goal with no check. If you cannot tell whether you reached it, you will argue about it.
• Too many goals. Three goals mean none is protected when time runs short.
• Two approvers. Joint decisions often mean no decision. Name one person.
• Rules nobody wrote down. A rule that lives in your head is a surprise waiting to happen.
• Rules without reasons. People follow rules they understand, and break the ones they do not.
• Writing the pages once. Put a review date in them and keep it.
• Writing in long, clever sentences. Plain words, short sentences. A reader in a second language and an agent both need them.
• Giving an agent the task but not the limit. It will happily go past a line you never drew.
• Treating the agent’s “I understand” as proof. Test with questions.

7. Practice: the direction pack

Deliverable: in your git repository, in a folder team/:

1. direction.md: purpose, one goal for the period, one to three checks with dates, a not-doing list and limits with reasons. One page.
2. working-agreements.md: five to eight rules for how you, your colleagues and your agents work. If you work alone, write the rules for you and your agents.
3. decision-rights.md: a table of at least eight decisions with driver, approver, advice and told.
4. reader-test.md: the five questions you asked, the answers of one person and one agent, and what you changed.
5. Your AI-use line.

Commit with a message such as Add direction, working agreements and decision rights.

Check: a person who was not involved reads the pages for ten minutes and answers the five questions without looking. If they miss two or more, rewrite.

Stretch: pick one decision where two people currently think they decide. Hold a ten-minute talk, name one approver, record it in the log and tell everyone.

8. Checklist

• The direction fits on one page and uses plain words.
• The goal has one to three checks that a person can look at.
• The not-doing list and limits each have a reason.
• Working agreements were written with the people they affect.
• Every kind of decision has one approver.
• Agents work from written briefs and the written limits.
• A person who was not involved passed the reader test.
• The pages have a review date.
• I recorded my AI use.

9. Further learning

Google’s re:Work guides on team effectiveness and on setting goals with OKRs give you the research and the method behind clear expectations, and Atlassian’s pages on SMART goals show how to make a goal specific. Atlassian’s working agreements and DACI plays are free workshop guides that you can run with a small team. SVPG explains why to give teams problems and not only tasks. The plain language guide helps you write pages that a reader in a second language can follow. Next, give and receive feedback: the page you wrote here tells people what is expected, and feedback tells them how it is going.