Stakeholders, Meetings and Change

"Product wants it Friday." "Management asks why this is taking so long." "Can we skip the meeting?" "How do we change how the team works?" This lesson gives plain ways to handle these. It covers talking to stakeholders (the people who care about your work or are affected by it), running meetings, introducing change, and planning.

Read Lesson 0 first for the answer shape, Lesson 3 for estimates, and Lesson 5 for writing design docs.

Everything here is common practice and opinion. Teams and companies differ a lot. Use the ideas, not the exact words, and always use your own true examples.

Words used in this lesson

• A stakeholder is a person or group who cares about the result or is affected by it: product, design, support, sales, management, users.
• Alignment means people agree on the goal, the plan and who does what.
• Output is what you build and ship. Outcome is the change it makes for users or the business.
• A milestone is a checkpoint on the way to a bigger goal.
• An agenda is the list of topics for a meeting, with the decision or result you need from each.
• Nemawashi is a Japanese word for quietly building support for a change with the people affected, before you propose it formally.
• Process bankruptcy means deciding to drop the old way of working and start with a small new one, instead of fixing every old rule.

Talk about the why before the what

The communication section of the list has four useful ideas:

• Narratives move people more than facts. One article says to explain the why before the what, and to repeat it. In practice: "Support gets 40 tickets a week about this (why). So we will rebuild the page in two steps (what)."
• Avoid the "apple pie" statement. Shreyas Doshi's "Apple Pie Position" is described as an unobjectionable statement that makes the speaker sound good but adds little ("we should focus on quality"). Say something someone could disagree with, and give a reason.
• Disagree about the point, not the tone. Paul Graham's "How to Disagree", as the list describes it, aims to refute the central point rather than attacking tone or the person.
• When trust is low, an article advises: acknowledge the difficulty, speak tentatively, and aim for at least five positive interactions for each negative one.

A short update that managers can use (my own)

Status: on track | at risk | blockedDone: <one line, in user terms>Next: <one line>Risk: <what could go wrong, how likely, what we are doing about it>Need from you: <a decision or a thing, with a date>

Put the status and the ask at the top. A busy reader should be able to stop after two lines. Use numbers, not "a lot" or "soon".

Meetings: fewer, shorter, written

Ideas from the list:

• Cancel the meeting if you can live with the outcome. An article with this title says: if you would accept the result without the meeting, skip it.
• Write it down. "The Document Culture of Amazon" is described as saying written documents reduce bias and avoid audio and screen-sharing problems. A one-page document read quietly can replace a long presentation. (See Lesson 5.)
• Know the anti-patterns. Simple Sabotage (listed in the meetings section) covers meeting anti-patterns and how to fix them. I have not read it, so I do not list its points.
• Better meetings. Lara Hogan's "On Better Meetings" is listed with tips for efficient meetings but no specifics on the page.

A simple rule set (my own):

1. Every meeting has a purpose and an owner: "decide X" or "share Y". If it is "share", try a written update first.
2. Send the agenda and the document before, and say what decision is needed.
3. Invite only those who decide or are affected. Others read the notes.
4. End with actions: who does what by when. Send them the same day.
5. Keep it short, and stop early when the work is done.
6. Automate the small things so the meeting is not spent on bikeshedding (see Lesson 7).

Introducing change: prepare people first

• Nemawashi. The change-management section of the list mentions it: quietly build support before you propose a change. Talk to the most affected people one by one, hear their worries, and change the proposal. When the formal discussion happens, there should be no big surprise.
• Why the status quo is hard to change. One article in the list discusses learned helplessness in teams ("nothing ever changes here") and suggests declaring process bankruptcy: stop trying to fix every old rule, and try a small, new, clear way of working.
• Start small. Try the change for one team or one month, measure, and then decide. See the reversible-decision idea in Lesson 0.
• Let people who disagree speak. Resistance often carries real information about risks you missed.

A simple plan for a change (my own): why now (the problem, in numbers), what changes (small and concrete), who is affected (and talked to), how we will know it works (a measure), how we go back (if it fails), and when we review (a date).

Planning: outcomes, milestones and honest dates

• Objectives and milestones. The list credits High Output Management (Andy Grove) with a simple frame: an objective is "where do I want to go", and milestones are "how will I pace myself".
• Estimate, target, commitment, plan. One article in the list separates these four words. Many fights come from one person saying "target" and another hearing "commitment". See Lesson 3.
• Estimating is still worth doing. Two articles in the list ("Software Estimation Is Hard. Do It Anyway" and "Yes, You Should Estimate Software Projects") argue that estimates are necessary for planning, even though they are imperfect.
• Fixed time, flexible scope. Shape Up from Basecamp is listed as using fixed-length cycles and assigning whole projects to teams. Whether you like it or not, the useful idea is: when time is fixed and the work is bigger than expected, cut scope, not quality.
• Outcomes over output. Escaping the Build Trap (Melissa Perri) is cited in the list for its warning against valuing shipping over customer outcomes. Ask: "What should be different for users after this ships, and how will we see it?"

Interview questions

Key takeaways

• Start updates with the status and the ask. Use numbers.
• Explain the why before the what, and say something somebody could disagree with.
• Meetings: a purpose, an owner, the agenda and document first, only the people needed, actions with names and dates. Cancel if you can live without the outcome.
• Prepare people before a change (nemawashi), start small with a measure and a way back, and listen to those who disagree.
• Plan with objectives and milestones. Keep "estimate, target, commitment, plan" separate. When time is fixed, cut scope, not quality.
• Ask for outcomes, not only output: "What should be different after this ships?"
• This is common practice and opinion. Adapt it to your team.

What's next

Last: Sources and reading list, Lesson 11. Practise: write your next status update in the five-line shape (status, done, next, risk, need from you) and send it to a colleague. Ask whether they can stop reading after two lines.