Priorities tracker guide
Overview
The priorities tracker (internal, GitLab team members only) is one spreadsheet per quarter with seven tabs. Copy the previous quarter’s tracker so the old one stays a record, change the quarter settings on the Read me tab, and every tab recalculates.
This page is the reference for the spreadsheet: what each tab holds, how to write a row, how capacity is calculated, and which checks a row has to pass before plan lock. The process the tracker supports, including the review cadence, the swap rules and the quarter close, is on the Quarterly planning page.
The tabs
| Tab | What it is | Who fills it |
|---|---|---|
| Read me | Quarter settings (dates, holiday weeks, committed ceiling, plan lock, review cadence, stale window) and the rules in short form | Tracker owner |
| Summary | The 20-minute review agenda and the execution scorecard. All formulas | Nobody |
| Org bets | The three to five outcomes that define the quarter, ranked, each with an appetite, and the org-level list of what we are explicitly not doing | Tracker owner |
| Priorities | The plan. One row per priority, three to five per team, ranked. Plan, track, check and close columns | EMs, then row owners |
| Capacity | Engineers, absences, nominal capacity and ceiling per team, with live counts pulled from the Priorities tab | EMs confirm counts before plan lock |
| Two-pager | The template each team copies before the quarter | EM, co-signed by the PM |
| Review log | One line per review, including canceled ones, with dates generated from plan lock plus cadence | Tracker owner |
Conventions inside the tracker: yellow cells are yours to fill; blue text is a number you typed and black text is a formula, so leave formulas alone; gray italic rows are examples to overwrite. Dropdowns are enforced. If you need a value that is not in a dropdown, ask the tracker owner rather than typing around it. Row IDs are the team code plus a number, such as DRF-1, and are generated for you.
The Two-pager
Each team writes one before plan lock. Two printed pages is the limit, because that is about as much as a reviewer can hold in their head at once, and longer plans tend not to get read. The tracker owner reads sections 3, 5, 6 and 8 first.
| # | Section | What goes in it |
|---|---|---|
| 1 | Team | Team exactly as named on the Capacity tab, EM, PM, date |
| 2 | Capacity | Engineers (FTE; a new hire counts as 0.5 for their first eight weeks), known absences in engineer-weeks, nominal capacity and committed ceiling. The formulas are in Capacity and the committed ceiling |
| 3 | Where we were | Three lines, no more: what we said last quarter, what happened, what we learned. Plus last quarter’s say/do |
| 4 | Priorities, ranked | Three to five rows in the same shape as the Priorities tab. Copy them across when done |
| 5 | What we need from other teams | What, from whom, by when, and who accepted it by name and date. A dependency nobody accepted is a hope |
| 6 | Explicitly not doing this quarter | What we are not doing, who asked, and what we told them or when we will revisit. This list is how we protect the plan and avoid re-litigating it in week 6 |
| 7 | Risks | The risk, the early signal, and what we would do about it |
| 8 | Decisions I need from leadership | The decision, by when, and the cost of not deciding. This is the highest-value section on the page |
Anatomy of a row
Each row on the Priorities tab has four groups of columns. The EM fills in the plan columns before lock. The track columns change every review cycle. The checks column is a formula, and the close columns are filled in once, at quarter end.
Plan. Team, rank, org bet, outcome, metric, baseline, target, owner, tier, confidence, appetite in engineer-weeks, stop signal, check-by date, depends on, dependency accepted by, epic link.
- The outcome reads “By [date], [who] does [what]”. The metric, baseline and target make it checkable.
- The stop signal reads “If [this], we [do that]”. The check-by date is when we look at it. When it passes, the row is flagged until the EM decides: continue with a new date, swap, or deprioritize.
- Depends on names a row ID that exists in the plan, or
EXT: [team] — [what]for a team outside Search and Data Platform, orNone. The providing team accepts it by name and date. - Committed rows link to the epic where the work itself is tracked.
Track. Current value, status, last update, and a change log of dated lines, newest first.
Checks. One cell that reads OK or names the rule the row breaks. Every row must read OK to lock.
Close. Final value, result (Hit, Partial or Miss), and the three close-out lines.
The same row written first as a task, then as a bet:
- As a task: Deliver the usage dashboards public beta by Dec 15. This only tells you what the calendar says.
- As a bet: By quarter end, 25 engineering leaders across 10 design-partner accounts return to the usage dashboard weekly. Metric: weekly returning leaders, baseline 0, target 25. Committed, 80%. Appetite: 26 engineer-weeks. Owner: one name. Stop signal: if fewer than 5 leaders are returning four weeks into beta, we stop adding views and fix data trust first; check by the end of week 6. Depends on
DIP-1, accepted by name. This tells you whether it worked and when to stop.
Capacity and the committed ceiling
Capacity is a calculation, and the Capacity tab does it from the quarter settings and the numbers each EM confirms before plan lock.
- Nominal capacity = engineers × (weeks in quarter − holiday weeks) − known absences, in engineer-weeks.
- Committed ceiling = nominal capacity × 70%.
- The other 30% is the reserve. It never appears on a row. At quarter close each EM records how much reserve was actually used so the ceiling can be recalibrated.
The tracker owner sets the holiday deduction on the Read me tab each quarter. It covers company-wide time off only; individual PTO goes in the Absences column on the Capacity tab. The guide the tracker uses is 0.5 weeks for the January to March and April to June quarters, 1.0 for July to September, and 2.0 for October to December, which absorbs Thanksgiving and Dec 21 to 31. In the October to December quarter, a team of four engineers with two engineer-weeks of planned leave has 4 × 11 − 2 = 42 engineer-weeks nominal and a committed ceiling of about 29. Its committed rows have to fit inside those 29 engineer-weeks. Aspirational rows use whatever frees up.
The Summary tab rolls this up for the org: committed ceiling, committed appetite planned, headroom, teams over their ceiling and teams missing an engineer count. Negative headroom means the org has promised more than it can deliver at the ceiling, and every team over its ceiling re-ranks before plan lock.
Checks the tracker enforces
The Checks column on the Priorities tab applies these rules. They are mechanical checks rather than judgment calls, and a row that fails one does not lock.
- Ranks within a team run 1 to n with no duplicates.
- Every row has an outcome, a metric, a baseline and a target.
- Every row has one owner, by name, and links to an org bet or says
None. - Committed rows fit inside the team’s ceiling.
- Every row has a stop signal and a check-by date. A passed check-by date flags the row until the EM decides.
- Every dependency names a row ID that exists in the plan, or an
EXT:team, and is accepted by name. - Committed rows link to an epic.
- Confidence matches tier: committed is 80% or 90%, aspirational is 50%.
- Rows not updated inside the stale window (14 days) are flagged, and stale rows are discussed before green ones.
- A dependency carries at least the org priority of the highest-priority row that depends on it. See Prioritizing across teams.
The example rows on the Priorities tab include one that intentionally fails two of these so you can see what the column does.
Anti-patterns we design against
Each rule on this page exists because one of these has already happened somewhere. If you see one, name it in the review.
| Anti-pattern | What it looks like | The rule that blocks it |
|---|---|---|
| The write-once plan | Rows filled in at plan lock and never opened again | The stale check flags any row not updated in 14 days, and stale rows are discussed before green ones |
| Watermelon status | Green on the outside, red inside; the slip appears in week 12 | Stop signals and check-by dates written up front; amber without a dated plan is red |
| Everything committed | Twelve committed rows for a team of four | The 70% ceiling, three to five rows per team, and the Capacity tab’s check |
| 100% allocation | No reserve, so the first incident eats the first committed row | The 30% reserve is a hard input and reserve used is recorded at close |
| Output metrics | “Ship X by date” with no way to know whether it worked | The outcome, metric, baseline and target check |
| Dependency hopes | “Team Y will have it ready” with nobody on Team Y having said so | Dependencies must name a row or an EXT: team and be accepted by name |
| Meetings as tracking | Twelve people watch one person read a spreadsheet | A 20-minute agenda the Summary tab generates, and the cancel rule |
| Zombie rows | A row nobody believes in, kept alive to avoid admitting it | Deprioritizing is a first-class outcome with three written lines |
| Silent slips | A committed row quietly moves to next quarter | Nothing moves without a dated Change log line; committed swaps need the tracker owner |
| Sandbagging | 100% say/do with aspirational rows untouched | The score treats it as a planning miss rather than a delivery win |
Frequently asked questions
“Isn’t this another process on top of the interlock?” No. The interlock covers the few large cross-functional items and stops at commitment. This page covers what happens below and after: how a team picks and sizes its own rows, how dependencies get settled, and how committed work is run and closed. Where the interlock has a rule, we use it as written.
“My team has four engineers. How many rows?” Three to five, ranked, with committed rows inside the ceiling. The interlock’s resource allocation framework caps commitments at the org level: at most one P1 or E1 and two P2 or E2 per 20 engineers, unless a VP approves an exception. Shared across the org’s teams, that usually leaves a four-person team with at most one committed cross-team row at a time. That is a consequence of the cap rather than a separate rule, and it is intentional.
“I can’t get to 80% confidence on something leadership wants committed.” Say so on the row, in the Change log. The row becomes aspirational, or the appetite grows, or the scope shrinks until you can. Committing at 50% and calling it 80% undermines everything downstream, because every other number on the tracker assumes that one is honest.
“Something urgent came in mid-quarter.” If it fits in the reserve, do it and log one line. If it needs committed capacity, propose the swap under the swap rules and flag it for discussion at the next review, or schedule an ad hoc thread or sync to fund it by prioritizing across the org, scope, cost and time.
“Why a spreadsheet and not GitLab?” Because the checks it enforces (ranks, ceilings, dependency acceptance, stale flags, say/do) are formulas today, and the work itself already lives in GitLab epics. When GitLab work items can enforce the same checks, the tracker moves there and this page changes.
“What does an engineer actually have to do?” Help write the row you own (under an hour, once a quarter), keep your epic current, and say early when a stop signal fires. Everything else on this page is for managers.
Related pages
Quarterly planning, R&D Interlock, and Pre-mortems for launches.
b52f57ed)
