| toc | summary |
|---|---|
true |
My impressions from the StaffPlus conference in New York |
[@whereistanya]{.twitter}
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:
- You could opt for a yellow lanyard if you didn't want to be in photos
- There were pronoun stickers for the name tags, and a coloured sticker to indicate if you're happy to chat with people or rather would not
- Washrooms were all-gender
- We were asked to form "C-shaped" groups during breaks, to make it easier for people to join your chat
- There was a quiet area, and people were asked not to eat there so attendees observing Ramadan would have a food-free zone
- There was live captioning of the talks!
- The only tech glitch was a dying microphone, which was replaced within seconds
The "Recording" links require a digital pass to the StaffPlus event.
[@dbsmasher]{.twitter} [Recording]{.video}
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.
[@harterrt]{.twitter} [Recording]{.video}
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:
- Could I delegate this?
- What feels urgent (as opposed to is urgent), who would care if I didn't work on it?
- Would the CFO (as somebody outside of engineering) think I'm irreplaceable?
- Am I better at my job at the end of the week than I was at the beginning?
[@cdwort]{.twitter} [Recording]{.video}
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.
[@hazelcough]{.twitter} [Recording]{.video}
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:
- Start with the quickstart guide
- Model the domain; don't shy away from non-technical complexity
- Learn the domain: integrate, read docs
- Design the model
- Test against use cases
- Package the model: simplify
- Test and iterate: build lots of integrations, remove friction
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.
[@ksylor]{.twitter} [Recording]{.video}
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:
- Partner with teams outside your org; highlight the benefits of your project to, for example, the business. Look at where org lines meet, and then "cross the A". Network by lurking in a lot of Slack channels, and build a reputation for good customer service.
- If you start with investing in infrastructure, you enable future work, and the infrastructure work can be valuable itself. Show that it actually is for every step; break the work down such that each step provides value on its own.
- Get feedback early and often: de-risk early stages, and test each stage. Measure continuously: start with a measurable goal, define success, and measure and track over time. If an increment is non-shippable: simulate ("send out rovers"), and run temporary experiments.
- Architect as a force multiplier: where an architect provides technical direction, the tech lead breaks the work down. The architect role can change over time; aim to level up your team, and transfer subject matter expertise; teach how to handle ambiguity, help understand when and why plans change, thinking about trade-offs, and using data to drive decisions.
[@fiftyvolts]{.twitter} [Recording]{.video}
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".
- Know your goal: you have to know yourself first why you want to do this work; business goals, personal goals? What do you know that others don't? And what will change because of your work?
- Focus on values: tap into deeper meaning, connect your work to cultural values of the company. Changing those is very hard, but if there is alignment, use that; if there isn't, consider reframing in terms of the values. ("Weaponize" them, basically.)
- Address your audience: understand who they are, what they need, and what you need from them. The audience is larger than just the formal approver. Rephrase your goals in terms of your audience's needs. Use proxies to expand your reach: for example, win over influencers first.
- Present progress: progress reports can be used to define success, and allow you to control focus. Commitment isn't "one and done". Dashboard are the "shadows in Plato's cave".
- Open your mind: don't be the bottleneck, build context in others, help others make your idea their own. Remove yourself from the day-to-day of others implementing your idea.
[@BobbyD_FL]{.twitter} [Recording]{.video}
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.
[@LeslieAChapman]{.twitter} [Recording]{.video}
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.
[@AliceLiCode]{.twitter} [Recording]{.video}
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.
[@scott_triglia]{.twitter} [Recording]{.video}
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:
- This email should have been a document
- Technical Decision-Making and Alignment in a Remote Culture
- Don’t ask forgiveness, radiate intent
- Strategies for making impossible decisions
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.
[@JohnRiv]{.twitter} [Recording]{.video}
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!
[@bryanl]{.twitter} [Recording]{.video}
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:
- Be a good example; realize that the higher up you go, the more your scope increases; if you 2x five people, you are a 10x engineer!
- Learn to delegate; Bryan referenced "levels of delegation", and how you should figure out what the appropriate one is for you
- Be a bridge: connect things that don't want to be together
- Build a culture that is tolerant of failure
- You can't control the outputs, so don't think about them; you can't will the outcomes
- Golden Circle: why, how, what; we tend to focus on the what and forget to ask about the why
- Write things down, embrace uncertainty, don't stop growing
[@DavidDaly44]{.twitter} [Recording]{.video}
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!
Footnotes
-
In my outsider/fanboy perspective, at least. ↩