Just finished “Staff Engineer” by Will Larson. It’s all about high-level engineering roles in big companies. Interesting stuff, but honestly, it felt a bit theoretical for someone not already in that world.
Larson breaks down staff engineers into four types:
- Tech Lead: Basically what I do now. Senior engineer focusing on team performance, not just coding.
- Architect: For big companies. Oversees important technical areas.
- Solver: Trouble-shooter who jumps between teams. Not common in places obsessed with sprints.
- Right Hand: Works with top leadership, no direct reports. Helps spread their influence.
The book talks about how to become a staff engineer. Lots of stories from people who’ve done it. Big takeaway: you need to find and tackle problems yourself, not wait for tasks.
It got me thinking about my own job. Right now, I’m usually given work to do. At best I’ll be given a product objective and need to figure out and engineering solution that solves it. Moving up would mean spotting issues and pushing for solutions myself. I do this a bit with tech debt and dev experience, but staff engineers often do it across the whole company.
There’s also a section on managing technical quality as companies grow. It’s a step-by-step process:
- Fix urgent problems
- Use best practices
- Find high-impact areas
- Get everyone on the same page about software changes
- Measure quality
- Maybe set up a team for quality tools
- Create a full quality program
The book says to take it slow. No point in fancy quality programs if production is always broken.