Topic 8 — Working with engineering and design

Goal: Understand agile and scrum and how a PM collaborates with the team day to day.

Lesson 8.1 — Why teams stopped planning everything up front

Six months in, Maya still remembers a story Sam told her over coffee. At his old company, the team spent a full year building a product to a giant spec before they showed a single customer. When they finally launched, the market had moved on and half the features nobody wanted. A year of work, mostly wasted.

That older way of building has a name: waterfall. You plan everything up front, build for a long time, then reveal it all at the end. It looks tidy on paper. It falls apart when reality changes faster than your plan.

The reaction to that pain is agile. You'll see the word everywhere in tech, usually drowning in jargon. Underneath, it rests on one honest admission: we can't predict everything, so we work in small steps, get feedback often, and adapt. Maya already knows this shape. It's the Build–Measure–Learn loop from Topic 3, scaled up to a whole team building together.

The catch is that agile is a mindset, not a rulebook. Plenty of teams run every meeting on schedule and still resist changing anything they learn. That's agile theater: the rituals without the point of them.

Run every ceremony but refuse to actually adapt, and you're wearing the costume without doing the job.

For Maya, agile means her plans are living things. Her job is to keep handing the team the most valuable next piece of work, then adjust as the work teaches everyone something new.

Lesson 8.2 — The vocabulary of a sprint

Maya's first week at Lumi, the team kept using words she half-recognized. Sprint. Backlog. Standup. She nodded along and quietly looked them up that night. Most of them belong to Scrum, the most popular specific way teams "do agile." She doesn't have to run Scrum, but she has to speak it.

The vocabulary, with how each piece actually shows up in her week:

• A sprint is a short, fixed work cycle. Lumi runs two weeks, which is common. The team commits to a chunk of work and aims to finish it by the end.
• The backlog is the prioritized list of everything the team could build. Maya keeps it ordered, top to bottom.
• Sprint planning is the meeting where the team picks what to take on for the coming sprint.
• The daily standup is a quick sync, around fifteen minutes, in a simple format: what I finished, what I'm doing next, what's blocking me. Done, next, blocked.
• The review (or demo) happens at the sprint's end. The team shows what they built.
• The retrospective is the team reflecting on how to work better next time. Not a demo, not a hunt for someone to blame. Just an honest look at what to change.

None of this is busywork. Each piece feeds the loop: plan a small batch, sync daily so nobody stays stuck, show the work to get feedback, reflect to improve. And of all of it, Maya's single biggest contribution is the one thing only she can do well. A well-prioritized, clearly-defined backlog, so that when planning starts, the team picks up the right things instead of the loudest things.

Lesson 8.3 — When there are no sprints

Not every team works in sprints. Maya found this out when she asked Dan how the support-and-operations folks plan theirs, and he laughed. Their work doesn't arrive in tidy two-week batches. It arrives all day, unpredictably.

Teams like that often use Kanban instead. Picture a board with columns, To Do, In Progress, Done, and work moving across it in a continuous flow. No fixed sprints. People "pull" the next task when they free up capacity, rather than committing to a batch ahead of time. The big idea is limiting work in progress: don't start ten things at once, finish what you started before grabbing more.

Same agile spirit, different rhythm. Scrum moves in fixed time-boxes. Kanban flows continuously. Scrum suits planned, batchable work with a regular cadence. Kanban suits unpredictable streams like a support team. Plenty of teams blend the two and call it "Scrumban."

Maya doesn't have to choose the methodology. She does have to notice which one her team runs, so she can plug into it. Feed the backlog for Scrum. Keep the flow unblocked for Kanban.

Lesson 8.4 — What the PM actually does all day

So where does Maya fit inside all this? Start with what she is not. She isn't the team's manager, and she isn't running the Scrum mechanics, since that's often a Scrum Master's job. Nobody on that team reports to her.

Her role is to be the source of the what and the why. That breaks down into a handful of things she does, day in and day out.

She keeps the backlog prioritized, so the team always builds the most valuable thing next. She stays available, because engineers and designers ask her things constantly: "what should happen if the user has no internet?", "what if two people edit at once?" A PM who answers fast keeps everyone moving. She protects the team from thrash, the disruption that comes from constantly changing priorities and random requests landing mid-sprint. And she accepts the work, checking that what got built actually meets the acceptance criteria from Topic 7.

That second one, being available, sounds minor. It isn't. Imagine Sam stuck for a full day, waiting on Maya to answer "what should this button do?" while she's buried in meetings. That's a senior engineer's expensive day, idle, because of a thirty-second decision nobody made. Quick, clear answers are one of the most appreciated things a PM gives a team.

Lesson 8.5 — You have no authority, and that's the point

Here's the strange part of Maya's job. She has no power over anyone on her team. She can't assign work, can't approve raises, can't fire. So how does she lead a group of people who don't report to her?

By treating it as a partnership, not a command. Maya brings deep knowledge of the user and the goal. Sam and Priya bring deep knowledge of what's actually possible to build. When she respects their expertise on how, she earns the trust that lets her lead without authority, the thread that runs back to Topic 1.

In practice it comes down to how she shows up.

She brings problems, not finished orders. "Here's the user problem and what we're trying to achieve, how would you approach it?" invites Sam's best thinking. "Build exactly this" throws it away.

She involves the team early. People who help shape a plan feel ownership of it. People handed a sealed spec feel like order-takers, and they act like it.

And she gives credit while absorbing blame. When the feature wins, the team hears their names. When it goes sideways, Maya stands in front of it. Trust grows fast when a PM shares the wins and shields the team from the falls.

Get this right and the team wants to work with her, which, for someone with no authority over them, is the whole game. Get it wrong, and even a brilliant roadmap quietly stalls.

Worked example — A sprint in motion

Lumi is building the new weekly-budget feature, and Maya's team runs two-week sprints.

Going into sprint planning, she's done her part already. The backlog is prioritized, and the top items are clearly defined with acceptance criteria attached. So planning is quick: the team looks at the well-shaped top items and commits to a realistic batch without arguing about what each one even means.

Three days in, Sam hits a question. "If two users edit the same budget item at the same time, who wins?" He could guess. He could stall and move to other work. Instead he messages Maya, and she answers within the hour. He stays unblocked.

Midway through, Dan comes pushing. A big customer wants a "tiny" tweak, and he wants it this sprint. Maya hears him out, agrees it matters, and parks it for next sprint anyway. Letting it in would have shattered the team's focus. She absorbs Dan's frustration so the team doesn't feel it.

At the review, the team demos the working feature. At the retro, someone notes that Priya's designs landed late and that slowed everyone down. Nobody gets blamed. Maya simply commits to finalizing designs earlier next time.

Across the whole sprint, Maya never wrote a line of code and never ran a single ceremony. She kept the work prioritized, answered fast, protected focus, and partnered on getting better. That's the job.