The Flight Lifecycle

A flight moves through a series of statuses that mirror - well, an actual flight. Each status communicates exactly where the initiative stands. The transitions between them are deliberately flexible - you can move freely between most statuses, because real projects rarely follow a straight line. The lifecycle gives structure without becoming a straitjacket.

Takeoff

Every flight begins at the gate. The takeoff phase is where the work gets scoped, the crew gets assigned, and the crates get loaded. Think of it as the preparation phase - the plane is on the runway, but it hasn't left the ground yet.

During takeoff, the captain is defining what this flight will deliver. What crates need to be on board? Who's flying? When do we expect to land? These questions should be answered before the flight goes active. That doesn't mean every detail needs to be figured out - you can load additional crates mid-flight - but the high-level scope and crew should be in place.

Takeoff is also a good time to think about which North Star - if any - this flight serves. Which organisational objective does the work connect to? Making that connection explicit (even if just in the flight description) helps the entire team understand why this work matters, not just what needs to be built.

Some teams use takeoff as a brief planning session - 30 minutes to align on scope, crew, and timeline. Others simply create the flight, load crates asynchronously, and move to active when they're ready. Both approaches work. The key is that the team has enough context to start executing when the flight goes active.

Active (In Flight)

The flight is in the air. This is where the real work happens. Crew members are completing crates, the captain is monitoring progress, and the team is shipping continuously. The active phase is where value gets delivered.

While a flight is active, it's visible in your team's flight tracking system. A flight's progress reflects crate completion and time elapsed. If the flight is approaching its landing date and crates are behind, the visual indicators make that obvious without anyone needing to run a report.

The captain's job during active flight is to keep things moving. That means unblocking crew members, adjusting scope if needed, communicating with stakeholders, and making the call to drop crates or extend the timeline if the original plan turns out to be unrealistic. This is leadership in practice - not managing tasks, but enabling the team to deliver.

Active flights should have a natural rhythm. How that rhythm looks depends on your team. Some teams do a brief daily check-in. Others use async updates in Slack. The point is that communication is happening and blockers are surfaced quickly. The methodology doesn't prescribe how - it just makes the status visible so problems can't hide.

Emergency Landing

Sometimes flights hit turbulence. A critical dependency falls through. A production incident demands the crew's attention. A fundamental assumption turns out to be wrong. When this happens, the flight moves to emergency status - and that's a good thing.

Emergency is not a failure state. It's a safety mechanism. In aviation, an emergency landing is a deliberate decision to prioritise safety over schedule. The Flights methodology works the same way. Calling an emergency is an act of transparency and leadership, not an admission of defeat.

When a flight enters emergency, it signals to the entire organisation that this initiative needs immediate attention. This visibility ensures that help arrives quickly and that stakeholders understand the situation without needing a lengthy status email.

The captain decides when to call an emergency and when to resolve it. An emergency flight can transition back to active once the blocker is cleared, move to landed if the team can still deliver the core scope, or return to takeoff if a fundamental re-plan is needed. The flexibility of these transitions ensures that the team always has a path forward.

Landed

The flight has arrived at its destination. All core crates have been delivered, the work is in production, and the initiative is complete. Landing is the moment to celebrate - the team shipped something meaningful.

A landed flight doesn't necessarily mean every single crate was completed. Sometimes scope gets adjusted mid-flight, and that's fine. What matters is that the flight achieved its objective. If the goal was to launch a new onboarding flow and it's live in production, the flight has landed - even if a few nice-to-have crates got deprioritised along the way.

Landing is a natural moment for reflection. What went well? What slowed us down? Were there surprises we didn't anticipate? This doesn't need to be a formal retrospective with a facilitator and a whiteboard. A quick team conversation - even async - can surface valuable insights for the next flight.

Landed flights remain visible when a flight moves to landing. This gives the team a sense of accomplishment and provides stakeholders with a clear record of what's been delivered. When it's time to move on, the flight transitions to archived.

Archived

Archived flights are the historical record. They're no longer active, no longer on the main board, but they're preserved for reference. Need to remember what was included in that infrastructure migration from three months ago? Check the archived flight.

Archiving is a deliberate action - flights don't auto-archive. This gives teams control over when a landed flight moves off the active board. Some teams archive immediately after landing. Others keep recently landed flights visible for a week or two so the accomplishment stays visible.

Archived flights can be viewed in a separate section of the dashboard, filtered and searched. The crew assignments, crate lists, and timeline data are all preserved. This historical data becomes valuable over time - it helps with planning future flights by giving you a realistic picture of what your team has delivered in the past.

In rare cases, an archived flight can be brought back to takeoff status. Maybe the work needs to be revisited, or a follow-up initiative builds directly on the previous flight. Rather than creating a new flight from scratch, you can reactivate the archived one and pick up where you left off.

Status Transitions

One of the best things about Flights is that you can move freely between statuses. The transition model is deliberately permissive - because real projects don't follow a straight line, and your tools shouldn't force them to.

Here's the full map of what you can do from each status:

• Takeoff can move to Active or Canceled.
• Active can move to Emergency, Landed, Takeoff, or Canceled.
• Emergency can move to Active, Landed, Takeoff, or Canceled.
• Landed can move to Archived, Active, Takeoff, or Canceled.
• Archived can move back to Takeoff.
• Canceled can move to Takeoff or Active.

Notice how generous this is. An active flight can go back to takeoff if the team needs to re-plan. A landed flight can reopen as active if a critical issue surfaces. An emergency flight can land directly if the team delivered despite the turbulence. Almost every status can be canceled, and canceled flights can be revived. The only status with a real constraint is archived - it must go through takeoff first, because reactivating a historical flight is an intentional act that deserves a fresh planning pass.

This flexibility is a feature, not a loophole. Rigid state machines that only allow forward movement force teams to work around their own tools. Need to reopen a flight you just landed because you missed something? Go ahead. Need to send an active flight back to takeoff because priorities shifted? No problem. The tool trusts your team to make the right call.