“Staff Engineer” Read Through, Part 1

“Operating at Staff” through “Managing Technical Quality”, Pages 32-69

Listen, I started numbering these at 0. Partly because I am a nerd, but partly because part 0 covered the preamble. So this is Part 1, base 0. Enjoy.

Operating at Staff

While I’ve discussed this a lot of times, even from Mid-level to Senior, the book calls out that the “promotion” to staff is often simply viewed as a sequential step from Senior, but this is truly a different role that you are able to change to.

It comes up frequently, but in this section it is called out that the speed of feedback and ability to measure impact and results can have a dramatically different cycle. When you are strategizing, aligning others, setting direction, mentoring, and other Staff+ behaviors, these are investments that can take months or years to truly show impact.

The list of topics is very strong, showing some clear priorities one needs to focus on to operate effectively as Staff+. A phrase did jump out at me here, describing potential missteps as “career-limiting moves”. I have heard this phrase before and it sort of chills me. When I first heard it I sort of laughed it off. Burning one bridge with an awful colleague, or failing to bend to the will of a megalomaniacal boss might have impact in that job, but they can’t control your whole career. My feeling has changed a little bit on this. Even if you change jobs after a misstep, it can still mean that you lost opportunities or learning experiences that can hurt you, even if it can’t completely destroy your career.

I have not yet, but I will go ahead and link an article called out here: Lara Hogan’s “What Does Sponsorship Look Like?”, which can help distinguish mentorship and sponsorship.

Work on what matters

I definitely resonate with the call-out that more time or effort is not what will continue to scale impact. Finding ways to be more effective in the same time, through force-multiplying, ruthless prioritization, and crisp communication is key.

One of the case-study participants, Michelle Bu, noted that she prioritizes “energizing” work, rather than focusing strictly on “impactful” work, as the former centers herself in work experience, instead of centering on the company in the latter case. This is VERY insightful to me. I have struggled to be energized by my work for a long time. It has been pretty draining. Much of it has nothing to do with the work and more to do with my approach, mental state, and so on. I have had times in my career that there were tasks I “got to” do instead of “had to”. I considered many Bar Raiser activities this way. It was a privilege to work with diverse interviewers, candidates, hiring managers, and recruiters. Interviewing a candidate for a new role was especially exciting. This definitely has me thinking about what would be needed to regain energy in my work, and be less drained by the prospect of doing work that doesn’t feel tuned to my strengths.

There is a specific quote about the dire cost of sleeping less or cutting out hobbies or other fun activities to work more. I consider these things the fuels we need. If our tank is empty, the number of hours we put in will not be relevant, we won’t have much to give. If we can refuel and come to problems fresh, we can better devote ourselves to solving them.

Avoid snacking

I am DEEPLY guilty of what is described here as “snacking”, which is to spend time working on easy, low impact tasks when the easy, high impact tasks are gone. The alternative is to move to high effort, high impact tasks, which can feel overwhelming, or unbounded. I do try to time box it more now, and I do feel like reviewing code can be a sort of… medium impact. It can force multiply by allowing me to identify endemic issues and help share fixes, it can help up-level others’ approaches, and so on. I have spent almost all my time doing this, though.

I was trying to use it to learn how things worked at Meta, seeing how people were fixing things, what parts of the code affected what, and so on. I would also provide my general feedback where applicable. This didn’t end up having the effect I’d hoped, and was interpreted to be a waste of time by my leaders. I think it may have been criticized a bit sharply, but it wasn’t entirely off-base. I didn’t balance appropriately. The main point of this section is that you CAN snack occasionally, but you need to remain aware of the impact on your higher impact tasks and maintaining balance.

Stop preening

I didn’t have notes on this. The message is pretty clear: preening, or doing lower-effort, highly-visible work may get some short term positive attention, but ultimately doesn’t add up to significant long-term impact.

Stop chasing ghosts

The crux of this section is, when starting on a new team, organization, or company, not to be unduly influenced by the ghosts of past failures, successes, or priorities.

Beyond this, my favorite note here is that those who optimize for their own criticality and ability to grab credit are awful. This is acutely accurate.

Existential issues

If there is something that threatens the on-going survival of a company, this has to be a top priority. Redecorating the bridge of a sinking ship will only be of value to the future sea creature residents.

Work where there’s room and attention

Often some of the known, most impactful work is already well-staffed and under control. Throwing yourself into this work may not move the needle, and it may make things worse. Instead, finding the unidentified or understaffed areas of great impact can be a much more valuable investment. The book notes a few examples, like developer tooling, glue work, and inclusion work. The latter is very close to my heart, and VERY hard to quantify. One could measure over time subjective measures via surveys, but shifting culture demands dedication and acceptance of small gains.

When inclusion work in particular is not of interest, doing it will make smaller gains that are easily lost, and progress won’t be appreciated. The author calls out that this doesn’t mean the battle is lost, but instead attacking the disinterest through advocacy, and recognizing that it is a moral and ethical imperative.

Foster growth

This section struck a chord with me. This is really where I want to dedicate my life’s work. Growing people, teams, and the industry, and aiding in maturing practices and making our work humane is what I am most passionate about.

The author notes that dedicating yourself to this kind of growth, even in a small measure, can make this your legacy. One of the best outcomes of this behavior in my career was with the mobile client org in Prime Video at Amazon. Years after I left I still heard from engineers still on the team saying that processes I put into place still served them well, how I reviewed work and improved it is still an exemplar, and so on. The book notes that this legacy outlives your code contributions, and this is definitely my experience.

Edit

Making small changes to project or team mechanics can yield large benefits. Do that.

Finish things

When there is just SOMETHING that keeps getting in the way of a team finishing a project, helping them get over the hump and deliver is extremely impactful. One example I experienced was working on our 3p Android client app for Prime Video. I had led failed efforts (well, canceled, but that’s a kind of failure) to deliver this in the past. Eventually we had joined a complex, cross-company effort at a mega-app. Beyond our video component, the project itself kept floundering. My director said “can you just make this happen?” and I agreed. It was not easy, it was not all me in any way, but finding where the real blockers were and simplifying did move things forward, and we did finally ship.

What only you can

This is something that has really flummoxed me. Previously at Meta it sunk my ability to work there. At Google I still haven’t reconciled this. The book notes that things that won’t happen if you don’t do them are unique opportunities for impact. When I finally found a team match at Meta, I found significant morale and burnout issues. I thought the most important thing I could do was champion changes to planning and commitments to relieve some of the unrealistic expectations on the team and prevent frequent churn as multiple commitments collided. I think what I suggested helped, but me doing this was not aligned with what was expected of me. I thought that no one else would speak up and make changes. I think that’s true, but it was not valued.

I am hoping to better align my unique strengths with my team’s needs, or find a team that is missing what I have to offer if I am given that opportunity.

Why it matters

Building skills and true expertise gives you the only currency that will matter in advancing your career, actual ability and experience.

Writing engineering strategy

I haven’t experienced this myself, so it’s helpful as future guidance. I have written design docs, and some strategies. I have written a long term vision doc, but recognize now how the guidance here would have made it better.

One of the first things the author mentions is that your great ideas that you have initially are not useful guiding principles, and they must be dismissed to actually succeed in grounding each step in real experience. I definitely didn’t do this in writing a vision document. My vision was a mishmash of some business needs and cool things I wanted my team to build. It really wasn’t grounded in strategies.

The “formula” put forth in the book is to write 5 design documents, then refine to a strategy. Once you do that, do it 4 more times to have a total of 25 designs and 5 strategies that can then be refined to a vision. This feels very connected to the work being done, and is a much better foundation than I worked from.

One gem from this section was to be careful about design critique. Ensuring that designs are good is important. Helping others improve is also. However, you’ve only written your best design doc once. Expecting others to meet or beat that quality (and maybe even expecting it or yourself every time) will slow things down and be discouraging. Improving quality is a goal, but producing software requires accepting a lot of good but not perfect designs.

Managing Technical Quality

This section begins with a quote that really resonated with me. Paraphrased, it says that the contributor feels most impactful when they can share their experience and expertise with a team that can’t quite generate a solid plan from good ideas. I love this and feel the same way. Showing where to focus attention first, simplify a v0, generate parallel work streams, enunciate external touch points to prioritize, and so on is amongst my favorite things. It turns a rough idea into an effective plan, and a rather ambiguous set of tasks into concrete execution units.

The next salient point is that while there CAN be quality crises, often quality lagging standards is the norm. As your standards raise, all previous work falls below that bar. This shouldn’t be a shock, and should be accounted for in a structured way. Further, you cannot do one thing, or run a single program, or even make a significant, dedicated effort and “win” quality. You can build safeguards, you can improve a pain point, but you only learn and enable continued opportunities to keep improving.

The author explains that improvements need to start small and gain momentum. Even if a major overhaul is needed, starting with easy wins like linting one part of the codebase helps acclimate teams to the benefit of small investments in quality before committing to bigger changes. Further, immediate bombardment with new process will generate resistance and create pushback.

As with most improvements or fixes, measuring, finding the biggest area of opportunity, and focusing precisely is more effective than guess and check efforts or relying on intuition. Having a measure also allows proper progress tracking to ensure work is having the desired impact.

Having a structured, and gradually expanding approach to quality is important, and it can be tempting to tackle a few “high ticket” items at once to maximize gains. The author calls out that ruthlessly prioritizing and picking a single best practice or improvement to rollout at a time is helpful to maintain focus and measure impact.

The author stresses again, that as you scale up your quality efforts, and intend to implement larger scale quality programs, you must measure. Sometimes one of the most challenging parts of these improvement programs is being able to have measures that actually capture the dimension you want to improve. If you are trying to improve Engineer experience, while you can survey and take subjective measures, it can be helpful to develop some proxies that are more concrete. For example, if you want to reduce iteration time in your code review process, time to first review, and total iteration count could be ways to measure this. If your measures are poor proxies, they should be abandoned and reworked. Making great strides against a proxy metric that doesn’t actually have a positive impact on the real problem is not success.

Another point that struck a chord with me in this section was that often a general best practice or approach that works well for many teams may be ineffective, or even damaging, to teams with unusual processes or tools. Sometimes it may seem that standardizing then applying the standard best practices would be a good idea, but often teams working in atypical manners are doing so out of necessity. For me this was often working on mobile teams, and dealing with measures or standards that were built for server-side teams. Many build systems didn’t accommodate, or measures were designed for immediate deployment (such that old code is no longer running in hours or days, versus months or years). Empowering these teams to amend or replace best practices that don’t apply is critical, otherwise they will always feel that they are not meeting standards and their work is unappreciated.

The next suggestion that grabbed my attention was providing examples when establishing practices or new standards. I find this extremely helpful. A long document detailing all of the ins-and-outs tends to be harder to use as a model than a few clear demonstrations captured in “golden” code changes showing how to apply the new guidance. Whenever I have had access to such a change record in refactoring or migration, it has always made my life much easier than trying to take a dozen steps written out and applying them to my own code.