2022-04-17
Two weeks ago, I had the opportunity to attend StaffPlus in New York, one of the very first in-person events for senior individual contributors (in tech). Being pretty fresh in a Staff level role myself, this sounded like the perfect event for me.
The event was hosted by Tanya Reilly, author of Being Glue and the upcoming The Staff Engineer’s Path. The talks were grouped into blocks of three to four, with a mix of shorter and longer talks in each block.
Between the blocks, there were breaks with catered goodness and “office hours” to chat to the presenters of the previous block, though they were around the entire day.
Clearly, a lot of thought had gone into the details:
The “Recording” links require a digital pass to the StaffPlus event.
This was an overview of what it means to be a senior individual contributor (IC), though at the Principal level. In Silvia’s view, being a senior IC means making technical decisions and leading, i.e., no doing everything yourself.
A senior IC is more effective if they report to a senior leader and partner with managers; they have input on the performance evaluation of teams.
They translate from product strategy to technical strategy, and from there to technical execution; they identify one-way (“trap”) doors, while avoiding micro-planning.
Silvia used an analogy of steering a ship into the “bay of appropriate futures”, and there was a lighthouse, but the details elude me now.
A method to avoid becoming an architecture astronaut is to be involved in handling incidents; generally, Silvia advises to keep contacts outside of engineering.
A lightning talk about a process to help focus on the most important thing to work on.
There are bad strategies to decide what to work on, for example: inertia, decibels, and guilt.
Ryan described his ritual: at the beginning of the week, he empties his inbox, reflects on the last week, and then chooses his work. This reminds me of my own process, based on Getting Things Done, though my cadence is daily instead of weekly.
To account for biases, Ryan asks himself questions:
Amy talked about getting up to speed quickly when starting a new job as a Staff+ Engineer by way of asking yourself (and others) questions. Some of these would be very relevant for the interview process as well, and to me, they make sense in general to better understand expectations for you position, even without starting at a new company.
Why were you hired, and why was the position filled externally? What’s the problem you’re supposed to solve? The range of possible answers here included “internally, nobody wanted the job”—which probably would be valuable to know during interviewing already.
To build your network, try to understand organizational context; focus on relations that violate Conway’s law. Amy has a script to use for “getting to know you” conversations.
What’s your job? Don’t make assumptions, set expectations. Clarify where on the archetype spectrum people see your position. How do different people define “Staff level”? How do they know somebody is ready for it? What’s top of mind for your manager?
What (wrong) lessons did you learn? Don’t over-index on past experience. As an example: an acquisition doesn’t have to kill innovation; this was interesting to hear, seeing that Amy works at GitHub, where innovation indeed hasn’t come to a grinding halt since the Microsoft acquisition in 20181.
What’s the first thing you should tackle? Agree on a timeline.
What are you, as a new person, uniquely qualified to do? You have the opportunity to identify under-documented areas, you could tackle paper cuts, you could re-examine assumptions; overall: be kind.
When do you know enough? Do you learn through experimentation, or doing? Is there a mismatch between your position on the spectrum and the company’s? (Is it the reason you were hired?)
To gain broad knowledge: draw infrastructure and architecture diagrams, map out a request path; to gain deep knowledge, look at the most complex piece of code, and figure out where its logs are.
Eventually, though, move beyond using these questions, and forget about them.
Amy’s talk is also available as a post on LeadDev.
This lightning talk was technical, i.e., not specifically about Staff+ work, but happened to be very relevant for me. Michelle described the lifecycle of an API design:
An impressive bit was how, as part of designing an API for checkout, the team looked at every single checkout implementation they could find online.
Katie (of Oh Shit, Git?!? fame) talked about running a long term project: turning Etsy into a progressive web app (PWA). The main alternatives were rebuilding from scratch, or refactoring; the latter took longer and was the harder sell, but that’s what they ended up doing.
The whole talk was anchored around a comparison to Mars missions: “to get to Mars, you have to get to the moon first.”
The advice was grouped into four strategies:
This was probably my favourite talk. Short and sweet, to the point, and actionable. Mattie is a director and not a Staff+ Engineer, so they were talking from the perspective on the “other side of the table”.
The topic of the talk was a framework for when “the brilliance of your ideas alone no longer gets commitment”.
I found this talk confusing, and maybe my Helveto–Canadian sensitivities for humility (and perceived absence of it) got the better of me, but the self-promotion got in the way of the message for me.
I did learn that Twitter builds their own hardware, and Bobby was involved in saving tons of money through realizing that you could use cgroups and namespaces to combine storage and compute into single nodes instead of separate ones, more efficiently using spare CPU capacity of storage nodes.
Right after what I found to be an overly self-promoting talk, Leslie
talked about… how to be a more effective self-promoter
influencer by taking cues from social media influencers.
She started off with bragging about her accomplishments, which was shortly thereafter revealed as a technique to improve your name recognition, along with being “known for things” (building your personal brand).
People should want to work with you; build trust by gaining a reputation for actually finishing things. This requires focus and saying “no”; set realistic expectations regarding your involvement, and point to other people who might be able to help better than you.
Listen and give people space; be an idea aggregator.
Share you influence, be a sponsor or mentor, and learn to delegate (“work to put yourself out of a job”).
Diversify: be involved in as many projects as you can (while still not over-committing, I assume).
Get involved outside of the office, give back to the community. Opportunities can crop up everywhere.
This was another technical talk, and slightly less relevant to me, though still very interesting.
Alice talked about how accessibility can be framed as “solve for one, extend to many”; for example, ramps designed for wheelchairs can also be used for strollers.
Semantic HTML supports screen readers; for a while, “divitis” introduced by CSS made this more difficult. Landmarks (navigable regions) and language attributes further support screen reader usage.
Dark mode might be easier on the eyes than light mode, but more importantly, respect user preferences.
There was quite some overlap between Scott’s talk and Katie’s or Mattie’s; I guess ambiguity is a common theme!
An “ambiguous project” can be one where you can’t even see the proper outline, that deals with unknown tech, or where new team dynamics are involved. Ambiguity is also an opportunity; you can make the project what you want it to be. Generally, the closer to the level “mission statement” you get, the less clear things are.
Before even starting, clarify the project goals. This helps avoid situations where the wrong thing is built, or where goals are “suspiciously generalized”. Work backwards by starting with a product brief (PR/FAQ) to provide specificity and clarity.
Who needs to be involved? Be specific, leverage frameworks such as RACI. Have your stakeholders review the product brief; aim for a tight group of visionaries (think “heist team assembly montage”).
Define intent early and iterate; prefer a “known mediocre” proposal to trying to be perfect. If you get lost talking about the project, workshop the right words and be very consistent (write glossaries!).
For execution, accelerate out of the unknown, and keep an eye out toward surprises. Socialize and get feedback, log and broadcast decisions; relevant articles and talks:
Produce frequent incremental value (see Katie’s talk!).
Know your exit criteria: pick your finish line, and repeat it a lot (see Landing projects successfully).
Manage yourself: protect the team from uncertainty, radiate resilience and calm when you hear bad news. Bend and adjust with pressure. Exploring the frontier of what you’re comfortable with can lead to tremendous growth.
John talked about the analytic hierarchy process (AHP) to make decisions. It is based on the insight that multiple independent judgments outperform an individual expert judgment.
The basic idea is to define criteria for the decision, and then weight them pairwise; then, the different solutions are compared pairwise per criterion. Every participant does that individually, or in a discussion similar to how you’d assign story points. The discussion itself might be more valuable than the result (though John said that they always ended up thinking the result made sense for them).
The outcome is a weighted decision, and if all the criteria and weights are published, anybody looking at the decision can see what the criteria were, and how they were weighted. John talked about a decision that was made using the process, but the criteria weren’t published—and the acceptance of the decision was very low.
The graphs coming out of using the process can, for example, be used in ADRs.
The talk certainly didn’t lack slides with tables and numbers, but thankfully, John has published a tool that can support the process. I’m looking forward to try and use this process sometime soon!
This talk was highly entertaining, but I’m not too sure what I’m taking away from it.
After establishing that there is no road (“it’s all swamp”) and no how-to, Bryan did provide some guidance around working at the Staff level:
David talked about establishing a peer group, specifically for Staff+ developers. He recommends providing a low barrier of entry: Slack channel, Google group, biweekly Zoom calls, the occasional dinner.
When meeting, they would usually just chat, bring up issues, and identify common problems. More recently, they have started a tech talk series, and a mentorship program (not limited to, but run by Staff+).
Of the 50 Staff+ at his company, about ten attend the Zoom calls. (For comparison: at my company, there are eight Staff+ in total).
The group should be self-organized, and provide value for its members.
David provides a collection of resources on his website.
We just started our own Staff+ peer group at work, so we’ll see how it goes!
The level of presentation skills was impressive; the range was from strong to very strong.
For myself, I’ve taken away things mostly around improving clarity for my own role, and what questions to ask to get there. I definitely want to try out AHP, and I feel better equipped to tackle ambiguity.
Certainly an event I’d consider attending again!