Book notes: Staff Engineer, Leadership beyond the management track

Posted on In

This is an interesting and recommended book by Will Larson published in 2021 about Staff engineers roles.

Here are my notes:

Staff engineer archetypes

  • Tech lead:
    • Scope complex tasks.
    • Coordinating the team.
    • Unlocking the team.
    • Cross-functional relationships.
    • Closer to the team’s manager.
    • Coding less.
    • Delegating projects in the team.
    • Grow their teammates.
    • Guide the team’s approach and execution.
    • Define the team’s technical vision.
    • 1 Tech lead for every 8 engineers.
    • Typical meetings (On-Call, Team Standup, 1:1, Focus Bloc/ Coding, Interviews, Sprint Planning, Sprint Demos, Incient Retrospectives, Arch Reviews).
  • Architect:
    • Success of a specific technical domain (API design, stack, storage strategy, etc…).
    • They should not design in isolation and then tell others what to implement.
    • Influential architects maintain an intimate understanding of the business needs, users’ goals, and relevant technical constraints.
    • Advocate for effective approaches.
    • Have organizational authority, earned by demonstrating consistently good judgment.
    • Only present in companies with very complex core domains.
    • In some companies they are deep in the code base, in others they do not code.
    • Companies with more than 100 engineers.
    • Typical meetings (Org Standup, 1:1, Arch Reviews, Prep Proposal Arcs, Interviews, Acquisitions discussions, Incient Retrospectives, Urgent sync scalability).
  • Solver:
    • Trusted agent in the Org who solves complex problems.
    • Work on critical problems until they are solved.
    • More present in companies that think of individuals rather than teams.
    • Typical meetings (Team meeting, Scalability work, 1:1, Interviews, Incient Retrospectives, Urgent sync scalability).
  • Right hand:
    • Compared with the Got Hand of the King, operating with the authority of a senior leader.
    • Aligned with the leader’s approach, beliefs, and values.
    • Solve important (essential) problems at a high level.
    • Problems are never purely technical, they are the intersection of business, technology, people, culture, and process.
    • Drive into a fire, edit the approach, delegate to the appropriate team, and jump to the next fire in another part of the Org.
    • Companies with more than 1000 engineers.
    • Typical meetings (Org Status meeting, Scalability calls/status, 1:1, Interviews, Eng Budget Review, Quarter Planning Offsite, Team Meetings, Urgent sync scalability, Acquisitions discussions).

Time enough in a thirty or forty year career to experiment with every archetype.

1. What do Staff engineers do?

  • Working on projects/efforts that have strategic value for the company while driving technical design and up-leveling their team.
  • They keep doing much of what made them successful as Senior Engineers: building relationships, writing software, coordinating projects. => No.

These tasks were core work tasks, now they are auxiliary. The new core tasks are:

  • Setting and editing technical direction:

    • Pragmatic, deliberate, and focus on long-term trend of progress.
    • Prioritize understanding and solving the company’s real needs over technology approaches you are excited to learn about.
    • Organization first, you second.

  • Providing sponsorship and mentorship:

    • You can change the company’s long-term trajectory more by growing the engineers around you rather than through personal heroics.
    • Sharing your experience and advice, and building relationships is high-impact work.
    • Effective staff pair a moderate amount of mentorship with considerably more sponsorship.
      • Learn the opportunities you have to raise people’s names each week.
      • Find a person to sponsor.
      • Listen to their experiences, learn about their skills, and how they want to grow.
      • Raise your sponsee’s name in those opportunities.

  • Providing engineering perspective:

    • Injecting engineering context into organizational decisions.
    • Delivering valuable input that can change the outcome of companies’ routine decision-making.
    • Staff engineers unexpectedly are in a room where this sort of decision is happening. Ej: Review customer contracts, Interviewing process, Roadmap-planning.
    • You are representing the interests of all engineers, not only your owns.

  • Exploration:

    • A team that masters hill-climbing to do exploratory work is far from a sure thing.
    • Dedicate specific resources and exploratory work to staff engineers.
    • It’s not necessarily a business problem, some time is infrastructure, security, etc.
    • Great deal of organizational trust to be trusted, having enough respect from the business that if you fail, it’s the reflection on the problem and not you.

  • Being glue:

    • Doing the needed, but often invisible, tasks to keep the team moving forward and shipping its work.
    • Expediting the most important work and ensuring it gets finished, behind the scenes.

But Will you still write software?

  • Depends, probably more code reviews and experiments.

Slow but rewarding:

  • No fast feedback loop, time frames are longer. It is normal to feel like you haven’t accomplished anything.

Advantages:

  1. Allow you to bypass informal gauges of seniority.
    • You already demonstrated your performance in the core work, so now you do not need to prove yourself, this means more free time and energy.
    • It gives you respect and authority.
  2. Facilitating access to “the room” where high-level engineering discussions take place (technical and non-technical ).
  3. Increase in current and career compensation.
  4. More agency to select the project you work on, maybe more exciting work. (Depends on the company).

Different rather than better:

  • If you’re more focused on hitting Staff than on setting yourself up to do work that energizes you, it’s easy to end up stuck in a role you don’t want.
  • In your career, there are few choices without consequences, and this isn’t one of them.

2. Operating at Staff

Work on what matters:

  • Your work maintains an aloof indifference to your sacrifice rather than rewarding it.
  • To success in the task to do more in less time, you need to use a deliberate approach to look for high-impact work with low effort.
  • Avoid “snacking”, when prioritizing work. When high-impact and easy work ends there are two types of work: high-impact and hard effort and low-impact and easy. You probably can go for the easy for a while to keep motivated (Psychologically reward, “snack”), but you should always look for high-impact.
  • Do not “preening” low-impact with high-visibility work.
  • Stop chasing ghosts, from previous work. Understand the context first.

What should you work on?

  • Work on existential risks first.
  • Work where there’s room for attention, teaching a company to value something it does not care about it’s hard work and it often fails.
  • Create a legacy in the team by developing them, this will last more than your code.
  • Look for small, quick changes that increase project outcomes with little effort, like 1 single consensus, 1 single conversation, or 1 quick modification.
  • We only get value from finishing projects. Invest time into finishing a project, try to define finishable work, or help others to rescope projects into finishable work. Investing time into finishing a project is always time well spent.
  • Do things that matter that only will happen if you do them.
  • You can’t escape subjective interview practices, but you can deliberately accumulate expertise from doing valuable work. Indeed, that’s the only viable long-term bet on your career: focus on work that matters, do projects that develop you, and steer towards companies that value genuine expertise.

Write an engineering strategy:

  • Good engineering strategy is boring and effective strategy is easy to write.
  • Five design documents, remove similarities, that an engineering strategy.
  • Five engineering strategies, forecast implications in two years’ future, and that’s the engineering vision.
  • Durably useful engineering strategy and vision are the output of iterative, bottom-up organizational learning.
  • Strategies are tools for proactive alignment that empower teams to move quickly with confidence.
  • Same discussion three times, write a strategy.
  • When there are no clear investments that are worth making in the future, create another vision.
  • Designing docs or RFCs: describe decisions and tradeoffs in a project.
    • Use when capabilities will be used by numerous projects.
    • Use when high impact your users.
    • Use when work takes longer than a month.
    • Start to clarify the problem. The clearer the problem statement the more obvious the solution.
    • Keep the template simple.
    • Gather and review together, write alone. (Remember that they are collaborative documents, do not fall in love with your proposals)
    • Prefer good over perfect.
  • Engineering strategy:
    • Look at controversial decisions that came up in multiple designs.
    • Good strategies guide trade-offs and explain rationale, bad strategies remain policy without explanation.
    • Strategies are a Framework for Responsible Innovation
    • Big Technical Changes Happen at Slack
    • Advises for strategy document:
      • Start where you are
      • Write the specifics, write until you start to generalize. Wait until you write more design documents.
        • Specific statements create alignment.
        • Generic statements create the illusion of alignment.
      • Good strategies are opinionated.
      • Show your work, you provide the underlying context, but enable others to modify and extend your work.
  • Engineering vision:
    • Group strategies, extrapolate how the trade-off will play out over the next two or three years.
    • Grounded on serving business and users.
    • Be optimistic rather than audacious. Everything goes well and every project is finished on time, but do not assume infinite resources.
    • Illustrative rather than declarative. Stay concrete and specific.
    • Keep it one or two pages long.
    • Vision in for few people, the ones that are writing strategies, do not expect a load of excitement.
    • Good visions are obvious and boring.

Curate technical quality:

  • Well-intentioned proposals are good, but a well-structured plan is better. Most essential value, sooner.
  • Successfully companies raise the quality bar as they scale.
  • At a well-run and successful company, most of your previous technical decisions won’t meet your current quality threshold. Filling the gap is a routine.
  • Technical quality is a long-term game.
  • Approaches:
    • Fix host sports: (unless the company is creating more problems faster)
    • Use best practices: that are known
      • Good processes are evolved rather than maintained, use only 1 new practice at the same time.
      • Workflow to adopt a good practice:
        • Document the approach.
        • Experiment with a few engaged (and motivated) teams.
        • Sand down rough edges.
        • Improve the documentation.
        • And go back to the experiment.
      • For improving research: Accelerate
    • Use leverage points
      • Prevent gross quality failures and reduce the cost of future quality investments. For example:
        • Interfaces (Contracts between systems):
        • Stateful systems (The more requirements, the more challenging, failures, performance, security, compliance, consistency, etc…)
        • Data models:
          • Rigid: only exposes what supports and prevents invalid states.
          • Tolerant of evolution over time.
          • Effective: not necessarily very clever.
    • Align Technical vectors
      • Are the direction in which every technical decision points. Most of them should be aligned with the organization’s shared vision.
      • To align technical direction, you can route all this to Architect, but this is not scale. And every team with its own independent decisions it’s not a good idea.
      • Alignment tools:
        • Direct feedback: A quick conversation can prevent years of unnecessary processes.
        • Refine engineering strategy.
        • Encapsulate your approach in workflows and tooling: Deliberate tools create workflows that nurture habits better than documentation. EJ: Mandatory steps for deployments, templates for PRs.
        • Train new team members during onboarding, it’s easier than when they’ve formed.
        • Use Conway’s law, “Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization’s communication structure”.
        • Work on technology change, using architecture reviews
    • Measure technical quality: It’s important to be specific with the definition of quality that we want to achieve.
      • Percentage of statically typed code.
      • Number of files with tests.
      • Test coverage.
      • How narrow are the public interfaces across modules?
      • What percentage of files use the preferred HTTP library?
      • Do endpoints respond to requests within 500ms after a cold start?
      • How many functions have dangerous read-after-write behavior? Or perform unnecessary reads against the primary database instance?
      • How many endpoints perform all state mutations within a single transaction?
      • How many functions acquire low-granularity locks?
      • How many hot files exist that are changed in more than half of pull requests?
    • Spin up a technical quality team: developer productivity/ developer tools/product infrastructure. The team goal is to preserve quality across your company’s software. Small team form 3–6 and 1 from every 15 devs.
      • Trust metrics over intuition.
      • Keep your intuition fresh, and keep in touch with product developers.
      • Listen to, and learn from, your users.
      • Do fewer things, but do them better: transversal tools impact everything.
      • Don’t hoard impact, decentralized approach, balance the benefits of exploration against the benefits of standardization.
    • Run a quality program: Boost the org quality with a quality sponsor, ej quality consultancy.

Stay aligned with authority:

  • Act as a proxy: What would X (Your direct manager) do here? This demonstrates a shared and aligned vision with your Manager and with the organizational authority.
  • The company is not designed to set you up for success, The safety net ends normally in a Senior role, in a Staff role, you are the safety net.
  • Don’t surprise your manager.

To lead, you have to follow:

  • Has a vision of how things should be.
  • Know how things work.
  • Take actions to change them, this creates early success.
  • Effective leadership: More time following than doing leading.
    • Follow how much you disagree. Let’s other lead if you only disagree in a minor way.
    • Follow other leaders that you can trust.
    • Make feedback comments explicitly optional to not block.

Learn to never be wrong:

  • Don’t spend social capital repairing relationships with conflicts, learn to collaborate with folks with different priorities and perspectives.

  • Have a deep perspective on technology and architecture.

  • Remain skeptical of yourself, keep pragmatic and agnostic to technical religion.

  • Do not go to a meeting thinking you have the reason and trying to convince everyone. To be effective, go with the goal of agreeing on the problem, and understanding the needs and the perspectives in the room. Identify what needs to happen to align on an approach.

  • Key points for meetings:

    • Listening through questions: Ask three good questions before sharing your perspective.
    • Good questions are asked with the desire to learn, and they are specific.
    • Define the purpose of the meeting. But don’t do it twice, meetings with multiple failed reframings almost always end with scheduling another meeting.
    • Read the room. Maybe there are frustrated folks, or too far apart, maybe escalating the problem outside the room could be an option.

  • Key points for “difficult folks”:

    • Invest time to be aligned before the meeting.
    • Introduce someone they can’t be a jerk to in the meeting like the manager or the CTO.

  • Your career depends more on being easy to involve than being technically correct.

Create space for others:

  • In previous roles you were the go-to person, in staff roles you should deliberately create space for them.
  • Good discussion: the one that turns out you didn’t need to attend.
  • You made a key contribution, think about what needs to happen for someone else to make it next time.
  • In meetings:
    • Contribute by asking powerful questions.
    • Pull people not participating.
    • Be the one to take notes (more time for others to speak).
    • Be the person to pull the missing key person into the next meeting.
  • How to shift complex and important desitions to the team:
    • Write it down, folks can learn from our decisions rather than being directed by them.
    • Circulate early, incorporate feedback, and involve folks in the decision-making from the beginning. They can see the thinking process and then the final output.
    • Separate style from substance. Do not give feedback on other folks’ decisions. Do not give feedback that won’t meaningfully change a project’s success. If it’s valuable feedback, consider giving it in private.
    • Don’t try to show value. Do not push insecurity over impact, you do not need to be everywhere in the team and not all your decisions should be the same as others. Let others grow as leaders too.
    • Change your mind: Listen to your coworkers, and then change your mind, this is a sign of respect.
  • Sponsorship:
    • When critical work comes to you, think: Who could be both successful with and grow by this work?
    • When the work becomes theirs, you have to let it be theirs.
    • You should sponsor a few times a month.
  • What if you don’t?
    • The only way to remain a long-term leader of a genuinely successful company is to continually create space for others to take the recognition, reward, and work that got you to where you’re currently sitting.

Build a network of peers:

  • It’s those conversations about career challenges and growth that have gotten me to where I am in my career.
  • Keep in touch regularly with previous managers/colleagues.
  • Build your internal network too.
  • Be visible: Blogging/public speaking.
  • Ambient networks: follow interesting people.
  • Prioritize quality over quantity.

Present to executives:

  • Know your audience. If you need to attach an appendix with datasets or not use an academic report too boring, etc.
  • Most important: Why you’re communicating with them? Planning, status report or resolve misalignment.
  • Your goal should be to extract as much perspective from the executive as possible, not to change their mind.
  • Controll the sequence in which you present your ideas: The clearest sequence to present your ideas is always to give the summarizing idea before you give the individual ideas being summarized. The Pyramid Principle
  • SCQA for documents:
    • Situation, relevant context.
    • Complication, why the situation is problematic?
    • Question, what is the core question to address?
    • Answer, what is the best answer to that question?
  • Mistakes to avoid:
    • Never fight feedback.
    • Don’t evade responsibility or problems.
    • Don’t present a question without an answer.
    • Avoid academic-style presentations, The Minto Pyramid principle.
    • Don’t fixate on your preferred outcome.
  • Share drafts with executives attending the meeting asking for feedback.

3. Getting the title where you are

  • Opportunities are not evenly distributed across the company:
    • Infrastructure is different from product.
    • Fixing vs preventing.
    • Work more visible in headquarters than in a distributed office.
  • Give management a try if you have doubts.
  • Promotion packages:
    • Write them before, and then translate them into that format. It becomes a map to accomplish your goal.
    • Template:
      1. What are your staff projects?
        • Goal, complexity, what you did, and project’s impact. Keep it short and link design documents.
      2. High-leverage ways you have improved in the company.
        . Quantificable impact of your projetcs. Cost reductions ($), and the number of tickets reduced (20%).
      3. Mentored people and accomplishments.
      4. Evidence glue work and the impact.
      5. Which teams/leaders are familiar with and advocate for your work?
      6. Do you have any skill/behavior gap? How would you address the concerns?
    • Iterate:
      1. Answer why you’re doing this.
      2. Temper your expectations, it takes time.
      3. Bring your manager into the fold. Communicate your goals, and ask for feedback and guidance. Be honest, don’t tell them what they want to hear.
      4. Write the promotion packet.
      5. Wait two days and then edit the promotion packet.
      6. Edit the promotion packet with trusted peers.
      7. Edit the promotion packet with your manager.
      8. Periodically review the promotion packet with your manager.
  • Find a sponsor.
  • Staff projects are usually not required, but worth pursuing for personal growth and ease the promotion. Basically is a huge project where you can demonstrate that you are able to navigate that ambiguity and deliver successfully in an effective way.
    • Complex and ambigous.
    • Numerous and divided stakeholders.
    • Named bet where failure matters.
  • Get into the room:
    • Bring something useful to the room: Critical details for a project, expertise, similar experience, and relations with relevant customers.
    • That the room doesn’t already have: Bring something distinct.
    • A sponsor in the room.
    • Your sponsor needs to know you want to be there.
    • Decrease the cost of including you:
      • Stay aligned with your manager.
      • Optimize for the group.
      • Speak clearly and concisely. Develop an economy of speech.
      • Be a low-friction person.
      • Come prepared.
      • Focus and be present.
      • Volunteer for low-status tasks.
    • To avoid.
      • Misunderstanding the room’s purpose.
      • Being dogmatic.
      • Withholding consent.
      • Sucking the oxygen out of the room.
      • Embarrassing your sponsor.
      • Being flakey or not showing up regularly.
  • Being visible:
    • Be known for good things.
    • People know your name.
    • Internal visibility:
      • Write and distribute more long-lived documents.
      • Lead and participate in company forums like architecture reviews, code reviews, and learning circles.
      • Be a cheerleader for your team’s and peer’s work on Slack, email, etc.
      • Share weekly notes of your work with your team and stakeholders.
      • Contribute to your company’s blog.
      • Attend, or potentially event hosts, office hours for your team or org.
      • Avoid overburned activities with volume.
      • Find the activities that leverage your strengths.
    • Executive visibility:
      • Build relationships with your manager’s manager and that layer.
    • External visibility: This is optional and depends.
      • Create a mailing list.
      • Write books.
      • Be a conference speaker.
    • Salary Negotiation.