Build
Engineering leads. The work is moving. Your job is to make it easy for them to go fast — not to direct the work, not to hover, but to be present in a useful way.
There is a difference between being available and being a presence that slows things down. Available means: when a question arises, you answer it quickly. When a decision needs to be made, you make it. When a blocker appears, you clear it. Not hovering means: you're not asking for daily updates, you're not sitting in on every implementation decision, you're not adding requirements that weren't in the story.
The goal is maximum velocity. Your job is to protect it.
How to Show Up
Answer questions fast. When an engineer asks a question, the longer it sits unanswered, the more expensive it gets. They either wait, or they make a judgment call that may or may not match your intent. Neither is good. Same-day answers are the baseline. Same-hour is better.
Make decisions with confidence. You will be asked edge cases that weren't in the story. A user state you didn't account for. Two valid ways to handle an error. A design question with no obvious right answer. Make a call. Explain the reasoning if it's not obvious. Don't defer decisions back to another meeting — that's not PM. "Here's what I'd do and why" is.
Raise changes early. If a requirement changes — from client feedback, new information, a realization in review — don't absorb it quietly. Surface it immediately. Discuss the impact with the engineer. Update the release plan. Scope changes in the middle of build are expensive and normal; the failure mode isn't having them, it's hiding them.
When Things Change
Something material will change. A dependency will slip. A client will revise a requirement. A design will turn out to be infeasible. The original timeline will look wrong.
When this happens: say it immediately, to the engineer and to leadership. Update the release plan. Adjust milestones. If the change is significant enough to affect the story — who it's for, what it does — loop in PD as well.
The release plan is not a contract. It's a shared understanding of what's happening. Its only value is accuracy. A plan that reflects reality, even when that reality is "we're two weeks behind," is more useful than a plan frozen at the original intent.
What You're Watching For
A few signals that something is wrong:
The engineer is quiet for too long. Not because they don't need anything — because they're carrying a problem silently. Check in. Not "how's it going" — "what's blocking you right now?"
The scope is drifting. Features that weren't in the story are appearing. Someone added "just a small thing." The story is changing shape. None of these are automatically wrong, but all of them should be explicit decisions, not quiet additions.
The milestone is approaching and it doesn't feel right. Trust that feeling. Get on a call, look at what's actually done, and update the plan to reflect reality.
The Release Plan, Again
You wrote the release plan in Define. It is your responsibility to keep it accurate throughout Build. The engineer owns the code. You own the plan.
Every time a milestone slips, update it. Every time a requirement changes, update it. Every time the expected release date shifts, update it. By the time Build ends, the release plan should have the Launch date, the known scope, and a finalized version of the release notes — with nothing that will surprise anyone.
Next: Launch