After the Graph Is Built, Someone Still Has to Tell the Team What to Do

In the last post, the login dependency graph finally looked right to me. OAuth and the login form weren't chained in document order. Backend and frontend sat in parallel, both blocked on the same API contract, both blocking QA. Figuring out what actually blocks what had taken longer than I wanted, but we were past it.

Then we had a planning call. Everyone nodded. Two days later my frontend engineer pinged me on Slack: "So… what am I actually building this week?"

The graph was right. Nobody had a personal assignment.

The planning vacuum

Demos skip this part.

You can stare at a clean dependency graph in the tool and still have an empty Slack channel. The structure exists. The "what do I do on Monday morning" part does not. Somebody has to turn "here's the plan" into "here's your slice, here's what you're waiting on, here's the due date."

On most small teams I've worked on, that somebody is also the tech lead. You're writing tickets, @-ing people, chasing blockers, repeating yourself in three channels because half the team missed the planning meeting.

Post #1 was about the structure problem: stop faking a graph with disconnected tickets. This is different. The graph can be correct and the handoff can still fail. Everyone agrees in the room. Nobody leaves knowing what they personally own.

Why confirm isn't optional

I almost skipped the review step.

We were going through the login sprint graph. Tasks looked fine. Dependencies matched what we'd argued about in the last post. I was one click from confirming when I noticed rate limiting on auth endpoints sitting under Frontend.

That's backend work. Throttling login and password-reset endpoints belongs with the auth API, not the UI. The model had assigned it to Frontend because the spec mentioned rate limiting near the login form section. Same mistake family as OAuth-before-login: confident, plausible, wrong.

That's why AI sprint planning has a confirm step. The AI draft is fast. Review isn't bureaucracy. It's the difference between a plan your team can run and a plan that looks done until someone finds a misassigned task on day three.

I moved rate limiting to Backend. Checked that Alex's email was on the Backend lead field. Fixed a due date that didn't fit our staging window. Then I confirmed.

Ten minutes, maybe. Sending the wrong assignment to three engineers would have eaten more time than that before lunch.

Email as the broadcast layer

After confirm, Ravel emailed each department lead their assignments. Backend got auth API, rate limiting, session handling. Frontend got login UI and OAuth. QA got E2E scenarios and the staging integration checklist.

Each email listed what that department owned, plus enough context to start: dependencies, due dates, how we'd know the task was done. Nobody had to sign into a new tool to discover they had work. Nobody had to scan a shared board and guess which cards were theirs.

We send email on purpose. Your frontend engineer shouldn't need a Ravel account before they know what to build. They need a list in their inbox with enough context to start without a follow-up thread.

That doesn't replace standup or arguing about API shape. It does cut down on the "wait, what am I supposed to be doing?" message two days after planning.

What changed in practice

The login sprint started the way the graph said it would.

Backend and frontend got their emails the same morning and started the same day, both blocked on the API contract work already in flight. QA's email said explicitly to wait on both tracks before E2E, so they didn't have to read that from a board column.

I stopped being the router. I wasn't pinging Sam to ask if Jordan had started the auth API. The graph and the emails already spelled out who owned what.

What I don't have figured out yet is day two onward: PR merges unlocking downstream tasks, specs changing mid-sprint, GitHub activity updating the graph without someone clicking a status dropdown. Different problem. I'll write about that later.

Still early

Email distribution fixes the planning vacuum for us. It doesn't fix every coordination problem. It's one-way. It doesn't replace conversation. And it's useless if nobody reviews the graph before hitting confirm.

If you've worn the PM hat while also leading engineering, or lived through a great planning meeting followed by two quiet days on Slack, I'd like to hear what you do for the broadcast step. Manual assignment? Automate it? Hope people read the board?

We're building AI sprint planning around this at theravel.app. Take a look, or tell me what you use instead.