Job Fair and planning process

Planning summary

We plan in 3-months cycles, that are organized in the following way:

1. Call for input from sales and strategy updates
2. Call for projects (PR-FAQs or a new step in an existing PR-FAQ)
3. Call for staffing preferences of engineers
4. Global prioritization against the MSEM, ARR opportunities, and technical goals, so as to saturate engineering capacity.
5. Cycle starts! Off-cycle PR-FAQs are welcome, either to be considered for the next cycle or to make off-cycle adjustments.

Planning sequence

In what follows:

• a cycle is 3 months of work leading to a quarterly release (eg. Starship). Note that the release cycle is decorrelated from our financial planning cycle.
• D is the day the (development) cycle starts, and D+90 is the Starship release date.

Here’s our planning cycle:

• D-45: TPMs send reminders that planning will start soon!
  • Reminder to the go-to-market leadership to collect top 10 asks from customers
  • Reminder to everybody else to create PR-FAQs. Note that PR-FAQs can be raised on an ongoing basis, this is just a reminder.
• D-30 days: GTM leadership share the top 10 asks from customrs in #job-fair
• D-23: Deadline to submit projects for job fair prioritisation. Projects are submitted by raising a ticket. A project is either a new PR-FAQ, or a new milestone in an existing PR-FAQ. In both cases, the proposal needs to include a definition of a milestone that can be achieved in one quarter, and the staffing requirements.
• D-23 to D-17:
  • The prioritization team (PM/EMs/HoX/VPEng) reads PR-FAQs and creates a recommendation (or set of!) based on MSEM, revenue goals, and technical goals.
  • In parallel, engineers express their preferences on a set of PR-FAQs they’d like to join if prioritized.
• D-17 to D-10: prioritization week: prioritize the quarter ahead. 1 hour of job fair prioritization meeting every day until done
  • The prioritization team (PM/EMs/HoX/VPEng) start by prioritizing the next release
  • Then the release after that (more uncertain as will be re-assessed in the next cycle)
• D-10 to D-3: staffing week.
• D-3 to D: buffer, cycle starts
  • VPEng (or delegate) posts in #announce-company to share projects that have been greenlit.
• D+7: Updates to the customer facing roadmap by PMs and marketing are done.

This cadence will apply to most of PR-FAQs. A minority of PR-FAQs will also be greenlit on a rolling basis. If this process looks rigid, it isn’t. We’ll make adjustments in cycle if we have good reasons to make them. But having a planning cadence provides visibility to the team on when to submit PR-FAQs ideally (before planning!), when and how prioritization happens, and how far ahead we plan the roadmap and why. Note that as we go, prioritization will be easier and easier as we’ll have planned 2 cycles ahead and will only be making adjustments.

Roles and responsibilities

• TPMs are responsible for coordinating the cycle: sending calendar invites, reminders, organizing Job Fair meetings).
• PMs are responsible for the overal quality level of PR-FAQs (clear success criteria).
• The prioritization team (PM/EMs/HoX/VPEng) are responsible for prioritization and staffing

PR-FAQs

PR-FAQ stands for Press Release / FAQ. It’s a popular way to define projects by working backwards from the customer; there are many resources online with templates and discussions.

PR-FAQs should cover work that is at least 3 weeks for 1 engineer, either in the form of a standalone PR-FAQ, or in the form of a milestone defined in an existing PR-FAQ.

• Milestones and scope. PR-FAQs need to include a milestone to be delivered in one quarter, with a definition of its scope.
  • New PR-FAQs are often ambitious initiatives that will take several cycles to deliver. That’s great! However, we also want planning to be actionable and to deliver value to customers as fast as possible.
  • Continue working on an existing PR-FAQ. If you’ve worked on a PR-FAQ for one quarter, and want to keep working on it, then
    • Keep the same PR-FAQ (unless you prefer to start a new one).
    • Add a new milestone section that describes the scope of what you’re proposing to work on.
    • Raise a new PR-FAQ ticket, pointing to the milestone
    • Scoping doesn’t have to be fine-grained at this stage. For a working example, see the Sentinel roadmap. Each early step is a quarter, and later steps will be broken down further as we iterate.
  • There’s some ambiguity in the decision to raise a new PR-FAQ or to add a milestone in an existing one. There’s no wrong or right decision: do what makes it so your project is the easiest to understand.
  • The milestone should provide some customer value. It’s possible in 99.999% of the cases (it can be to an internal customer for platform or infra stuff). Get help from a PM if unsure here. If it’s not at all possible to deliver a valuable increment in a quarter, state it clearly as it is useful to know both for planning and for discussion about the proposal (can we make it smaller!).
• Staffing needed. PR-FAQs include the team needed to deliver the proposed one-quater (or less) milestone. Providing several options is encouraged! Eg. with 3 eng we might do x next cycle, with 2 eng we might do y, with 1 we won’t get anything valuable out.
• Authors. Most PR-FAQs should include design, engineering, and product authors to provide a well rounded perspective from each of the disciplines. One way to do that is to write the PR-FAQ, then quickly involve counterparts to make sure the approach, design, and scope make sense.
• Validation. PR-FAQs should be backed by user or customer insight: either through research, direct conversation with customers, or input from the GTM team. Any associated customer Product Gaps should be indicated on the PRFAQ.
• Metrics and measurable goals. PR-FAQs need to set metrics as part of the success criteria of a milestone. We understand that given our release and adoption cycle, it may be hard to measure things quarterly, so here are a few tips:
  • Feel free to scope down metrics to single-tenant Cloud only, because the adoption cycle is much faster there.
  • Feel free to define targets to be attained in 6 or 12 months if it’s impossible to measure 3-month results (preferred).
• “Umbrella projects” are deprecated and will not be used anymore.
• Duplicates. Try to avoid duplicate proposals or proposals about work already on some team’s roadmap. It’s a good idea to quickly survey what’s already on the roadmap before raising a proposal.
• Here are two examples of good PR-FAQs: Job Fair and Sourcergaph Own.

Backend/invisible/cleanup work

• For non-customer-facing work, such as “I want to replace the XYZ engine/library/layer”, if it’s longer than a month of work in 2023, then it has to go through the PR-FAQ process.
  • Head of Engineering is the business sponsor and will assign biz impact.
  • This is a way we can show the business the importance of the work we sponsor.
• Easiest way to get backend work approved is to tie it to a greenlit project by making it a prerequisite.
• There’s a fixed 20% budget of ALL Eng resources (i.e. 16 people at any time) allocated to “Infrastructure”, meaning they’re just doing the highest-priority tech cleanup.
  • This work will be in the Job Board under the umbrella project of Infrastructure.
  • The current recommendation is to write an RFC for any work you want in this bucket that takes longer than about a week, and we’ll prioritize it against all other open work (cross-functionally).

PM review

PMs (or Head of Engineering for non-customer facing/platform proposals) are in charge of reviewing PR-FAQs. This is non-blocking and just a way to ensure there’s a high standard for PR-FAQs and that the exec team can focus on reviewing the most impactful proposals first in case there are too many of them.

We don’t use a formal/complicated framework for evaluating impact for now, in order to keep things lightweight. We might someday introduce a more complicated opportunity canvas later on.

That said, here’s a rough guideline for evaluating impact of customer-facing features:

• High: Large ARR (>$5M ARR) or DAU (> 500 DAUs) impact, in the next 12 months. Fit with strategy. Well validated. Differentiated feature. Eg. a project like Batch Changes, Insights, Own, or adding support for a broadly-used codehost.
• Medium: Large ARR (>$1M ARR) or DAU (> 100 DAUs) impact, in the next 12 months. Fit with strategy. Elements of validation.
• Low: Unknown or unvalidated impact. No clear fit with strategy.