The path to growth for all engineers is through ownership and communication. As the team takes on increasingly complicated work, communicating clearly in public channels allows Flights to run more parallel (and related) projects simultaneously. This should also help prevent surprise interactions and make onboarding easier for new teammates.

We use the roles Pilot and Copilot to assign responsibility for our features and efforts - but first, let’s clarify what we mean by “ownership”.

Owning the epic

Outside of actual code changes, there is other groundwork that helps up build the right features and avoid being surprised by complexity.

Here’s work apart from code changes that needs to happen for feature (and migration) development:

1. Working with product to understand commercial reasons behind features

   a. Why are we building what we’re building? Does it benefit us now, and/or, make it easier to build features and value later?

2. Determining scope of a feature

   a. Locales, regions, brands, screen sizes, platforms, K4B / Leisure

   b. If we don’t intend to ship a feature across all of the above regions / brands / etc, how do we handle that complexity?

   c. What might it cost not to rollout a feature worldwide?

   d. Ex: Horizontal multibook in LATAM

3. Working with design to plan features responsibly

   a. Kickoff meetings - “What will this feature look like and what does it hope to accomplish?”

   b. Handoff meetings - “Here are the final designs with edge cases handled and no big unknown questions unanswered”

4. Define acceptance criteria

   a. Refining and pointing tickets with the team

   b. Doing Given, When, Then, How

   c. Handle estimation with other engineers to predict rough cost

   d. This allows product to plan what is possible quarter over quarter

5. Working with backend to fix any interesting issues with APIs, expected data, or other testing wrinkles

6. Owning communications in Jira and in the Slack epic channel Slack

   a. Name the channel something reasonable based on Jira ticket

   b. Prefix with the Jira epic and use the feature name for the suffix

   c. Example: #r9e-39346-two-step-uwl

   d. Triage and handle communications with other teams

   e. Raise pressing or dangerous bugs to PM or EM

   f. Makes it clear when a feature or XP will be turned on with an expected timeline

7. Understanding and planning architectural changes and challenges

   a. Does this feature make sense in all contexts?

   b. Does this increase our tech debt, and make it harder to develop features in the future?

   c. Are these tradeoffs that we (engineers) and product are ok making for now?

   d. Is given work impacted by other ongoing migrations or code shifts? How can we be defensive about delivery in an ever-shifting codebase?

8. Balancing implementation tradeoffs and prioritizing bug fixes, as we move to compete work against deadlines and other external pressures.

   a. When things go wrong, and bugs crop up, have we made it clear to stakeholders (internal and external) what our paths forward are?

   b. Have we clearly laid out all options with rough costs?

9. Handling XP rollout, examining performance, investigating any metrics problems and being vocal with product how we’ll handle them

   a. Communicate this in #xp-updates

   b. Communicate updates in the Slack epic channel

   c. Doing analysis based on region, other features, locale, brand, etc in the XP console and Dashmore

There’s a lot more to developing features than just making code changes.

Feature examples

1. FLY-95: FRP: Responsive XS-S - Flights mWeb FRP migration

   a. Glenn is the Pilot, with the rest of the team supporting as Copilot (not enough work to warrant a dedicated Copilot)

   c. He’s responsible for helping triage issues, delegating work to Foundation as appropriate, investigating metrics problems around search volume and session volume

   d. Communication is handled in #fly-95-mweb-flights-responsive-rp

   e. He’s working with Luciana to understand which bugs are which priority, and what metrics we care about for defaulting the XP

2. R9E-26139: NON-2-step: Add itinerary in details tab - Splitting itinerary and booking options into two tabs for FDP

   a. Rita is the Pilot, and Ted is the Copilot

   b. She’s responsible for the development and architecture of the feature

   c. As we turn on the XP, she’ll handle communicating that in channel, working with PMs and Designers to triage and fix bugs

Roles

Pilot

At the end of the day, the Pilot is responsible for successful delivery of the feature. They should take as much of the above list as they can.

That being said - growth takes time, and none of us can do everything perfectly. It’s ok to distribute responsibility as long we’re being vocal about it - we’re here to support each other, since our successes and failures are shared.

Copilot

The Copilot is the backup! They can serve as a sounding board or backup for any of the above responsibilities. The Copilot should aim to have the same context and understanding as the Pilot.

Having a buddy here means also that either of the two can take time off, and we don’t lose knowledge in one person’s head until they return.

Questions

Q. Should other folks expect to work on things they don’t Pilot or Copilot?

A. Yes - some epics will have more work than can be done by one or two engineers. There may also be work that can be parallelized for more than two people, because development isn’t linear or dependent.

Q. If someone is out for vacation, do we reassign roles?

A. No - it should be quite unlikely that both Pilot and Copilot for a feature are on PTO at the same time. Knowledge of the feature or migration still ultimately belongs to those two engineers, and they should keep folks up to date if joint longer time off is coming up.

Q. For bigger epics (migrations), Glenn only has “Team” as his Copilot - does that mean we’re all supposed to have the context and help lift the load? What happens if someone DMs me and I don’t have context?

A. Yes - we might not understand the responsive migrations as deeply, but they impact all the product work that we’re doing.

You can always redirect questions you’re not sure how to answer to #ask-flights, or the appropriate epic channel for more help from your team.