What happens after you go past Senior? Will Larson, CTO of Calm, has been interviewing Staff-plus engineers across the industry for his new book, Staff Engineering.
This is our first full-length interview podcast episode! If you enjoyed it, please help us share with a friend and let us know your feedback! (Links at bottom)
1:00 Why research Staff Engineering?
- Most bigcos make up their ladders as they go along, or cargo cult from FB/Google.
- We have to separate management from leadership.
- Lara Hogan - the Voltron Manager
- Julia Evans' Wizard Zines
- Tanya Reilly - Being Glue
- Dan Na - Pushing Through Friction
- Julia Grace, Director of Eng at Apple: "Don't play team sports alone, you'll lose."
- The Staff level is a leadership role, you don't get promoted on the basis of your work alone.
- 3 types: Role Models, Mentors, and Sponsors
- Sponsors: Lara Hogan on Sponsorship
- The key question: "Do I need to develop myself" or "Is the company evaluating my work fairly"?
- Mentors: Some mentors give generic answers, others know your specific context. The second one is harder.
- Role Models: Helps you know someone with your background can accomplish something. Lighthouse hires are important as proof.
- Retention is most important here
- Look externally on Twitter and on StaffEng.com
- The best people may not be writing online
- Books are bought, not sold
- If you aren't visible, your work won't be valued.
- Most people don't manage their careers at all
- Most companies are set up to assume Fungible Developers which is exactly what you don't want to be
- But also blaming your manager is a self limiting belief. You personally have to be managing your own career.
- Write your own promotion packets on an ongoing basis.
- Julia Evans on Brag Documents
- Tip: Make your own achievements channel in Slack and log all that info for later
- Silvia Botros at Twilio
- Katie Sylor-Miller at Etsy
- Spend a huge amount of time soaking up context
- Reduce communication and coordination costs
- We rarely understand the problems we are solving when we design the solution
- One directional communication doesn't work - gathering context and providing a common interface helps solves this
- Architects are powerful bc they are aligned with their engineers, Managers have to align with their orgs
- Similar to a Product Manager role - all of the responsibility, none of the authority
- Opposite of Architects? It depends on the company's approach - do they plan and then ship, or do they ship and learn. Architects cannot function in the second type.
- 4 archetypes: Team Leads, Architects, Solvers, and Right Hands.
- Calm is all Team Leads - the majority of the value is not in operating or creating infrastructure - it is in creating product
- It's pointless to bias too much to Architect or Right Hand early on
- You don't see Right Hands except at much bigger companies - for scaling out
- Will Larson's Intro to Systems Thinking
- Thinking in Systems by Donella Meadows
- Engineers should have both an abstract Systems Thinker and a practical Solver toolkit
- Incident programs overfocus on compliance rather than remediation
- Incidents -> Response -> Review -> Management (catalog, tag) -> Remediation
- Don't focus on moving from stage to stage
- Accelerate: Building and Scaling High-Performing Technology Organizations
- 1. Delivery lead time
- 2. Deployment frequency
- 3. Change fail rate (defect rate)
- 4. Time to restore service
- How they dynamically run tests to improve productivity at Stripe
What is Career Chats with Swyx and Randall?
Short, focused chats about developer careers. 1 topic each, selected from the best of our writing and thinking.