I readStaff EngineerbyWill LarsononAug 19th, 2023

★★★★☆

I had a physical copy of this book on my night stand so I could check out steal wisdom from other staff engineers. This tl;dr may embody a lot of my personal experience.

The Archetypes

The staff engineer is an individual contributor, aka IC, in the leadership. This book introduces four archetypes of staff engineers:

  • Tech Lead, essentially an engineer manager without human factor. They’re generally not accountable for hiring or performance review, but may provide valuable feedbacks in the calibration.
  • Architect, focuses more on the cross-team collaboration and alignment. Either they shepherd the technical leadership of a relative large business unit, or their work has profound impact on other teams and/or business units.
  • Solver, allows the individual contributor to continue deepen the domain expertise on specific fields to tackle hard engineer problems.
  • Right hand, a natural extension of the architect type. They provide the tech leadership as a service for the senior leadership.

I find the TL role might be most common role for the staff engineer. It leverages her domain expertise for technical stewardship without middle-layer management overhead. I also played the Solver role in Epic Games to focus on specific hard engineering problems.

What do do stuff engineer actually do?

  • Setting technical directions
  • Providing engineer perspective
  • Mentorship
  • Exploration
  • Being glue

Setting technical directions is the most impactful thing for the staff engineer to influence and lead the team. It is also related to the Operating at Staff: writing engineering strategy and learn never to be wrong. I think it is worthy to unpack it a little bit.

The technical directions may include many components:

  • the choice of data storage
  • CI/CD best practice
  • Incidence response protocols

The author recommends to bottom up the strategy: start with tech spec, or RFC, and find the common ground for the team to buy in a strategy, then build a long- term vision based on strategies. Here is one concrete examples:

  1. We find several RFCs use DynamoDB as the major data store for its durability and speed.
  2. We can recommend the DynamoDB to the engineer team with best practice.
  3. This also impact our long-term vision that the AWS lock-in is OK, and cloud-agnostic is NOT pursued.

The staff engineer should be opinionated, — otherwise, the organization may rely on the consensus to make a decision; but also keep pragmaticism and agnosticism.

Recently, I played the exploration card to tackle a schedule problem with constraint programming. It was surprisingly fun and impactful to work on solutions from different perspectives.

Being glue means to keep the lights on. I heard stories that some Microsoft partner engineers work all day long to fix build break before the CI/CD pipeline matured. It was tedious, but important to unblock the other engineers.

Operating at Staff

Work on what matters

Impact != visibility. Do not work, or preen on low impact high visibility work, or snack on low impact, low effort work.

In my experience, the impact is usually measured by the dollar value or influence on the engineer team. That is why most of staff engineers are found in the core business unit or the infrastructure team. It is a well-known secret to switch to the infra team to fast track the path to the staff title. The caveat is there may not be enough oxygen in the room for so many staff engineers.

Writing engineering strategy

Strategies allow everyone to make a quick, confident decisions. They should be:

  • Specifics with explanation
  • Being opinionated

and bottomed up from tech specifications as we discussed in Setting technical directions section.

Managing technical qualities

Technical qualities are usually hard to measure, and most of engineers make conscious decisions of the tradeoff of velocity vs. quality. In my view, startup companies may prioritize the velocity to find the product-market-fit over technical quality. Therefore, we should focus on the hot spot to maximize the ROI. We then could learn from error-n-trial to build the guidelines for best practice.

The leverage points are the places which need lots of investment but can easily go wrong and hard to fix.

  • Interfaces, the contracts between subsystems. They’re generally have a very long life cycle.
  • Stateful systems, where the data is persisted. The DB migration is generally error-prone and painful.
  • Data models glue the interface and state to reflect the perception of the system.

The quality assurance program is just like any other initiatives in the organization, it needs:

  • Goals and objectives
  • Sponsorship from senior leadership
  • Metrics and dashboard
  • Path to success to reduce the friction
  • Tools to nudge the teams programmatically
  • Review and retrospective for lessons learned

Further reading:

Lead without authority

The staff engineer is a leader role without authority, it may borrow the authority from senior leadership to facilitate the daily operations. Thus they should stay align with authority. No surprise principle applies here.

The remaining guides, such as:

  • To lead, you have to follow
  • Create space for others
  • Build a network of peers

are more likely to build more allies inside the organization and deposit political capital for the raining days.

Getting the title

It occurs to me that many companies adopts the promotion committee for staff-plus level promotion. An independent group of staff engineers reviewed the promotion portfolio, scrutinized the achievements, calibrated across teams to make the final decision, the direct manager has little or none influence in this process.

However, your direct manager is still your prominent allie and sponsor. The general consensus is the candidate must demonstrate the capability in the next level consistently to be considered for promotion, and your manager is responsible for that assessment. The promotion portfolio can work as the personal charter to close the gap identified.

I acquired my staff title when switching company. It worked partly because of my stellar performance in the interview, but mostly due to the economic climate. The bull market artificially inflated my old company’s valuation, which pushed my compensation package to the next band. The new company had the capital, more importantly the optimistic expectation, a little bit FOMO. All these factors combined helped me to seal the deal.