Staff Engineer: Leadership Beyond the Management Track
Rate it:
Open Preview
Read between January 13 - January 14, 2022
16%
Flag icon
Don’t measure vision by the initial excitement it creates. Instead, measure it by reading a design document from two years ago and then one from last week; if there’s marked improvement, then your vision is good.
16%
Flag icon
If there’s one thing that engineers, engineering managers, and technology executives are likely to agree on, it’s that there’s a crisis of technical quality.
16%
Flag icon
It’s a compelling narrative with a clear villain, and it conveniently shifts blame away from engineering leadership.
16%
Flag icon
When you accept the premise that low technical quality results from poor decision-making, you start looking for bad judgment, and someone at the company must be the culprit. Is it the previous CTO? Is it that Staff engineer looking at you with a nervous smile? Is it everyone? What if it’s none of those folks, and stranger yet isn’t even your fault either?
16%
Flag icon
low technical quality isn’t a crisis; it’s the expected, normal state.
16%
Flag icon
fix the hot spots that are causing immediate problems adopt best practices that are known to improve quality prioritize leverage points that preserve quality as your software changes align technical vectors in how your organization changes software measure technical quality to guide deeper investment spin up a technical quality team to create systems and tools for quality run a quality program to measure, track and create accountability
17%
Flag icon
a deployment causes an outage, it’s because the author didn’t correctly follow the code test process, so now we’re going to require tests with every commit – that’ll teach those lazy developers!
17%
Flag icon
At some point, you’re likely to find that your organization is creating quality problems faster than you’re able to fix hot spots, and that’s when it’s time to move on to adopting best practices.
18%
Flag icon
This sad tale mirrors how many companies try to roll out best practices, and it’s one of the reasons why best practices have such a bad reputation.
18%
Flag icon
Adopting best practices requires a level of organizational and leadership maturity that takes some time to develop.
18%
Flag icon
When you’re rolling out a new practice, remember that a good process is evolved rather than mandated.
18%
Flag icon
The transition from fixing hot spots to adopting best practices comes when you’re overwhelmed by too many hot spots to cool.
18%
Flag icon
Take everything you’ve learned, and pull it into a technical specification document that you socialize across your team. Gather industry feedback from peers. Even after you begin implementation, listen to reality’s voice and remain open to changes.
19%
Flag icon
Conway’s Law argues that organizations build software that reflects their structure. If your organization is poorly structured, this will lead to tightly coupled or tangled software.
19%
Flag icon
Most companies can combine the above techniques from hot-spot fixing to vector-alignment into a successful approach for managing technical quality, and hopefully, that’s the case for you.
19%
Flag icon
There are some process measurements that correlate with effective changes. For example, you could measure the number of files changed in each pull request on the understanding that smaller pull requests are generally higher quality.
20%
Flag icon
What percentage of the code is statically typed? How many files have associated tests? What is test coverage within your codebase? 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 mutation within a single transaction? How many functions acquire low-granularity locks?
20%
Flag icon
It’s rare for these teams to have a product manager, generally one-or-more Staff-plus engineers, and the engineering manager partner to fill that role. Sometimes they employ a Technical Program Manager, but typically that is after they cross into operating a Quality program as described in the next section.
20%
Flag icon
Trust metrics over intuition. You should have a way to measure every project.
20%
Flag icon
Keep your intuition fresh. Code and process change over time, and your intuition is going stale every week you’re away from building product features.
20%
Flag icon
Do fewer things, but do them better. When you’re building for the entire engineering organization, anything you do well will accelerate the overall organization.
21%
Flag icon
Even if you’re quite successful, you’ll always have a backlog of high-impact work that you want to take on but don’t have the bandwidth to complete.
21%
Flag icon
A quality program isn’t computer code at all, but rather an initiative led by a dedicated team to maintain technical quality across an organization.
21%
Flag icon
Build the tools and documentation to support teams towards their goals. Once you’ve identified a clear path for teams to accomplish your program goals, figure out how you can help them make those changes!
22%
Flag icon
Create a goal dashboard and share it widely. Once you have your program goals communicated to each team, provide dashboards that help them understand their current state, their goal state, and that give reinforcing feedback on their (hopeful) progress along the way.
24%
Flag icon
To lead, you have to follow
24%
Flag icon
the most effective leaders spend more time following than they do leading.
24%
Flag icon
Make your feedback explicitly non-blocking.
25%
Flag icon
A lot of times, you’ll see engineers go into a discussion confident that their perspective is right and with the goal of getting other folks in the room to agree with their approach. This mentality turns each meeting into a zero-sum debate. Even in the “best case” that their approach is agreed upon, they didn’t get to learn from anyone else in the room, and it’s unlikely that the rest of the room is leaving energized.
25%
Flag icon
To get good at this, you need to master three approaches: listen through questions, define the purpose, and know how to read the room.
25%
Flag icon
Good meetings start from a clear purpose and agenda, but many meetings don’t meet that definition, particularly ad-hoc discussions.
25%
Flag icon
Take a moment to ask if your understanding of what the group hopes to accomplish is correct. This works best as a statement wrapped in a clarifying question along the lines of, “Just to check, our goal here is to decide whether to postpone launching the project by two weeks?”
26%
Flag icon
longevity as a senior leader is just as much about maintaining your relationships as it is about standout successes.
26%
Flag icon
One of the best measures of your long-term success as a Staff-plus engineer is that the organization around you increasingly benefits from, but doesn’t rely upon, your contributions.
26%
Flag icon
This broader definition depends on getting more folks involved and getting to a good set of decisions without much of your own personal contribution.
26%
Flag icon
Shift your contribution towards asking questions. Asking the right questions helps avoid missteps, but also makes it easier for more folks to contribute
26%
Flag icon
Be the one to take notes. This helps destigmatize note-taking as “low status” and also frees up an alternative would-be notetaker to contribute more instead. It also gives you something to focus on other than speaking!
27%
Flag icon
Write it down. There’s a well-worn model of genius encapsulated in the Feynman algorithm: “1) Write down a problem. 2) Think very hard. 3) Write down the solution.”
27%
Flag icon
If senior leaders don’t change their mind, then soon everyone will correlate bluster with success
27%
Flag icon
When critical work comes to you, your first question should become, “Who could be both successful with and grown by this work?”
28%
Flag icon
Networking, networking, networking, networking… You have to be really cognizant of who you’re talking to and make sure that you have connections across multiple teams and multiple groups to leverage those networks.
31%
Flag icon
Never fight feedback. It’s very common for an executive to have a critical piece of feedback but to not quite have the right framing to communicate it within the moment. You want them to deliver the feedback anyway, not hold it back and probably forget to give it later. If you show up as resistant to feedback, then they’ll start swallowing their comments, and you’ll get relatively little out of the meeting.
31%
Flag icon
“never bring your manager a problem without a solution.”
31%
Flag icon
The best advice I’ve heard is that often reaching Staff is a combination of luck, timing, and work.
31%
Flag icon
A Staff engineer isn’t a better Senior engineer, but someone who’s moved into fulfilling one of the Staff archetypes.
32%
Flag icon
Your promotion packet is your foundational tool to demystify the Staff promotion, prioritize the right personal development to ensure you get there and activate your internal sponsors and network in support of your progression
34%
Flag icon
Bring the promotion packet to your next 1:1 with your manager, and tell them that attaining a Staff promotion is a goal of yours.
35%
Flag icon
While you’ll likely have a variety of sponsors, in the context of getting promoted—especially to a Staff-plus role—this almost always needs to be your direct manager.
35%
Flag icon
While you’ll always need your direct manager engaged as your sponsor, you may need additional sponsorship.
35%
Flag icon
“I’m looking to be recognized as a Staff engineer”