Staff engineer 30/60/90 day plan: map the decisions, then move one

Learn, contribute, lead assumes the job is your output, just more of it. Before the Room uses one lens for levels, and it is about the scope of a move: a senior engineer solves the problem, a staff engineer changes the decision around the problem, and a principal engineer changes the system that keeps producing that decision. A plan whose milestones are things you built is a senior plan with a staff title.

Quick wins have a second cost that is easy to miss when you are new. The book treats credibility as a currency: it buys the right to be heard on a decision, and each use changes what the next one buys. Correct a naming convention, a test strategy and a log format in your first sprint, right each time, and your objection to a data boundary that will cost a year sounds like one more correction. From the debrief side:

In the debriefs I have sat in, the engineer who describes picking one hill a quarter has tended to read as more senior than the one who describes flagging everything he disagrees with.

A ninety-day plan is a quarter. Plan for one hill, and spend the first month finding the right one. The book's name for the position you start in is the authority gap, "the distance between what you are accountable for and what you are allowed to command."

Copy this into your own document and replace the middle column with your names, teams and dates. Each row ends in something you can show, not something you attended. Weeks 4 and 8 carry the weight: everything before week 4 makes the choice good, and everything after week 8 makes the decision stay made.

Find the decisions under the requests. Before the Room's first Surface tool is a worksheet whose core is four lines, filled in before you answer: the request in its exact words, the decision it is scaffolding phrased as a choice, the owner named as a person or a role (never "the team"), and the incentive that will settle it. When the owner is not you, ask the question the book calls one of the most useful in technical leadership: "Whose call is that?"

The staff version is noticing a pattern no single request shows, and the book's example is a mobile one. In one week, the mobile lead asks whether a new endpoint can tolerate older app versions, support asks whether the old order screen can stay another quarter, and the product manager asks whether widget work can start before the backend is final. Read together, they scaffold one decision nobody has made: whether the organization maintains two versions of the order flow for the next six months, and who pays for it. Write the requests side by side, name the decision they share, and find the one person who can own it.

Map power before you form an opinion. For the two or three cross-team changes people keep mentioning, answer the book's six questions: who can say yes, who can make yes expensive, who pays the adoption cost first, who benefits later, who owns the failure, and who loses the story their team tells about itself. Engineers tend to skip the last one, and it is often the one underneath a stalled proposal. Being new helps here, in my view: nobody expects you to have a position yet, so people tell you their costs.

Find who can reopen. Put the decision that keeps coming back on a decision-rights map: proposes, decides, pays, executes, can reopen. The reopen row is the one people leave blank. If you cannot put a real name in the decides and reopen rows of the decision everyone calls settled, it is less closed than it feels.

Protect a synthesis block from week one. The weekly operating system chapter treats synthesis, noticing that the same dependency showed up in three plans, as the actual work of a technical leader. It is never urgent, so it rarely happens by accident: "If your synthesis block does not survive contact with Tuesday, the organization is spending your judgment as support."

Choose one outcome by day 30. The repair chapter narrows a choice with five questions, and they make good exit criteria for your first month:

• What is the smallest outcome that would matter here?
• Which single decision blocks it?
• Who can make that decision?
• What one-page artifact would make the trade-off visible to them?
• What would count as movement in a week?

Then write down what you are not taking on. The book names the failure it sees most often in a repair plan, and it is the one I would expect from a conscientious new staff engineer: "refusing to choose, and mapping everything instead, which is avoidance with good vocabulary."

The second month runs the book's thirty-day repair on the outcome you chose, rows 5 to 8 of the table: diagnosis, validation, a decision moment and follow-up, each producing evidence. Its premise: "Do not repair your leadership. Repair one situation, in thirty days."

In week 5 the incentive comes before the artifact on purpose: an artifact that solves the visible problem while missing the reason it stayed stuck is wasted paper. Week 6 is the one people skip when they are new and want to look decisive, and skipping it means walking into week 7 with a map only you believe. In week 7, see the owner and anyone whose late objection would change the decision one at a time, before any group meeting, and ask the book's pre-alignment question: "What fact, risk, or constraint would make this unsafe to approve?" Then ask for a specific decision: a yes, a risk accepted, an owner assigned, or an explicit deferral.

The threshold is set in week 5, said to the owner then, and fires at the end of week 7 if no decision has been made, aimed at whoever owns both sides of the gap, often the director over both teams. The book is precise about what travels: "You do not escalate the plan. You escalate the one unresolved decision the plan surfaced." How to write it so it does not read as going over someone's head is in how to escalate as a tech lead, and it applies unchanged at staff level.

The book's worked repair is a mobile one, and a composite. Release builds keep failing on a pipeline another team owns. The hidden decision is whether the platform team treats the mobile build path as a supported product, and the incentive keeping it stuck is that the platform team is measured on backend deploy reliability, where mobile build failures do not show up. The artifact is an outcome evidence table of a month of release builds with a two-option ask. Validation moves some failures back to the mobile team's own signing configuration. The decision is an owner with a same-day response in release weeks, and the follow-up shows the next failure picked up the same day, with one slip in the second release week.

The book's last row says to continue, not close, and that is the honest shape of a day 60: one movement you can observe and one slip on the record. A clear no is also a result: record it, and decide in the open whether to plan around it or take it higher.

Start the evidence while the repair is running. Add a ledger entry when the decision closes, with the scope and the proof you cannot show yet, and walk your manager through it in the second month, while there is still time to change the work if they read it as senior scope. The fields, and why the missing-proof line matters most, are in staff engineer promotion packet evidence.

Check that it held. The book's follow-up signal has two checkpoints: after a week, did the owning team change what it tracks; after a month, did the new behavior become the default, or did the system drift back? Your repair hits its one-month check in this window. Then do what the repair chapter names as the staff version: leave the owner, the trade-off and the reopen criteria recorded, so the gap does not return unnoticed.

Publish how decisions reach you. By week 9 you know where decisions here actually close, which is rarely quite where the org chart says, so the weekly operating system starts to fit. The book's practical start is one published paragraph, something like: local implementation choices stay with the team; cross-team, irreversible and reliability decisions come through written intake; there are two review windows a week; urgent escalation is for production risk, security, a customer commitment or a blocked cross-team dependency. And the rule that makes it more than a gate: "if someone can own a decision with context and a review point, I will not take it back."

Transfer one class of decisions, not ten. Pick one recurring kind of decision that keeps landing on you, such as local library adoption, and write it down as a decision-rights transfer: the class, the future owner, the guardrails and one review point. The book's pace is roughly one class a month. Review the first two decisions at the checkpoint, not in the thread, and let a call inside the guardrails stand even when you would have made it differently. Re-review every call and you have kept the veto and handed over only the typing.

From the hiring side, this is the line in the chapter I would underline for anyone ninety days into a bigger role:

In the debriefs and calibrations I have sat in, the tech lead who read as ready for more scope was usually the one whose team kept moving while they were on vacation.

The book says plainly that this is one view, and not every organization reads it that way. It is still a useful test for day 90: if you took week 13 off, which of the decisions you touched would stall?

Choose the second repair. The repair chapter observes that the second one usually goes better, because by then you know which artifact fits your environment, which stakeholders move things and where decisions actually close. That is most of what a first quarter in a staff role is for, learned from one real decision rather than a listening tour. What staff scope looks like across platforms is in staff engineers change the decisions a team can make; this plan is one way to have a first example of it by day 90.

The book draws the boundary of the repair itself: thirty days can produce one observable movement, not a transformed organization, and treating one repair as a cure sets you up to be blamed for what the system will not move. The repair template also says when not to run it: when the problem is structural and sits above you, when raising it would put you at real risk, during a live incident, or for more than one gap at a time.

If your first month shows that the stuck decision belongs above you, days 31 to 60 end with bringing it to the right owner and stopping there. And if the organization punishes honest evidence, no plan in this post applies; the book's advice is to protect yourself first: document, seek formal support, and weigh moving teams or leaving.

What should a staff engineer 30 60 90 day plan include?

Decisions, not activities. Days 1 to 30: map the unstated decisions, the power around them and who can reopen them, then choose one stuck outcome. Days 31 to 60: run a four-week repair on it that ends in a specific decision from its owner. Days 61 to 90: check that the decision held, record what keeps it closed, and publish how decisions reach you.

What should a new staff engineer do in the first 30 days?

Map before you move: a four-line hidden-decision worksheet on heavy requests, a power map for the cross-team changes people keep mentioning, and real names in the decides and reopen rows of the decision that keeps coming back. By day 30, choose one stuck outcome and write down what you are not taking on.

Should a new staff engineer go for quick wins?

Not as the plan. A quick win is usually senior-scope work, and a run of small corrections spends credibility you will need for the one decision that matters. Fix what is cheap and obvious, but do not count it as the ninety days.

My manager already gave me a 30/60/90 plan. Do I replace it?

No. Keep your manager's headings and put one stuck outcome inside them. Walk your manager through your map at day 30 and your first evidence entry in the second month, so any disagreement about scope surfaces while there is time to change the work.