Module 5: Keep Learning
Two lessons. Three sources publish reading lists, and together they run to about 130 items. This module cuts that to what you can actually read, and to a routine that survives a busy quarter.
| Source | Used for |
|---|---|
| Will Larson, staffeng.com learning materials | The largest list: posts, books, papers |
| Terry Brown | Books, the StaffPlus conference, newsletters, podcasts, “subscribe and scan” |
| Hands-on Architects | T-shaped and I-shaped learning, the daily and weekly routine |
| Tanya Reilly (ch. 9) | Build a new specialty |
The Reading List, Ranked
Will Larson’s learning-materials page lists about 100 items. Terry Brown lists about 25. Hands-on Architects list eight books. Read all of it and you will never write a strategy doc. This lesson ranks by how many of the three sources recommend an item, then by what it is for.
“Subscribe and scan. You will never want to read every article in every newsletter.”
Recommended by Two or More Sources
| Item | Who recommends it | What it is for |
|---|---|---|
| The Staff Engineer’s Path, Tanya Reilly | Brown, Hands-on Architects, and this guide | The spine of Modules 2 and 3. |
| Staff Engineer, Will Larson | Brown calls it “perhaps more insightful” than Reilly’s | Credited with popularizing the archetypes. The staffeng.com guides are the online version. |
| Becoming a Technical Leader, Gerald Weinberg | Larson and Hands-on Architects | Source of the MOI model in lesson 4.2. |
| Accelerate, Forsgren, Humble, and Kim | Larson and Hands-on Architects | The measurement case. |
| Being Glue, Tanya Reilly | On Larson’s list | The origin of the term in lesson 1.4. |
| What Sponsorship Looks Like, Lara Hogan | On Larson’s list, and cited in his sponsor guide | The companion to lesson 3.2. |
| The Engineer/Manager Pendulum, Charity Majors | On Larson’s list, and in his promotion guide | The route through management in lesson 3.5. |
Sources: Additional resources on Staff-plus engineering, Will Larson, Terry Brown, and Hands-on Architects.
Recommended by One Source, and Worth It
From Brown: The Software Engineer’s Guidebook by Gergely Orosz, chapter 2 on owning your career and the staff engineer section. “The best staff engineers I know routinely do all of the things Gergely highlights in this chapter.” Also the StaffPlus conference from LeadDev, which did not exist when Brown reached staff.
From Larson, on what the job is: What a Senior Staff Software Engineer Actually Does, parts 1 and 2, by Joy Ebertz (Box). How I operated as a Staff engineer at Heroku, Amy Unger. What does Staff level mean at GitLab, Charlie Ablett, which pairs with the handbook page used throughout this guide.
From Larson, on operating: Migrations: the sole scalable fix to tech-debt, Will Larson. Technical Decision Making, Cindy Sridharan. “I Wouldn’t Start From Here”: How to Make a Big Technical Change, Tanya Reilly. Design Docs at Google, on industrialempathy.com, for the template in lesson 2.3.
From Hands-on Architects: Designing Data-Intensive Applications, Martin Kleppmann. Fundamentals of Software Architecture, Richards and Ford. Expert Generalist, Martin Fowler.
Newsletters and Podcasts
Brown’s newsletter picks: The Pragmatic Engineer, LeadDev Originals, Tidy First (Kent Beck), Dear Architects, Software Lead Weekly, Crafting Tech Teams, LevelUp, Stay SaaSy, Leadership in Tech.
Podcasts: StaffEng (Larson’s, no longer current, interviews with staff engineers), Engineering Enablement (getdx), Dev Interrupted, Tech Lead Journal, Software Architecture Radio, a16z.
Source: Becoming a staff engineer: some resources, Terry Brown.
Papers
Larson lists 24 papers. Three to start with, because they come up in every architecture conversation: Dynamo, Out of the Tar Pit, and Hints for Computer System Design. Larson also links How to Read a Paper by S. Keshav, which is the right first read.
Source: Additional resources on Staff-plus engineering, Will Larson.
Pick three books, three newsletters, three posts. Delete the rest of this list from your mind. Reread it in a year.
The Code: Your daily unfair advantage in software engineering.
Join 350,000+ software engineers, tech leads, and CTOs who start their morning with The Code.
T-Shaped and I-Shaped: The Weekly Routine
Hands-on Architects split staff-level learning into two shapes. Reilly’s chapter 9 says when to change shape. Terry Brown gives the self-assessment.
The Two Shapes
T-shaped is breadth. Hands-on Architects call it the “expert generalist,” borrowing Martin Fowler’s term, and the target is “stuff you don’t know you don’t know.” Their routine is 15 minutes of reading a day with coffee, from sources like InfoQ, DZone Refcards, and the Thoughtworks Technology Radar. The Radar’s four rings (adopt, trial, assess, hold) are a cheap way to see what is moving outside your specialty.
I-shaped is depth. Be the go-to person for one class of problem. Their practices: write posts, give talks, mentor, and deliberately explore alternatives to your preferred solution so you do not develop tunnel vision. Document the pros and cons. Practice with coding challenges, system design sessions with peers, and architectural katas.
Their calendar answer for depth: a dedicated weekly slot, their example is 1 to 2 hours on Friday afternoon, timeboxed with the Pomodoro technique. They also use NotebookLM to summarize articles and explain concepts, and Atomic Habits’ habit stacking to make the routine stick.
Source: The Staff Engineer Toolkit, Hands-on Architects.
When to Change the I
Reilly’s chapter 9 lists “build a new specialty” as one of the paths from a staff role. The trigger is the Hands-on Architects line from lesson 2.2: every technical skill set goes obsolete over time.
Lesson 4.4 is the current example. A staff engineer whose depth is in a domain agents now cover has a new I to build, and the Friday slot is where it gets built.
Source: The Staff Engineer’s Path, ch. 9, Tanya Reilly.
The Self-Assessment
Terry Brown’s first internal resource is a career progression framework. If your company has one, review it with your manager. If it does not, progression.fyi collects public frameworks from many companies, and Brown’s advice is to find the one that fits and self-assess against it.
Do this once a quarter. The gaps it shows are the reading list for the next quarter, and they go straight into the gap analysis section of the promotion packet from lesson 3.1.
Source: Becoming a staff engineer: some resources, Terry Brown.
The Routine
Breadth reading with coffee. InfoQ, DZone Refcards, the Thoughtworks Technology Radar.
1 to 2 hours of depth, hands-on, with the tools from lesson 4.4 in the mix.
Score yourself against a progression framework and update the packet.
That is the whole module. Three calendar entries.
By this point you should have:
- Three books, three newsletters, and three posts chosen from the list, not thirty
- A 15-minute daily slot and a Friday slot on your calendar
- A progression framework to self-assess against once a quarter
What’s Next
The whole path in one page, plus every source this guide was built from, listed so you can go read the originals.