Common Pitfalls

Flights is designed to be simple, but simple doesn't mean foolproof. Teams adopting the methodology - especially those coming from heavily prescriptive frameworks - tend to fall into a few recurring traps. Knowing what they are ahead of time can save you weeks of frustration.

Overloading Flights

This is the single most common mistake teams make. A flight starts with a clear objective - "rebuild the checkout flow" - and then someone adds "oh, and while we're at it, let's also update the payment integration, redesign the confirmation emails, and fix that caching bug that's been annoying us for months." Suddenly your focused two-week flight is a three-month odyssey with no clear finish line.

A good flight has a single, clear objective that you can state in one sentence. "Migrate the API from REST to GraphQL." "Launch the new onboarding flow." "Reduce page load time below 2 seconds." If your flight's objective requires the word "and" more than once, it's too broad. Split it into two flights.

The temptation to overload comes from a good place - teams want to be efficient and bundle related work together. But in practice, overloaded flights lose focus. The crew can't tell what matters most. The captain can't give a clear status because ten different workstreams are at ten different stages. And the landing date becomes meaningless because half the crates were stretch goals that nobody expected to finish.

The fix is simple: be ruthless about scope. If a crate doesn't directly serve the flight's stated objective, it belongs on a different flight or in the ground mechanics backlog. It's better to land a focused flight on time than to crash-land an overloaded one three weeks late.

Skipping Ground Mechanics

When every flight is urgent and every feature is a priority, it's tempting to put your entire team on flights and leave nobody on ground mechanics duty. This feels productive in the short term - more hands on the exciting work, faster delivery on the things stakeholders care about. But it's a trap.

Tech debt, bug fixes, dependency updates, infrastructure maintenance, flaky tests, monitoring gaps - these things don't announce themselves with a deadline. They accumulate silently, one small compromise at a time, until one day your CI pipeline takes 45 minutes, your test suite is 30% flaky, and deploying to production requires a prayer and a Slack message to three different people.

Ground mechanics exist to prevent this slow decay. Even if you can only spare one person on a rotating basis, that person handles the unglamorous but essential work that keeps the runway clear. They upgrade dependencies before they become security vulnerabilities. They fix flaky tests before the team stops trusting the suite. They address the small quality issues before they compound into big ones.

The rule of thumb: always reserve at least 15-20% of your team's capacity for ground mechanics. For a team of six, that's one person on rotation. It feels like you're giving up a crew member, but you're actually investing in the health of every future flight. A team with a clean runway launches flights faster than a team drowning in accumulated maintenance.

Ignoring Emergencies

Some teams treat the emergency status like a failure state - something shameful that reflects poorly on the captain or the team. This is backwards. Declaring an emergency is one of the healthiest things a team can do. It means they're being honest about the state of their work, and they're asking for help instead of silently struggling.

A team that never declares an emergency isn't a team without problems. It's a team that hides problems. They'll quietly descope the flight, silently push the landing date, or just stop updating the status and hope nobody notices. The work suffers, the team burns out, and leadership has no idea anything is wrong until the flight is three weeks overdue.

Emergencies should be normalised. When a critical external dependency falls through, declare an emergency. When a key crew member is unexpectedly out and the flight can't proceed, declare an emergency. When you discover mid-flight that the technical approach won't work and you need to pivot, declare an emergency. These are honest signals that the plan has changed and the team needs to regroup.

Leaders play a crucial role here. If declaring an emergency leads to blame, finger- pointing, or career consequences, teams will stop doing it. If it leads to support, problem-solving, and resource reallocation, teams will use it as intended. The emergency status is only as useful as the response it triggers.

The Captain Bottleneck

The captain role exists to provide clear accountability. One person owns the flight's success. But some captains interpret this as "I need to control everything" - reviewing every crate, approving every decision, being the single point of contact for all questions. This turns the captain from a coordinator into a bottleneck.

When the captain becomes a gatekeeper, the flight's speed is limited by the captain's availability. If the captain is in a meeting, work stalls. If the captain is on vacation, the flight drifts. If the captain is overloaded with their own crates plus all the coordination overhead, everything slows to a crawl.

A good captain enables the crew rather than gatekeeping them. They set the direction, remove blockers, and make the big calls - but they trust the crew to execute. A crew member shouldn't need the captain's approval to merge a PR, deploy a change, or make a technical decision within their crate's scope. The captain should be the person you go to when you're stuck, not the person you wait on for every step.

If you find that a flight can't make progress without the captain's direct involvement at every stage, that's a sign the role is being misused. The captain should be able to step away for a day and come back to find that the crew made reasonable progress on their own. If that's not happening, the captain needs to delegate more aggressively and the crew needs to take more ownership of their individual crates.

Infinite Flights

Flights are meant to be time-boxed. They take off, they fly, they land. But some flights never land. The scope keeps growing, the landing date keeps sliding, and after six weeks the team has lost track of what the original objective even was. The flight has become a permanent fixture of the dashboard rather than a focused initiative with a clear end.

Infinite flights usually start with good intentions. "We're almost done, just one more week." That becomes two weeks, then three. New crates get added faster than old ones get completed. The goal post moves because the original scope wasn't well-defined, or because stakeholders keep requesting additions, or because the team is reluctant to land a flight that doesn't feel "complete."

The fix is simple and uncomfortable: land what you have. If a flight has been active for more than three weeks, stop adding crates and start closing them out. Move incomplete work to a new flight with a fresh scope and fresh dates. It's better to land a flight that achieved 80% of its objective and start a follow-up than to let a flight drift indefinitely toward a 100% that never arrives.

Make it a team norm: if a flight hits its landing date and isn't done, triage immediately. Which crates are essential to land? Which can be moved to the next flight? Which can be dropped entirely? This forced triage is one of the most valuable aspects of time-boxing - it makes you confront priorities instead of avoiding them.