Roadmap · Career
Staff engineer and engineering leadership
Opens with creditsFor senior engineers who already own designs and influence their team, and want the next step: staff engineer, engineering manager, or an honest trial of both. By the end you own architecture across teams, lead projects and incidents, influence the wider organisation, and have evidence for the path you choose.
Curated by Tauseef Fayyaz5 stages, 38 topics~8 months at a few hours a weekBy the end, you will be able to
- Own architecture decisions that span several teams, recorded so every team can find the reasoning
- Lead a multi-team project from scope to launch, and run an incident through to a blameless postmortem
- Write proposals and updates for directors and other teams that get decisions made
- Do the core work of your path for a quarter: strategy and sponsorship as staff, or one-on-ones, feedback and hiring as a manager
- Choose between the staff and manager paths with evidence from doing the work, knowing you can switch later
The path
5 stages, in the order to learn them. Open one to start.
1Owning architecture across teamsAt this level the hard design problems sit between teams: shared data, service boundaries, platform choices and build versus buy. Own those decisions, write down the trade-offs, and keep the system something the organisation can operate.7 topics · ~2 months
- 1Service and data ownership boundariesEvery service, database and shared API needs one owning team.
- 2Trade-off analysis across teamsA decision that affects several teams rarely has a right answer.
- 3Build versus buyBuild versus buy asks a simple question.
- 4Failure modes and blast radiusEvery design should say how it fails, not only how it works.
- 5SLOs and error budgetsA service level objective, or SLO, is a reliability target measured from the user's side.
- 6Decision records other teams can findAn architecture decision record, or ADR, is a short document about one decision.
- 7Technical debt as a portfolioTechnical debt is the ongoing cost of past shortcuts and ageing code.
7 in this stageOpen this stage2Leading projects and incidentsLead work that runs through other people and teams: scope it so it ships, track risks and dependencies, and run incidents and postmortems calmly.8 topics · ~6 weeks
- 1A one-page project briefBefore a project involving several teams starts, write a one-page project brief.
- 2Shaping and cutting scopeShaping means deciding how much a problem is worth before deciding the solution.
- 3Milestones and estimates as rangesBreak the project into milestones, and make each one something you can demo.
- 4Risks and cross-team dependenciesKeep a short, living list of risks and cross-team dependencies.
- 5Weekly status that surfaces troubleA weekly status update tells readers three things in under a minute.
- 6Incident command and rolesIn a serious incident, one person coordinates and does not debug.
- 7Mitigate first, then communicateDuring an incident, the first goal is to stop the harm, not to understand it.
- 8Blameless postmortemsA blameless postmortem explains how the system and process allowed an incident.
8 in this stageOpen this stage- Communication and influence across the organisationStaff engineers and managers both lead mostly through writing and relationships. Write for people outside engineering, align teams that do not report to you, and disagree without spending trust.7 topics · ~6 weeksOpens with credits
- Try staff-shaped workBefore choosing a path, spend a quarter doing staff-shaped work: own a problem that spans teams, do glue work in the open, and notice whether the work energises or drains you.8 topics · ~6 weeksOpens with credits
- Try the manager sideIn the same quarter, test the people side: one-on-ones, feedback, delegation and a hiring loop. Then compare notes from both trials, knowing that moving between the two paths later is normal.8 topics · ~2 monthsOpens with credits
3 more stages, 23 more topics, free with an account.
You have seen the open stages of the Staff and leadership roadmap. Every topic it covers is listed above, and an account opens the rest: what each topic means, a question to check yourself, the courses, the practice and Tauseef's advice for every stage. Early access is open: sign up and your account is active shortly after.
Everything here is free to learn from. A few things, like adding a roadmap, keeping a cheat sheet or asking Tauseef a question, use credits. You get 15 when you join, your first roadmap is free, and if you are learning seriously and run out, you can ask for more. Credits only make sure the platform goes to people who are actually learning.
Related on Sefism
Picked from the other libraries by shared topics.
Best practices
See all- Tech Lead Best PracticesTech lead best practices for engineers stepping up: define the role, set direction with design docs and ADRs, plan and unblock delivery, run healthy code review, grow people, handle incidents.
- Engineering Career Growth Best PracticesCareer growth best practices for engineers: read your ladder, grow scope and impact, own outcomes, work with your manager, use feedback, build promotion evidence, pick a staff or manager path.
Career questions
See all- How do I go from mid-level to senior software engineer?Senior is less about years and more about scope: you own ambiguous problems, make sound technical decisions others rely on, and make the people around you more effective. Pick work with real uncertainty, write down your decisions and trade-offs, invest in others, and make that impact visible to the people who decide promotions.
- How do I deal with a toxic manager or workplace as a developer?First separate a hard environment from a harmful one. Protect yourself by documenting incidents, setting clear boundaries in writing and raising issues through the right channel. Try one or two honest fixes, but if the pattern continues or affects your health, plan a calm exit rather than enduring it indefinitely.
- What should I do when I disagree with a senior engineer or tech lead?Disagree early, privately where possible, and with evidence rather than opinion. Make sure you understand their reasoning first, frame your concern around the shared goal, offer a concrete alternative, and accept the decision once it is made. Disagreeing well builds trust; silence or going around them does not.
Stuck on something specific?
Writing only gets you so far. If you want an answer to your situation rather than the general case, book a session and we will work through it together. Sessions are free for approved Sefism members, and a few slots open each week.
- 1:1 Mentorship
- Fresh Graduate Mentorship
- Career Guidance
Brand deals, promos and partnerships: tauseeffayyaz@gmail.com