During the Flight

Once a flight is active, the crew's job is to ship. The captain's job is to keep things on course. And the methodology's job is to stay out of the way. Here's how to keep a flight moving without drowning in process.

Daily Rhythm

Flights does not prescribe a daily standup. If your team gets value from a 10-minute morning sync, keep it. If your team communicates asynchronously through Slack, pull requests, and your shared flight tracking, that works too. The methodology is intentionally silent on daily rituals because no single cadence fits every team.

What matters is that the captain has visibility into progress. Your flight tracking system should give that visibility at a glance. Active flights are front and center. Crate completion shows how much cargo has been delivered. If the flight is on track, the captain can see that without asking anyone. If something is off, the captain sees that too.

The captain checks in with crew members as needed - not on a rigid schedule, but when something looks stuck or when priorities need to shift. This is leadership, not management. The captain is a peer who happens to own the outcome, not a project manager collecting status updates to paste into a slide deck.

If your team does hold daily syncs, keep them short and focused. Three questions work well: What did I land? What am I working on? Do I need help? Anything that takes more than two minutes to discuss gets taken offline. The goal is alignment, not exhaustive reporting.

Status Updates

Here's a radical idea: stop writing status reports. Your tracking system's status should eliminate the need for separate status reports. The flight status tells you where things stand - active, emergency, landed. The landing date tells you when it's expected to finish. The crates tell you what work is part of the flight. Anyone in the organisation can look at the board and understand what's happening without asking a single question.

This works because the flight status itself carries meaning. When the captain moves a flight from active to emergency, that's a status update. When a flight lands, that's a status update. The detailed progress on individual crates happens in your external tracker - the GitHub issues, Linear tickets, or Jira cards that the crates link to. The flight board gives you the big picture; the tracker gives you the details.

When leadership asks "what's the status of the checkout redesign flight?", the answer should be "check the board." If they need more detail, the crate links take them straight to the relevant tickets. No separate status report needed. Every status report that exists outside the board is a signal that the board isn't doing its job.

For exceptional situations - a major pivot, a significant risk, or a dependency that affects other teams - the captain communicates directly with stakeholders. But these are conversations, not reports. They happen when something actually changes, not on a weekly schedule regardless of whether anything happened.

Handling Blockers

Blockers are inevitable. Code depends on APIs that aren't ready. Designs change mid-flight. A critical team member gets sick. The question isn't whether you'll hit blockers - it's how quickly you respond to them.

When something blocks progress, the captain makes a call: can we work around it, or is this a real problem? Most blockers can be worked around. The API isn't ready? Mock it and keep building. The design changed? Ship with the current design and iterate. A crew member is out? Redistribute their crates among the remaining crew.

The captain's job during a blocker is to keep the flight moving, not to solve every problem personally. Sometimes that means reassigning crates. Sometimes it means descoping - dropping a crate from this flight and moving it to the next one. Sometimes it means pulling in help from outside the crew.

Quick blockers get resolved in-flight. The captain makes a decision, the crew adapts, and work continues. No formal process. No blocker review meetings. Just a captain doing their job. The key is speed - a blocker that lingers for three days does more damage than one that gets resolved (even imperfectly) in three hours.

Calling an Emergency

When a blocker is too big to work around - when it fundamentally threatens the flight's ability to land - the captain sets the flight status to "emergency." This is the aviation equivalent of declaring a mayday. It's a signal that says: this flight needs immediate attention from outside the crew.

Setting a flight to emergency is not a failure. It's a mature, responsible act. It means the captain has assessed the situation, determined that the crew can't resolve it alone, and is asking for help. Teams that stigmatize emergencies end up hiding problems until they're too big to fix. Teams that treat emergencies as a normal part of the process catch problems early and resolve them quickly.

Emergencies aren't always about the flight itself. Sometimes a flight goes into emergency because something else took priority. Another flight hit a crisis, a production incident pulled the crew away, or a new deadline reshuffled the team's focus. Setting a flight to emergency in this case signals honesty: we're not actively working on this right now, and everyone should know that.

Emergencies should be resolved quickly. The whole point of the signal is to get fast attention. When a flight goes into emergency, the team's leadership should respond within hours, not days. The resolution might be fixing the blocker, descoping the flight, bringing in additional crew, or landing early with a reduced scope.

Once the emergency is resolved, the flight moves back to active status and continues toward its landing date. If the emergency resulted in significant scope changes, the captain communicates those to stakeholders and adjusts the crate list accordingly. The flight continues - battered, perhaps, but still flying.

A pattern of frequent emergencies on a team is worth investigating. It might indicate that flights are being scoped too aggressively, that dependencies aren't being identified during planning, or that the team needs more support. But individual emergencies are healthy - they mean the system is working as designed.