1. Common Activities
1.1. Setting technical direction
1.2. Mentorship and sponsorship
1.3. Providing engineering perspective
1.4. Exploration
1.5. Being Glue
1.6. Some Code
1.6.1. most write some, some write none, but none write as much as they used to
1.7. "Slow but rewarding"
2. Operating at Staff
2.1. Work on what matters
2.1.1. Basically Eisenhower matrix but with "effort" instead of "value"
2.1.1.1. Avoid Snacking
2.1.1.2. Stop Preening
2.1.1.2.1. low impact, high visibility
2.1.2. Existential Issues
2.1.3. Work where there's room and attention
2.1.4. Foster growth
2.1.5. Finishing things
2.1.6. What only you can
2.2. Write an engineering strategy
2.2.1. Design Documents
2.2.1.1. describe the decisions and tradeoffs you've made in specific projects
2.2.1.1.1. describes a specific problem
2.2.1.1.2. surveys possible solutions
2.2.1.1.3. explains the selected approach's details
2.2.1.2. design docs at google
2.2.1.3. tips
2.2.1.3.1. start from the problem
2.2.1.3.2. keep the template simple
2.2.1.3.3. gather and review together, write alone
2.2.1.3.4. prefer good over perfect
2.2.2. Engineering Strategy
2.2.2.1. write 5 design documents, and pull the similarities out
2.2.2.1.1. that's your eng. strategy
2.2.2.2. tips
2.2.2.2.1. start where you are
2.2.2.2.2. write the specifics
2.2.2.2.3. be opinionated
2.2.2.2.4. show your work
2.2.3. Engineering Vision
2.2.3.1. write 5 eng. strategies and forecast their implications two years into the future
2.2.3.2. tips
2.2.3.2.1. write two to three years out
2.2.3.2.2. ground in your business and your users
2.2.3.2.3. be optimistic rather than audacious
2.2.3.2.4. stay concrete and specific
2.2.3.2.5. keep it one to two pages long
2.3. Curate technical quality
2.3.1. fix the hot spots
2.3.1.1. focus on identifying the root cause and helping improve those causes
2.3.1.2. maybe process, but maybe not, maybe offer alternative technical solutions to the situation
2.3.2. adopt best practices
2.3.2.1. limit concurrent process rollouts
2.3.2.2. early suggestions
2.3.2.2.1. version control
2.3.2.2.2. trunk-based development
2.3.2.2.3. CI/CD
2.3.2.2.4. prod observability
2.3.2.2.5. small atomic changes
2.3.3. prioritize leverage points
2.3.3.1. leverage point - places where extra investment preserves quality over time
2.3.3.1.1. preventing gross quality failures
2.3.3.1.2. reducing the cost of future quality investments
2.3.3.2. 3 most impactful leverage points
2.3.3.2.1. interfaces
2.3.3.2.2. stateful systems
2.3.3.2.3. data models
2.3.4. align technical vectors
2.3.4.1. give direct feedback
2.3.4.1.1. before process change, give direct feedback to the individual(s)
2.3.4.2. refine your engineering strategy
2.3.4.3. encapsulate your approach in your workflows and tooling
2.3.4.3.1. instead of hoping ppl read the documentation
2.3.4.3.2. encode it in the system itself
2.3.4.4. train new team members during their onboarding
2.3.4.5. use conway's law
2.3.4.6. curate technology change
2.3.4.6.1. architecture reviews
2.3.4.6.2. invsetment strategies
2.3.4.6.3. structured process for adopting new tools
2.3.5. measure technical quality
2.3.5.1. define your code quality definition
2.3.5.1.1. no one is good at this
2.3.5.1.2. "quality" is not well understood
2.3.5.2. define how to measure those
2.3.5.3. instrument measurements
2.3.6. spin up a technical quality team
2.3.6.1. "dev productivity" team, or "developer tools", or "product infrastructure" team
2.3.6.1.1. not QA team
2.3.6.2. start small to stay focused and usefull
2.3.6.2.1. eventually grow as the org grows
2.3.6.3. fundamentals of success
2.3.6.3.1. trust metrics over intuition
2.3.6.3.2. keep your intuition fresh
2.3.6.3.3. listen to and learn from your users
2.3.6.3.4. do fewer things, but do them better
2.3.6.3.5. don't hoard impact
2.3.7. run a quality program to measure track and create accountability
2.3.7.1. core approach
2.3.7.1.1. identify a program sponsor
2.3.7.1.2. generate sustainable, reproducible metrics
2.3.7.1.3. identify program goals for every impacted team and a clear path for them to accomplish those goals
2.3.7.1.4. build the tools and documentation to support teams towards their goals
2.3.7.1.5. create a goal dashboard and share it widely
2.3.7.1.6. send programmatic nudges for folks behind on their goals
2.3.7.1.7. periodically review program status with your sponsor
2.3.7.2. leading causes of failed programs
2.3.7.2.1. running it purely from a process perspective, and becoming detached from the reality of what you're trying to accomplish
2.3.7.2.2. running it purely from a technical perspective and skipping advocating for your goal and listening to those you're trying to motivate
2.3.7.2.3. trying to cover both perspectives as a single person - don't go it alone
2.4. Stay aligned with authority
2.4.1. never surprise your manager
2.4.2. don't let your sponsor surprise you
2.4.3. feed your manager's context
2.4.4. influencing without too much friction
2.4.4.1. over time you will develop your own views on how things **ought** to work.
2.4.4.2. you have to find a way to slowly influence your leaders with these ideas without causing too much friction
2.4.4.3. do this by staying heavily aligned with them each step of the way
2.5. To lead, you have to follow
2.5.1. two leader attributes
2.5.1.1. sufficiently refined view of how things **ought to work**
2.5.1.1.1. such that they can rely on their distinction between how things **are** and how they **ought to be**
2.5.1.1.2. to identify proactive, congruent actions to narrow that gap
2.5.1.2. they care enough about the gap to actually attempt those narrowing actions
2.5.2. ways to follow
2.5.2.1. be clear with yourself about your true priorities
2.5.2.1.1. "will what we do here matter to me in six months?"
2.5.2.2. give your support quickly to other leaders who are working to make improvements
2.5.2.3. make your feedback explicitly non-blocking
2.6. Learn to never be wrong
2.6.1. don't want to be the person that sucks all the oxygen out of the room, so need to learn how to be a better person who is often right
2.6.2. listen, clarify and read the room
2.6.2.1. listen through questions
2.6.2.2. define the purpose
2.6.2.3. read the room
2.6.2.3.1. on if the group is ready to decide and take next steps
2.6.2.3.2. or not ready and need more time and space
2.6.3. practice these things with stuff all around you
2.6.3.1. PR comments
2.6.3.2. comments/questions on documents
2.6.3.3. meetings
2.6.4. dealing with jerks
2.6.4.1. include someone they can't be a jerk to in the meeting
2.6.4.2. investing heavily into aligning with them before the meeting
2.6.4.2.1. so they feel heard and are less likely to derail the discussion
2.7. Create space for others
2.7.1. discussions
2.7.1.1. ask more questions
2.7.1.2. you be the note taker
2.7.1.3. coordinate with those who couldn't make the discussion
2.7.2. decisions
2.7.2.1. write it down
2.7.2.2. circulate often
2.7.2.3. separate style from substance
2.7.2.4. sponsor others
2.7.2.4.1. to make your work their work
2.7.2.4.2. to take on some of these initiatives you are pursuing, into their daily work
2.7.2.4.3. at least "a few times a month"
2.8. Build a network of peers
2.8.1. be visible
2.8.1.1. external
2.8.1.1.1. twitter
2.8.1.1.2. meetups
2.8.1.1.3. conferences
2.8.1.2. internal
2.8.2. ambient network
2.8.2.1. follow people in tech you can learn from
2.9. Present to Executives
2.9.1. execs are unique in their communication style and you can cater toward their style
2.9.2. write down what you plan to share, to develop a holistic view on the topic + prepare
2.9.3. present starting with SCQA
2.9.3.1. Situation
2.9.3.1.1. What is the relevant context
2.9.3.2. Complication
2.9.3.2.1. Why is the current situation problematic
2.9.3.3. Question
2.9.3.3.1. What is the core question to address
2.9.3.4. Answer
2.9.3.4.1. what is the best answer to the posed question
2.9.4. Use Minto's Pyramid Principle to structure supporting arguments
2.9.4.1. layers of 3 supporting arguments per summarized argument, recursively
2.9.4.2. img reference
2.9.4.2.1. img
2.9.4.3. grouping mechanism
2.9.4.3.1. start with all arguments laid out
2.9.4.3.2. then start to group them
2.9.4.3.3. summarize that grouping
2.9.4.3.4. repeat, to have only 3 per node
2.9.4.4. order by descending importance
2.9.5. Mistakes to avoid
2.9.5.1. Avoid fighting feedback
2.9.5.1.1. agree or disagree, think about the feedback later. Better to keep feedback coming, then push back and cause them to refrain in the future
2.9.5.1.2. if you disagree regarding a decision being made, give 1-2 arguments to try to change their mind, then let it go
2.9.5.2. Don't evade responsibility or problems
2.9.5.3. Don't present a question without a (proposed) answer
2.9.5.4. Don't fixate on your preferred outcome
2.9.5.4.1. "no decision is permanent"
3. Page 130
4. Resources
4.1. https://staffeng.com
5. Titles
5.1. Senior
5.1.1. Staff
5.1.1.1. Principal
5.1.1.1.1. Distinguished
5.1.2. aka Staff + --->
5.1.3. Manager
5.1.3.1. Sr Manager
5.1.3.1.1. Director
5.2. Does Title Matter
5.2.1. Nick: NOPE. Accept at dumb places. Which is many.
5.2.2. benefits
5.2.2.1. allow you to bypass informal gauges of seniority
5.2.2.1.1. (aka have an inflated amount of influence regardless of skill + abilities)
5.2.2.1.2. "you don’t have to spend so much energy putting your credentials on the table"
5.2.2.2. facilitating access to "the room"
5.2.2.3. increase in current and career compensation
6. Archetypes
6.1. Tech Lead
6.1.1. guides approach and execution of a particular team
6.1.1.1. calendar
6.1.1.1.1. ex
6.1.1.2. similar to senior engineering role
6.1.1.3. 1 x 8 ratio
6.1.1.4. responsible for
6.1.1.4.1. organizing the team
6.1.1.4.2. delegating tasks + design work
6.2. Architect
6.2.1. direction, quality and approach within a critical area
6.2.1.1. calendar
6.2.1.1.1. ex
6.2.1.2. intimate understanding of the business' needs, user goals, and relevant technical constraints
6.2.1.3. identify and advocate for effective approaches within their area of focus
6.2.1.4. large companies, companies with exceptionally complex or coupled codebases
6.3. Solver
6.3.1. finds appropriate paths forward on arbitrarily complex problems
6.3.1.1. calendar
6.3.1.1.1. ex
6.3.1.2. fire fighter - not an organizer, or really team player
6.3.1.3. moved onto problems identified by organizational leadership as critical and either lacking a clear approach or with a high degree of execution risk.
6.3.1.4. generally operates on problems that are already identified as organizational priorities and thus are called on to do relatively little org‐level chiropractics
6.3.1.5. they generally stop working on problems once they’re contained
6.4. Right Hand
6.4.1. extends an executive's attention, borrowing their scope and authority to operate particularly complex organizations
6.4.1.1. calendar
6.4.1.1.1. ex
6.4.1.2. akin to operating as a senior organizational leader without direct managerial responsibilities
7. Getting the title where you are
7.1. promotion packets
7.1.1. general template
7.1.1.1. what are your staff projects?
7.1.1.1.1. what did you do
7.1.1.1.2. what was the project's impact
7.1.1.1.3. what made this project complex
7.1.1.1.4. keep it very short and then link out to supporting design documents
7.1.1.2. what are the high leverage ways you've improved the organization
7.1.1.3. What is the quantifiable impacts of your projects?
7.1.1.3.1. increase revenue by $X
7.1.1.3.2. reduce year over year customer support tickets by X%
7.1.1.4. Who have you mentored and through what accomplishments?
7.1.1.5. What glue work do you do for the organization?
7.1.1.5.1. what is the impact of that glue work
7.1.1.6. which teams and leaders are familiar with and advocates for your work?
7.1.1.6.1. what do they value about your work?
7.1.1.6.2. one sentence, include data (survey data) when possible
7.1.1.7. do you have a real or perceived skill or behavior gaps that might hold you back?
7.1.1.7.1. for each, how would you address the concern?
7.1.1.7.2. one sentence each
7.2. find your sponsor
7.2.1. almost always will include direct manager
7.2.2. might need skip manager involved some too
7.2.3. tell them your goals (of becoming staff+) - be super honest
7.3. staff projects
7.3.1. no staff project required
7.3.2. picking one if you do
7.3.2.1. complex and ambigious
7.3.2.2. numerous + divided stakeholders
7.3.2.3. named bet, where failure matters
7.3.2.3.1. leaders will recognize this initiative
7.4. get in the room, and stay there
7.4.1. bring something useful to the room
7.4.1.1. that the room doesn't already have
7.4.2. need a sponsor to get into the room
7.4.2.1. your sponsor needs to know you want to be there
7.4.3. to stay
7.4.3.1. stay aligned with your manager
7.4.3.2. optimize for the group
7.4.3.3. speak clearly and concisely
7.4.3.4. be low friction
7.4.3.5. come prepared
7.4.3.6. focus and be present
7.4.3.7. volunteer for low-status tasks
7.4.4. mistakes
7.4.4.1. misunderstanding the room's purpose
7.4.4.1.1. don't bring other problems/desired to this room
7.4.4.2. being dogmatic
7.4.4.3. withholding consent
7.4.4.4. sucking the oxygen out of the room
7.4.4.5. embarrassing your sponsor
7.4.4.6. being flakey or not showing up regularly
7.5. being visible
7.5.1. internal visibility
7.5.1.1. work on projects that matter
7.5.1.2. write longer lived documents
7.5.1.3. promote your team's work (slack + email etc)
7.5.1.4. share weekly notes
7.5.1.5. contribute to company blog
7.5.2. executive visibility
7.5.3. external visibility
8. Deciding to switch companies
8.1. Finding the right company
8.1.1. Finding a new company lets you play "bias arbitrage"
8.1.1.1. keep looking till you find the one that disproportionately values you
8.1.2. Meritocrats vs Proceduralists
8.1.2.1. neither innately good, but may want to find the one that better fits you
8.1.3. other factors
8.1.3.1. archetypes
8.1.3.2. growth
8.1.3.3. sponsorship
8.1.3.4. durability
8.1.3.5. pace
8.1.3.6. everything else you value
8.2. Interviewing for Staff-plus roles
8.2.1. draw your lines
8.2.1.1. do you practice interview programming, or decide you don't want to work at a company that values "fast programming"
8.2.2. debug the process
8.2.2.1. what are the interview formats, including what are they evaluating for?
8.2.2.2. do any of the interviews require specific preparation?
8.2.2.3. Who are the interviewers?
8.3. Negotiating your offer
9. Stories
9.1. Michelle Bu
9.1.1. Payments Products Tech Lead at Stripe
9.1.2. treat reviews of their documents as user testing
9.1.2.1. where do their cursors go etc
9.1.2.2. 🤮 we're trying to be too clever here. Too efficient. NO one cares about your stupid document. Focus on effectiveness over efficiency.
9.1.3. want/expect design idea to continue without her presence
9.1.3.1. good goal
9.1.3.2. bad conclusion that it's because it was written down. It's not.
9.1.4. define when you're ready for feedback on a subject
9.1.5. "writing is important"... doesn't like to read (books/blogs etc)
9.1.5.1. likes getting feedback from peers
9.1.5.2. k.. so you like others to read about your ideas
9.1.5.3. really the goal is collaborating with others. be effective. stop forcing "writing".
9.1.5.4. creativity inc
9.2. Ras Kasa Williams
9.2.1. Staff Engineer at Mailchimp
9.2.2. write self review in the 3rd person
9.2.3. write for yourself, to ensure you have a clear and concise message/thought
9.2.3.1. even if you never share what you write, write to get your ideas concise and potent