Getting Started
The first ninety days in a Staff role — whether you’ve been promoted or are new to the organization — are the highest-risk period. The expectations have changed, but the habits haven’t. This section gives you a concrete starting point, not a comprehensive plan. The goal is to help you build the right foundations early so the rest of this guide becomes actionable rather than aspirational.
Week One: Orient
Have an alignment conversation with your manager
This is the single most important thing you can do in your first week. Understand how your manager sees your role, what they consider the highest-leverage uses of your time, and where they see the biggest risks in your domain. Ask them directly: “What would make you confident that I’m operating at the Staff level three months from now?” Write down their answer. You’ll come back to it.
Identify your local staff group
Find out who your peers are, when the group meets, and what’s currently on their radar. Introduce yourself if you’re new. If you’ve been promoted from within, resist the temptation to skip this step because you already know everyone — the relationship is different now, and acknowledging that matters.
Read this guide end to end
Not to memorize it, but to internalize the shape of the role. Pay particular attention to The Identity Shift and Common Pitfalls.
Weeks Two Through Four: Map the Terrain
Identify the top architectural risks in your domain
You should be able to answer the question “What are the two or three biggest technical risks your area is carrying right now?” If you can’t, that’s your first finding — and your first project is building enough context to answer it. Talk to the engineers on your team, read the recent design docs, look at the incident history.
Attend Architecture Office Hours
If one is scheduled, go early, before you have a finished opinion about anything. Listen to what other teams are bringing. Start building your map of what’s happening across the broader engineering organization.
Start showing up in the places that matter
Design reviews, cross-functional working groups, architectural discussions in your domain. Don’t try to influence anything yet — just be present, listen, and build context. Your goal in the first month is to understand the landscape, not to reshape it.
Have a few one-on-ones with engineers on your team who aren’t your direct peers
Understand what they’re working on, what frustrates them, and what they wish were different. This builds the ground-level context that will make your judgment credible later.
Months Two and Three: Start Operating
Bring something to your local staff group
Not a polished proposal — a real problem you’re thinking about, a risk you’ve identified, or an architectural question you’re not sure how to approach. This models the behavior described in How We Operate and builds the peer relationships you’ll rely on.
Do a few high-quality reviews
Pick a design doc or a significant PR and give it the kind of review described in Core Responsibilities — specific, constructive, grounded in principles, and aimed at making the author better. This is the fastest way to establish credibility and to signal what “good” looks like.
Start connecting information
After a staff meeting or a leadership forum, translate what you heard back to your team. Don’t just relay the facts — contextualize them. “Here’s what was decided, here’s why, and here’s what I think it means for us.” This is one of the highest-value behaviors you can start building immediately.
Have a check-in with your manager
Revisit the alignment conversation from week one. Share what you’ve learned, where you’re investing your time, and where you’re uncertain. Ask for feedback. This is the beginning of the managing-up practice described in Staying Aligned.
What Not to Do
- Don’t try to change everything at once. The problems you’re seeing are real, but you don’t have the relationships, context, or credibility yet to drive large-scale change. Build the foundation first.
- Don’t disappear into code. It’s tempting to retreat into implementation work because it’s comfortable and legible. If your first three months look identical to your last three months as a Senior, something is off.
- Don’t skip the structures. Local staff groups, Architecture Office Hours, and the global meeting are not optional — they’re the operating system of the role. Show up before you feel ready.
- Don’t wait to be told what to work on. At this level, nobody is going to hand you a perfectly scoped problem. If you’re waiting for that, you’re already falling behind. Start building your own map of what matters, and then validate it with your manager and your peers.