Choosing Which Problems to Work On

Suppose you are the Staff engineer from the first lesson, and the scheduler project is nearing its end and needs less of your time. Four problems are waiting, and you can take on one of them as your main project. Which one would you choose?

• A. Builds in the shared continuous integration system take 38 minutes, and every engineer complains about them.
• B. The search team's ranking service has become slow, and its p99 response time has reached 900 ms.
• C. Every partner integration takes weeks longer than planned, because the company's 180 services expose APIs in inconsistent ways.
• D. The internal admin tool is built on an old framework, and rewriting it in a modern one would be interesting and visible work.

Most engineers choose the problem that interests them most, or the one that the most people complain about. Neither is a reliable method. This lesson describes where Staff problems come from, four questions that compare candidates with numbers, and the traps that lead experienced engineers to the wrong choice.

Where Staff Problems Come From

A Staff problem is rarely assigned; it is usually found in places where the cost of a problem is visible but spread out. The scheduler problem was found by reading six incident reports together. Other places produce candidates in the same way:

• Incident reports and on-call load across teams. One incident is a team's problem, but the same cause in six teams is a Staff problem.
• Questions that keep repeating. The same question asked every week in shared channels points to a missing tool, document, or rule.
• Planning documents. When many teams list the same dependency or the same blocker, nobody may own it.
• What leadership worries about. Will Larson writes that "the first place to look for work that matters is exploring whether your company is experiencing an existential risk," meaning a risk to the company's survival.
• Delays that partners or customers notice. Problem C was found this way, through complaints from the partnerships team.

A Staff engineer keeps a short list of candidates found in these places, with rough numbers for each, rather than waiting until a project ends to look.

Four Questions for Every Candidate

Four questions compare candidate problems: how large the cost is, who already owns it, why now, and why you.

• How large is the cost, in numbers? State it in engineer-days per quarter, revenue, or risk. A problem that cannot be stated in numbers cannot be compared with another one.
• Who already owns it? If a team owns the problem and is working on it, the best contribution is usually to help that team, not to take the problem over. Larson calls small, timely contributions of this kind editing: "making those small changes, quick modifications, and short conversations."
• Why now? Some problems grow if they wait, and others will be the same size next year. A deadline, a growing cost, or a short opportunity raises a problem's priority.
• Why you? Larson's last category of important work is "the sort that you're uniquely capable of accomplishing." A problem where your knowledge, history, or relationships make the difference is worth more from you than from someone else. Larson adds a warning that applies to every choice: "We only get value from finishing projects."

Comparing the Four Candidates

Here are the four problems from the opening with rough numbers, as the Staff engineer might estimate them:

Problem A has the largest cost, but it already has an owner with a plan and the expertise to carry it out. Taking it over would slow that team down. The right contribution is editing: reviewing the developer tools team's plan and spending an hour a week answering their questions.

Problem B is real and urgent, but it sits within one team's systems, and that team owns it. It is Senior-scope work for the search team, and a Staff engineer who takes it over removes a growth opportunity from the team's own engineers.

Problem C costs about 60 engineer-days a quarter and will cost about 120 within a year. The API Architect writes the guidelines and reviews each new public API, but the existing services belong to many different teams, and nobody owns the work of bringing them into line. Nobody else holds both the API knowledge and the relationships with the teams. It is the clear choice.

Problem D is the most attractive and the least valuable, which leads directly to the traps.

Notice that only one of the four sits in the quadrant of high cost and no owner, and that the high-cost problem with an owner receives help rather than a takeover.

The Traps

Larson names several ways in which experienced engineers choose the wrong work. Two are especially common at Staff level.

Snacking is choosing work that is easy and has little impact. Larson takes the term from the investor Hunter Walk, and describes it as the choice that remains once the easy, high-impact work runs out: "easy and low-impact." Snacking feels productive, because each task finishes quickly, but the total effect is small.

Preening is choosing work for how it looks rather than for what it changes. In Larson's words, "Preening is doing low-impact, high-visibility work." Problem D is a typical example: a rewrite that many people would see and praise, against a current cost of 2 engineer-days a quarter.

A third trap affects engineers who join a new company. Larson describes engineers who carry habits from a previous employer and "misjudge the familiar as the essential." An engineer who arrives from a company that ran its own data centers may see that problem everywhere, even where it costs very little.