Captain, Crew & Ground Mechanics

Traditional agile frameworks have roles like Scrum Master, Product Owner, and Development Team. Flights replaces these with three roles that are simpler to understand, more flexible to assign, and grounded in a metaphor that makes the responsibilities self-evident. When you hear "captain," you immediately know who's in charge.

The Captain

Every flight has exactly one captain. The captain is the person ultimately responsible for the flight landing successfully. They set the course, make the tough calls, and ensure the crew has what they need to deliver. If the flight runs into trouble, the captain is the one deciding whether to push through, call an emergency, or return to takeoff for re-planning.

Here's what makes the captain role different from a traditional tech lead or project manager: anyone on the team can be a captain. It's not a permanent title tied to seniority. A mid-level engineer who has deep context on a particular feature area might captain a flight that a staff engineer flies as crew. The captain is chosen based on who's best positioned to drive this specific initiative - not who has the fanciest job title.

The captain's responsibilities include scoping the flight during takeoff, monitoring progress during active flight, unblocking crew members, communicating with stakeholders, and making scope adjustments when reality doesn't match the plan. They're not necessarily writing the most code - they're ensuring the flight delivers what it set out to deliver.

A good captain is proactive about communication. They surface risks early, adjust expectations with stakeholders before the landing date, and never let a flight silently drift past its target. When things go wrong, they call the emergency rather than hoping the problem will resolve itself. Transparency is the captain's most important tool.

Captaining a flight is also an excellent growth opportunity. For engineers looking to develop leadership skills, taking the captain role on a smaller flight gives them real-world practice in coordination, decision-making, and stakeholder communication without the pressure of a formal management title.

The Crew

Crew members are the individual contributors who execute the work within a flight. They pick up crates, build features, fix bugs, write tests, and ship code. The crew is where the actual value gets created.

A flight typically has two to five crew members, though the right number depends on the scope. A small, focused flight might only need two people. A larger cross-functional initiative might need a designer, three engineers, and a data analyst. The captain determines the crew composition during takeoff based on what skills the flight requires.

Crew members report to the captain for the duration of the flight. This doesn't mean micromanagement - it means the captain is the person they go to when they're blocked, when they finish a crate and need the next one, or when they discover that a crate is much larger than expected. The captain-crew relationship is collaborative, not hierarchical.

One important aspect of the crew role: crew members are focused. When you're assigned to a flight, that flight is your primary commitment. You're not splitting attention across three initiatives and context-switching all day. This focus is one of the biggest productivity benefits of the Flights methodology. A crew member on one flight will almost always outperform the same person split across three projects.

Crew members also have a voice in how the work gets done. If a crate is poorly scoped, the crew member should flag it. If there's a better technical approach than what was planned, they should propose it. The captain makes the final call, but good captains lean heavily on their crew's expertise and judgment.

Ground Mechanics

Not everyone is on a flight at all times - and that's by design. Ground mechanics are team members who are between flights, dedicating their time to the work that keeps the platform healthy: maintenance tasks, tech debt reduction, dependency updates, small bug fixes, tooling improvements, and the countless other things that would otherwise be neglected.

In most agile frameworks, maintenance work gets crammed into sprints alongside feature work, where it perpetually loses the priority battle. "We'll address the tech debt next sprint" is one of the most common lies in software engineering. Flights solves this by giving maintenance its own dedicated space and its own dedicated people.

Ground mechanics are meticulous in their product focus. They're the ones who notice that the CI pipeline has gotten 30% slower over the past month, that a deprecated library needs updating, or that an error log is filling up with warnings nobody has investigated. This attention to the unsexy-but-essential work is what keeps the platform in shape for the next flight.

The ground mechanic role is temporary and rotating. After a team member finishes a flight, they might spend a week or two as a mechanic before joining the next flight. This rotation ensures that everyone on the team gets exposure to the maintenance reality of the codebase - nobody can hide from tech debt when they regularly spend time as the one responsible for fixing it.

Being a ground mechanic is not a lesser role. It's a critical function that makes flights possible. Without mechanics keeping the runway clear, flights would take off and land on a crumbling strip of asphalt. The best teams recognise and value mechanic time as equal in importance to flight time.

How Roles Interact

The three roles form a natural ecosystem. The captain coordinates, the crew executes, and the mechanics maintain. At any given time, a team might have one active flight with a captain and three crew members, while two other team members serve as ground mechanics. When the flight lands, those roles shuffle for the next initiative.

Role rotation is a core part of Flights. The person who was captain on the last flight might be crew on the next one, and a mechanic the flight after that. This rotation prevents burnout - captaining is demanding work - and ensures that knowledge and leadership experience are distributed across the team rather than concentrated in one person.

Nobody is permanently a mechanic. If someone is always stuck on maintenance while everyone else flies exciting feature work, something is broken in your team's rotation. The captain and team lead (or whoever manages team composition) should actively ensure that mechanic duty is shared equitably. It's part of the deal: everyone flies, and everyone wrenches.

Communication between roles is lightweight. The captain communicates outward to stakeholders and inward to the crew. The crew communicates upward to the captain when they need help or have updates. The mechanics operate semi-independently but stay in the loop on active flights so they can provide support if an emergency is called. There are no formal handoff ceremonies or status escalation procedures - just people talking to each other.

When a flight hits an emergency, mechanics can temporarily join the flight as additional crew if needed. This flexibility is built into the model. The mechanics are the team's reserve capacity - available to help when things go sideways, then returning to maintenance when the situation stabilises. It's a natural safety net that most traditional frameworks lack entirely.