Keeping the Runway Clear

Every airport needs ground crews. The people who refuel the planes, fix the landing gear, clear debris from the runway, and make sure the next flight can take off safely. In the Flights methodology, ground mechanics fill exactly this role - and they're just as important as the crew in the air.

The Role of Ground Mechanics

Ground mechanics are team members who are not assigned to any active flight. Instead, they're dedicated to platform health - the steady, unglamorous work that keeps everything running smoothly while the rest of the team is shipping features.

In most agile frameworks, maintenance work competes directly with feature work for sprint capacity. The result is predictable: features always win because they're visible and exciting, while tech debt accumulates silently until it becomes a crisis. Flights solves this by giving maintenance its own dedicated lane.

Ground mechanics are the unsung heroes of the team. They're the reason deployments don't break on Friday afternoons. They're the reason that dependency update doesn't sit in a PR for three months. They're the reason the CI pipeline runs in 4 minutes instead of 40. When a flight lands smoothly, it's often because a ground mechanic cleared the runway first.

The role carries real responsibility. Ground mechanics need to be self-directed - there's no captain assigning them crates. They look at the platform, identify what needs attention, and fix it. This requires experience, judgment, and the kind of engineering taste that knows the difference between a critical vulnerability and a cosmetic warning.

What Mechanics Work On

The ground mechanic's domain is broad. Bug fixes that aren't tied to any active flight. Dependency updates - keeping libraries current so security vulnerabilities don't pile up. Performance improvements that benefit the entire platform. Small features that are too minor to justify their own flight but too useful to ignore.

Documentation is prime ground mechanic territory. The kind of documentation that everyone knows needs updating but nobody prioritizes because there's always a more exciting crate to work on. Runbooks, API docs, onboarding guides, architecture decision records - ground mechanics keep these alive.

Tooling improvements are another sweet spot. Build system optimizations. Test infrastructure upgrades. Developer experience improvements like better linting rules, faster hot reload, or improved error messages. These investments compound over time and make every future flight faster, but they'll never survive a prioritization meeting against a customer-facing feature.

Ground mechanics also handle the leftover crates that didn't make it onto a flight. When a captain triages incomplete work during landing, some of those crates end up in the ground mechanic's queue. These are typically small, self-contained tasks that don't need the coordination overhead of a full flight.

Rotating Mechanics

Nobody should be a permanent ground mechanic. This is one of the strongest opinions in the Flights methodology, and it's non-negotiable. If the same person is always on ground duty, two bad things happen: they lose touch with feature development, and the rest of the team never builds empathy for the maintenance burden.

Rotate the ground mechanic role every flight cycle. When a flight lands and a new one takes off, shuffle who's on the ground. The person who was a captain last flight might be a ground mechanic this cycle. The crew member who just shipped a major feature might spend the next two weeks on platform health.

Rotation has a powerful secondary benefit: fresh eyes. A developer who has been heads-down on a feature for two weeks comes back to ground duty and immediately notices things that a long-term mechanic would have stopped seeing. "Why is this test so slow?" "Why are we still on version 2 of this library?" "Who wrote this and why?" Fresh perspective catches problems that familiarity hides.

Some team members will enjoy ground duty more than others - and that's fine. The developers who love gardening codebases, cleaning up tech debt, and optimizing builds can volunteer for ground duty more often. Just make sure it's not exclusively their job. Everyone on the team should experience both sides: the thrill of shipping a feature flight and the satisfaction of keeping the platform healthy.

Balancing Flights and Maintenance

The golden ratio between flight crew and ground mechanics depends on your team size, your codebase maturity, and how much maintenance debt you're carrying. There's no universal formula, but there are useful guidelines.

For a team of six, having one to two ground mechanics at any given time keeps things healthy. That means four to five people are on active flights while one or two keep the lights on. This ratio ensures that maintenance gets consistent attention without starving the team's ability to ship features.

If you have too few ground mechanics, tech debt accumulates. Builds get slower. Dependencies fall behind. Small bugs pile up into a swamp of paper cuts that frustrates users and demoralizes developers. You'll know you're under-investing in ground work when every flight starts hitting unexpected infrastructure problems.

If you have too many ground mechanics, nothing ships. The platform might be pristine, but the product isn't moving forward. Leadership starts asking why the team isn't delivering features. You'll know you've over-rotated when the ground mechanics start running out of meaningful work and begin gold-plating things that don't need it.

Adjust the ratio based on signals. If your last three flights all hit infrastructure blockers, you need more ground mechanics. If your tech health is solid and there's a backlog of high-priority features, scale ground duty down temporarily. The ratio should flex with the team's needs, not be set in stone. The captain and team lead should revisit the balance at each flight boundary - it only takes a minute and it prevents the team from drifting too far in either direction.