I recently read (and quite enjoyed) Tanya Reilly’s The Staff Engineer’s Path, which—despite the title—is a book that applies pretty well to any experienced IC who works in building software. It focuses less on prescribing specific technical solutions (e.g. recommending a framework or library) and more on what it means to be a staff-level-or-higher IC, what your responsibilities are, and how you can navigate that career path and continue to grow. It’s pretty well-respected and canonical in the world of tech books.

I read it because I would like to be a staff designer someday and the lack of longform writing by staff designers out there (and staff design resources in general) is a shame, so this seemed like the next best thing. Much of her advice is transferable, so I definitely got a lot out of it in that regard, and the more engineer-specific things were helpful for better understanding my SWE counterparts.

I only actually started taking notes from chapter 6 onwards, so these notes are far from comprehensive. I’ve italicized my own thoughts/interjections.

Chapter 6: Why Have We Stopped?

  • This chapter focuses on obstacles and what to do when you run into them
  • Balance your main project with small, high-leverage tasks
  • Escalating a problem isn’t complaining—it’s asking for help
    • It has been very hard but very important for me to learn this, especially as someone who has often not had access to senior designers or design management.
  • Tech migrations are awful
    • Make it easy for teams doing it, put more work on the team owning the migration
    • Tech migrations seem like an excellent example of the principle that the last 5-10% of the project is often disproportionately difficult to complete.
  • “Nobody wants to use software. They want to catch a Pokemon.” In other words, users only care about their task (catching Pokemon), not what the underlying code is like.
    • Clearly define when a project is done. It needs to actually be shipped to users, not just on QA.
    • An example of a clearly defined goal: “The user should be able to catch a Pokemon.”
    • I have to say that as a designer, this seems like one of the more blatantly stereotypical engineering traits (not understanding or communicating the practical value delivered to users).
  • When you’re launching new features, you need to market them and make them discoverable so users actually find out they exist and use them.
  • Balance developing new features with maintenance work

Chapter 7: You’re a Role Model Now (Sorry)

  • You’re now the adult in the room. If you notice a problem and think “someone should do something about this,” that someone is you.
  • You have lots of passive influence you may not even be aware of. People will look to you as a standard and model their behavior on yours.
  • Key traits of being a role model as a staff contributor: competent, knowledgeable, experienced
  • Hard skills should become second nature. “You want to get so good at your craft that your focus can be almost entirely on what other people are doing and you don’t have to worry about your own execution.”
  • Be self-aware. Know when you’re good at doing something and know when you don’t know much about it. There is no need for false modesty.
  • Have high quality standards, and other people will follow.
    • In general, I have found an important part of being successful is having higher standards for yourself than other people do for you. This is in part because it forces you to come up with your own idea of what you look like as a successful contributor, rather than simply blindly following others’ standards.
  • Be reliable, trustworthy, and finish what you start.
  • Glue work in staff contributors is recognized as leadership, but can be dismissed when done by juniors. Staff should do glue work so that juniors can spend time developing their skills.
    • This is really interesting to consider because a lot of what Reilly characterizes as “glue work” is a fundamental part of a designer’s job (e.g. talking to customers, articulating how to improve the product’s user experience, unblocking your teammates). The output of designers both heavily influences and is influenced by their teammates’ contributions, so that’s part of why, whereas it’s easy for developers to each work in their own silo (although…they shouldn’t, and the fact that “glue work” is so undervalued in the first place suggests some concerning things about developer culture and expectations).
  • Make codebases easy for others to use.
    • Faster deployment = faster outage recovery
    • Simplify complex code, make it easy for others to comprehend
      • This carries over to design as well (and it’s not just about having clear component libraries in Figma). Designs should be laid out in a way that’s easy for others to comprehend and understand the requirements.
  • Your success metric is whether others want to work with you
    • I like this perspective because it’s very collectivistic

Chapter 8: Good Influence at Scale

  • To teach people successfully, you need to set specific goals for what you want to accomplish with the teaching
  • Encourage students to actually do things (hands-on learning), not just listen to you
    • Have a specific artifact they produce/can look back at, e.g. a project, some piece of code, an app, etc.
    • If possible, let them lead and you can shadow them
    • Balance leading, pairing, and shadowing.
      • Really like this model of different modes of learning and the role the teacher and the student play
  • Set up learning path to onboard in a codebase
    • e.g. Send PR to add your name to team member list. This helps make sending PRs less scary for new people
  • Be a guardrail and check over work
    • If someone wants you to be a guardrail, be specific in ways you can help, e.g. offer to review documents or designs. Often, “Let me know how I can help” is quite vague as people might not know what to ask for or are unsure if it’s too much to ask for
  • Write down decisions. You don’t want people to feel like they have to follow documents to a T though (process for the sake of process). Some examples of documented decisions:
    • Style guides
    • Company’s standard, well-supported technologies
    • Technical vision and strategies
  • Automate work when possible, e.g. code linters, auto reminders, templates
    • This is a tangent, but one of the disappointing things about genAI is the focus on replacing people’s work wholesale instead of making it easier for them to focus on doing important, more critical thinking-heavy work (as automations like a template does).
  • Messy projects are learning opportunities you can give people. Even if you know you’d do a project well, it may be better to give it to more junior people who would learn a lot from it
    • Anyone who gets an A+ isn’t learning. Give to people who can do it at a stretch with some support
    • I’m reminded of a friend who leads an extracurricular organization I’m in who once said an important part of leadership is being okay with letting other people do it worse than you would.
  • You need to give away your current (smaller) responsibilities in order to get bigger, better ones and grow yourself
  • It can feel great to be the most knowledgeable person in a room, but you’re preventing your team from growing if you don’t give them opportunities to do it “good enough but worse than you”

Chapter 9: What’s Next?

  • This chapter focuses on leveling up your career
  • Figure out your priorities. Examples:
    • Financial security
    • Learning
    • Prestige
    • Cool, exciting work
    • Supporting your family
    • Flexible schedule (can consider taking a paycut in exchange for working less hours)
    • Challenging yourself
    • Working for yourself
    • Building wealth
    • Making a difference
    • Enabling you to do your real passion, e.g. music, art
  • Devote energy to the things you want to be good at
  • Work sustainably - do work that makes you happy, not work that drains you
  • Evaluating your current job
    • Are you learning?
    • Learning transferable skills vs. navigating the dysfunction of your specific org
    • How you feel about recruiting others to your team
    • Confidence you feel
    • Stress you feel
  • Good job = you grow toward your goals, high self-confidence and high abilities
  • Bad job = stagnation, bullies, lack of support, impossible deadlines
  • Best engineers switch between manager and IC every few years
  • Management isn’t a promotion, it’s a change in profession. The manager’s job is to improve at management, not technical skills.
  • Happiness is the intersection of doing what you love and what you’re good at
  • Consider designing your own role at your own company
  • Avoid “rebound jobs” - simply trying to get out of your own job’s particular misery
  • Don’t try to do your new job based solely on what worked at your previous one
  • Be ethical, know that your work can have huge impact (good or bad) on people
  • What seniors do sets industry culture. You play a part in setting norms and expectations