Overview

Every engineer at Warp divides their engineering time between two tracks. We spend 80% of our eng time focused on our primary project/Pod, as described in [How We Solve User Problems at Warp](https://warpdev.notion.site/How-We-Solve-User-Problems-at-Warp-96c428c2e261433388f4e33ead6eeebf) and [How We Divide Eng Work at Warp](https://warpdev.notion.site/How-We-Divide-Eng-Work-at-Warp-46275bfbaafa4cab9878b1ffd12d6409) . We spend the remaining 20% of our time on our Warp Minor, described here.

Minors serve several functions for us as a company ansd an eng team:

1. They ensure we spend some of our time each quarter working on small, user-impacting issues across our product. They also help us spread that work across the whole eng team, as opposed to having a "cleanup" team.
2. They divide expertise across the eng team. For any issue you might run into in the code, there's likely a Minor that it corresponds to, and that helps you know who can help you. This avoids centralizing all expertise in a small number of tenured senior eng.
3. They provide a mechanism for consistent, long-term ownership, both for the component and the engineer. Warp values engineering generalism and mobility, and we'll move between different technical and product areas in our primary projects. Minors persist across pod and team changes, and so let us build the muscle of stable, long-term ownership.
4. Because they're largely self-directed, they're often the first opportunity that junior engineers have to define their own goals, build product sense, and practice building organizational alignment.

Each engineer works on one Minor from this list.

Command Input

Blocklist and Grid

Settings, Help and App Mgmt

Customization Features

Windows, Panes and Tabs

In-App Growth Features, Paywalls and Conversion

Subshells, SSH and Shell Integration

Warp Drive

UI Framework

Performance, Memory, Stability

Structuring Minor Work

The organization of Minor work echoes how we organize our primary projects.

• Every eng working on a Minor is part of a Pod, with a Pod Lead. By default, each engineer should be their own Pod of one, though if a Minor prefers they can structure themselves into a multi-person Pod and select a Pod Lead.
• The Pod Lead is the product and technical DRI for that Pod's work.
• Every Minor is associated with one of our Focus Areas, such that the TL of the FA has some expertise in, and is a stakeholder of, their Minor areas.
• At the start of each quarter, Pod Leads are responsible for planning the Pod's work. That will echo the program in [How We Solve User Problems at Warp](https://warpdev.notion.site/How-We-Solve-User-Problems-at-Warp-96c428c2e261433388f4e33ead6eeebf) , but faster/more lightweight.

Prioritizing and Planning Minor Work

At the start of each quarter, each Minor Pod needs to come up with a plan for the quarter. Here's how to do that (with strong echoes of [How We Solve User Problems at Warp](https://warpdev.notion.site/How-We-Solve-User-Problems-at-Warp-96c428c2e261433388f4e33ead6eeebf) ). The Pod Lead should drive this process.

1. Sourcing ideas. Get input from lots of sources: GH bugs and user feedback, people dropping comments in Slack channel, input from your stakeholders.
2. Identify what will be the highest impact (cost:benefit) thing you can do in your area.
   1. Come up with your own suggested plan - this should be a very rough draft or list of ideas.
   2. Build alignment with your stakeholders around that being the right answer. Describe what you think the right plan is (e.g. in your Slack channel), and solicit input from your stakeholders. Incorporate their input, describe the new plan, iterate until aligned.
   3. A Minor Pod's stakeholders will include anybody else working in the Minor, the Minor's TL, plus Zach and John.
   4. Sometimes the highest impact plan will be a medium-sized project. Sometimes it will be a bunch of bugs, whether unified around a theme or a true grab-bag. Sometimes it'll include wrapping up a project started in the previous quarter. Sometimes it'll be a mix of bugs and projects. That's all great. You should weave all of these together, optimizing for the maximal user impact you can deliver.
3. Finally, you'll want to record and communicate the plan. This means creating a Linear Project for your Pod, populating it, and stickying a link in your Slack channel.
   1. To keep folks up to date, you should also post a weekly Project Update. Often that’ll be, “No change this week,” and that’s fine!