Last weekend I was painting the boys’ room and signed up for an Audible trial for some longer-form content than my typical podcasts. I’m not the fastest painter, clocking about 5 hours for cleaning, taping, and clean up and 6 for painting. By the end, the room looked great and the boys were very happy. As mentioned in a previous post, I’ll listen to Will Larson’s StaffEng podcast while driving to work. Those interviews have been so informative that I selected to listen to his synthesized book Staff Engineer: Leadership beyond the management track.

Will starts the book by categorizing staff+ engineers he’s interviewed into the following buckets by behavior.

Staff Engineer Archetypes

  • Tech Lead: Drives 1-2 team’s planning and execution, unblocking along the way as needed via mentoring. This is the most common variety since it occurs roughly at 1 per 8 engineers.
  • Architect: Leads direction, quality, and approach within a specific critical domain. See Brian Chambers Theory of Waves.
  • Solver: Digs deep into arbitrarily complex problems and finds a path forward. Might bounce around the organization as needed.
  • Right Hand (can’t resist the Hamilton reference ): Provides additional bandwidth to leaders of organizations by acting on their behalf. Requires tight alignment.

What do staff engineers do? Focus areas include mentoring, building their technical brand, and advocating for burning down tech debt while balancing delivering business value. One theme in various leveling rubrics is the time horizon of assignments gets longer at the higher levels. Feedback cycles also slow down commensurately, so the engineer must have good judgment and the ability to glean non-obvious cues to inform adjustments to trajectory. There are benefits to being at a Staff+ level. The title allows you to stop wasting effort proving your seniority. Interviews found this more common with women and minorities. You are also more likely to be allowed access to “the room where it happens.” There’s also increased agency to pick projects, but that comes with higher accountability for alignment of impact from those projects. Don’t get too comfortable working on easy and low impact instead of going for hard and high impact. There is a subset of this low-impact work that is high visibility. Too much optimization for visibility can also be a pitfall. “Visibility is a transient currency. Learning and developing yourself is a permanent one; focus on the latter once you’ve done the minimum to clear the former’s cliff.” ( quote )

Effecting change is a primary goal of a Staff engineer. The book contained a full section on methods for driving improvement in technical quality. One principle was to start with small, concrete changes that can layer on each other rather than rolling out a multifaceted program all at once. Engineers will be able to digest and internalize the slow, steady pace of change more effectively than split attention would allow. Another benefit of stepwise change is it allows monitoring the target metrics along the way to understand when a change moved the needle in a positive direction versus non-significant change or regression. Interesting but telling quip: “It doesn’t reduce risk, just makes it more clear who to blame when things go wrong.” Beyond audit requirements, we must make sure the processes we are creating actually reduce risk and not just service to point out problems after the fact.

Create space for others. The way a Staff engineer can be most valuable to his or her employer is to have a multiplicative effect on others. In order to let others flourish and solve problems on their own, you need to not be involved in everything. I have made the mistake in the past of being involved in too many decisions that it became hard to pull back. Make your feedback non-blocking on a document or code review (i.e. label the comment as a “nit”). This lets people assimilate what you’re saying while still exercising their own power of decision and building that muscle. When you do make a decision, write down the thinking process and research paths that lead to that decision. Even supporting arguments for the decision do not bring others along in the reasoning process as well as laying out the various paths of your research. This still needs to be balanced and well-organized to keep the reader on track.

Organizational authority is loaned, not given. It can be retracted. Using it depends on staying aligned with the sponsor that gave it to you. This idea of stewarding the responsibility you were given also applies to “remaining in the room.” A character quality that applies to both async decision-making (RFPs, code reviews) as well as in-person interactions is a low-friction demeanor. Someone used their social capital to invite you into the room. You should act in a way that makes the other members respect your sponsor’s judgment call of involving you. One of the most important things (especially for opinionated people such as myself) is not sucking the oxygen out of the room. No one else wants to work in that environment. Don’t act like every small decision is “threat level 1000” since, in reality, most are not. The second most important takeaway from this section was about being understood. I love this quote: “Keep in mind that it’s your obligation to be understood, not the obligation of everyone else to understand you.” It is similar to the idea in the Bible how Jesus came to serve rather than be served.

Will includes a chapter in the book on presenting to executives. My only tangential experience was helping plan a Data Modernization report-out some managers were giving, so I found this insight fascinating. The book says that executives are used to and very adept at processing data presented in a particular way. Your presentation will be most effective if you align with that methodology. For example, the executive might ask questions for pattern matching or expect data points up front rather than saving for the end. Get a clear understanding of why you are presenting and what you hope to accomplish: planning, status reporting, or resolving misalignment. Your goal is to extract their perspective and understand how to align with their priorities, not causing them to change their mind. Structured writing is important to effectively prepare thoughts, see The Pyramid Principle by Barbara Minto. Below are the 4 points in the SCQA format. I plan to start utilizing this in my writing.

SCQA Format

  1. Situation: Provide context.
  2. Complication: Why is the current situation problematic?
  3. Question: State the question succinctly.
  4. Answer: Propose your solution.

Concise writing and speaking lets you contribute more ideas in less time. Many times your opening paragraph in SCQA format is all that is needed to start the conversation. However, the planning necessary to write the full document will pay dividends when speaking in person. After you’ve written the document, ask for review by peers and stakeholders. The first round will be refining concepts and communication, so balance the seniority of those reviewing. You want to receive the necessary feedback without using up your time allotment from those you want to be engaged at approval time. The second round is with those decision-makers to get alignment prior to the meeting. That will help ensure as much as possible that there are no surprises at the meeting and the official approval is almost a formality. This is exactly the function of the majority whip in Congress. They ensure the necessary support is committed before calling for a vote.

Here are several link-outs from the book for my followup reading list. They were suggested as ways to dive deeper into the specific topics.

In a similar vein, on Tuesday afternoon I watched a Staff Engineering panel on Zoom. It was super inspiring to hear what some of the people were building. They were also very close to my age, younger than I was expecting for people so senior. One resource I would suggest following is Ryan Peterman’s newsletter developing.dev . It is short yet hits on important topics.