What Alignment Looks Like on an AI-Native Team

Last post I said the first friction point we hit was alignment itself, the meetings. We'd scheduled our whole week around them, on the old theory that information is expensive to move so you batch it onto a calendar.

When agents do more of the building, that theory breaks. Your meetings get more expensive in relative terms because they're now the slow part. We had a standup that ran ~25 minutes for 11 people, and most of it was status theater, people narrating things the rest of us could have read. The few minutes that mattered were when two people found out they disagreed. That's the only thing a standup has ever been good for: catching a disagreement before it turns into rework.

So we stopped trying to make the meeting better and asked when alignment actually needs to happen. Turns out: at a few deliberate moments, and otherwise on demand. Here's the cadence we landed on.

Up front, once, before the code. For anything bigger than about a day, we write a one-page design doc and hold a single 30-minute call. 10 minutes everyone reads in silence, 20 minutes we argue the open questions, two follow-up calls max. The point isn't saving time. It's surfacing the judgment calls early. Any task worth a design doc has a handful of real decisions in it: an architecture choice, a tradeoff, a path not taken, the kind of thing someone else on the team might see differently. The silent read plus the argument gets those decisions in front of the people who'd disagree before they're baked into code, instead of finding the disagreement at review.

Each morning, async. A written morning message goes out: what's newly in flight without a PR yet, and what's blocked. It's a broadcast, not a meeting. Transparency, not routing. Two minutes to read, nobody in a room.

Once a day, live. A short daily call. It's written down and transcribed too, which matters more than it sounds. The transcript feeds the agent that drafts the next morning's message, so yesterday's decisions show up in tomorrow's broadcast without anyone re-typing them. The meeting is gone the second it ends. The record isn't.

Continuously, just in time, as people work. This one replaced most of our recurring syncs. Instead of a standing "PM + design + eng" slot booked in case a decision comes up, the work surfaces the decision when it actually hits one. And the everyday question, "what should I even be touching right now?", is answered by a tool we call /whats-next. It reads what every open PR is carrying: how big it is (roughly, how long to review), how important it is to the company, and how old it is (how much conflict risk it's piling up while it waits). It weighs those and tells each person the next move. Those three labels come back in the review post. They're the quiet backbone of a lot of this.

End of the week, on the things that matter most. The significant code changes get a closer look in a weekly Show & Tell, where the team votes on which ones to walk through together. (More on that in Post 5.)

So in one breath: align densely up front in the design doc, broadcast async every morning, meet briefly and in writing once a day, pull alignment just in time as you work, and review the week's biggest changes together at the end. Almost nothing sits on a recurring calendar slot "in case."

Now the honest part.

We over-corrected first. Our first move was to kill the standup outright. Mistake. Routing didn't need to be there, but visibility did. Within two weeks people had lost the thread of what everyone else was building, and surprises went up, not down. Transparency and coordination are different jobs, and we'd thrown out both when we only meant to throw out one. The thin morning message is us putting visibility back without the theater.

The "max 2 follow-ups" rule protects decision speed. A company's throughput is capped by how fast it decides, so we don't let anything turn into a long-running open thread. If a design isn't settled after two follow-ups, the answer isn't a third meeting. Split it: land the part everyone already agreed on, break the rest into its own tasks to decide separately. The limit forces the decomposition instead of letting one undecided question hold a whole feature hostage.

The principle under all of it: align once and hard at the start, then pull alignment exactly when uncertainty shows up. Don't push it onto a calendar and hope the calendar lands on the right day.

Which raises the next question. If alignment is cheap, the next bottleneck is the handoff itself, the gap between the person who decides what to build and the person who builds it. That's the one we hit hardest, and it's where this gets uncomfortable: our PMs and designers started opening pull requests. That's the next post.