Finding the problem worth your team's year

Sit down to plan your team's next year and the candidates are already waiting: the migration a director keeps asking about, the reliability push that follows last month's incident, the feature the biggest customer named on a renewal call, the framework upgrade now two majors behind. The standard tool for this moment is a prioritization framework: RICE, the most common one, has you score each candidate on reach (how many people it touches), impact (how much it changes for them), confidence, and effort, then rank the list by the resulting number. The older urgent-important matrix sorts the same list into four quadrants instead. Both are honest tools, and I use them.

But a framework can only rank what is already on the list, and a problem gets onto a planning list in one way: by being urgent to a specific person with the standing to file it. The problem worth your team's year, the one whose solution compounds by making every following quarter cheaper, rarely has that sponsor. It sits in the seams between teams, costs everyone a little and no one enough to make it their problem, and so it never gets filed, which means a team that only sorts what arrives can run a perfectly efficient year without getting any cheaper to run.

So the work starts earlier than the ranking: hunt down the problem that will not announce itself, then protect it long enough to collect the payoff. I reach for seven moves, in this order.

Hunt where nothing gets filed

The compounding problem does not file itself, but it does leave tracks. The one I trust most is repetition across unrelated rooms: the same friction named in a team retro, then in a support escalation review, then in a conversation with your director, by people who do not talk to each other. One loud stakeholder repeating themselves counts as one room, no matter how many times you hear it. Keep a running note of every friction you hear named more than twice, and treat that note, rather than the ticket queue, as your candidate list for the year.

The second track is workarounds, the fixes teams build instead of filing tickets. Picture a release process nobody owns: the Android engineers keep a hand-maintained checklist, the backend engineers run a script one of them wrote on a weekend, and the web team simply releases less often than it wants to. Nobody files a ticket, because filing one means an argument about whose backlog it lands in, and every one of those teams has already found routing around the pain cheaper than having that argument. The problem three teams have independently half-solved is the one worth solving once, properly.

Test for compounding

Once you have candidates, resist the instinct to pick the biggest one, because size is not the test: a huge migration that pays out once is still just a project, while a small-looking capability that every future feature draws on can carry the year. The test I use is a single sentence: once we solve X, Y gets cheaper every quarter because Z. If you cannot fill in the Z, the mechanism, the candidate is not ready, however large or popular it is.

Put two teams from the same company side by side: one spends a quarter on deploy tooling, and every feature after that lands a little faster. The other ships the flagship feature, and the launch goes well, but the team comes back to the same pace it always had. Both quarters look productive in review, because a review can see a launch far more easily than it can see the next four quarters getting cheaper.

Write the problem page before the solution

Before committing to anything, write one page about the problem, with solutions banned from it. The page answers four questions:

• Who hurts?
• What does it cost each quarter?
• Why now?
• What compounds once it is solved?

If you cannot write that page, the problem is not ready to take a year of anyone's time. Will Larson's writing on engineering strategy begins the same way, with diagnosis, an honest description of the situation before any prescription. He pitches that discipline at the scale of a whole organization, but it works one level down for a single team, and it is cheaper there.

Watch for solutions smuggled in as diagnosis: a page that says the problem is that we lack a platform has already chosen its answer and dressed it up as a finding. The page earns its keep when a skeptical peer can read it and propose a different solution than the one in your head.

Price the urgent work

You will need an argument for why the urgent list should not win again, and the best argument is arithmetic. In 2018 the Journal of Consumer Research published what its authors called the mere urgency effect: given the choice, people reliably pick the task with a deadline over the task with a larger payoff, even when they can see both payoffs clearly. Planning rooms are not exempt from that pull, so total last quarter's urgent work, honestly (the honestly is the hard part), and ask what compounded from it.

Run that exercise on a team of eight and the numbers tend to land the same way: eleven or twelve engineer-weeks went to escalations and deadline rescues, and when you ask which of those weeks made any future week cheaper, the answer is close to none. That number, said out loud in planning, wins more protected capacity than any general argument about important work, partly because the room has heard the general argument every year and funded the urgent list anyway.

Some urgent work is simply the cost of running a business, and pretending otherwise discredits the whole argument. You are asking for urgent work to take a smaller share of the team's weeks, rather than promising it will take none.

Give it a lane

A year-long problem also invites a fair objection: a team that bets everything on a single horse for a year is fragile, because it responds slowly to change and ends up defending the bet just because of what the bet has already cost. Follow that objection to its usual conclusion, a plan of many small bets and nothing else, and the compounding problem disappears entirely, because it does not fit inside a small bet. Both sides of that argument can be true at once: give the year problem a protected lane, between a quarter and a third of the team's capacity, and keep the rest of the team's portfolio short-cycle, shipping and adapting the whole time, so the bet holds for a year while the team around it still turns every quarter.

The lane rarely falls to a head-on attack. Urgent work nibbles at it instead, one borrowed engineer at a time, each loan reasonable on its own, until the year problem has become a slide in a deck rather than a live workstream. Defending the lane is less a planning problem than a saying no problem, and most year problems that fail go this way, eroded rather than killed by any decision anyone remembers making.

Test the fashionable answer too

Every planning season has a fashionable answer in the air, and this year it is the AI-era development lifecycle: rebuilding how a team specifies, generates, reviews, and ships software around coding agents. Treat it as a legitimate candidate, and make it pass the same sentence as every other candidate: once we solve X, Y gets cheaper every quarter because Z. For some teams it passes easily, because slow code review or thin test coverage genuinely is the bottleneck on everything else. For others it is borrowed compounding, someone else's mechanism adopted because it is everywhere, with no line you can draw to your own team's costs. The sentence does not care which of these you are, and the temptation runs in both directions: adopting the fashionable answer because everyone else has, or dismissing it out of hand for exactly the same reason.

Commit with an exit design

A commitment made once in January and not examined again until December is how a team ends up defending a bet nobody still believes in. Commit with the exit designed in: on the day you commit, write down the observable signals that would mean the bet is not working (the kill criteria), and put a re-decision date on the calendar every quarter, so the problem keeps its year while the conviction behind it gets re-earned every ninety days, in front of the team.

And know when not to run this play at all: a team that is on fire, or too understaffed to hold any lane for even a quarter, does not need a year problem yet. It needs stabilizing first, and the hunt loses nothing in the waiting, since the urgent list is in no danger of drying up in the meantime.