Team Lead Mindset
Sources and Reading List: Popular Repos and Documents
The most-starred GitHub lists and well-known documents behind this series, which I read directly, which I only know from summaries, and which I could not open.
On this page
In one line: these are the popular GitHub repositories and well-known documents behind this series, which ones I read directly, which ones I know only from summaries, and which ones I could not open. Read the originals before you quote them.
A series about thinking should show where its ideas come from. This lesson is the reading list. It is also a good answer to the interview question "How do you keep learning?", because it names real sources instead of "I read blogs".
How I picked the sources
I looked for two kinds of sources:
- Popular GitHub repositories on engineering management, technical decisions, code review, reliability and open-source health. Stars are a rough sign that many people found a repository useful. They are not a sign of quality, and star counts change every day.
- Well-known documents from teams that have run large engineering organizations in public: Google, Etsy, DORA, OpenSSF, the Rust project.
About the star numbers. I could not call the GitHub API from my environment (it was blocked), so I did not read live counts. The numbers below come from web search results (third-party pages that copy GitHub data) and each snapshot has a different date. Treat them as "about this size", and check the repository page for today's number. Where I found no number, I say so.
Popular GitHub repositories
| Repository | What it is | Stars (snapshot) | How I used it |
|---|---|---|---|
| kuchin/awesome-cto | A curated list for CTOs and technical leaders, mostly startups | about 31k | Read directly. Used to find sources on technology choices and technical debt |
| joelparkerhenderson/architecture-decision-record | What an ADR is, 13 templates, when to write one | about 13k (March 2025 snapshot; likely higher now) | Read directly. Used in Lessons 1 and 2 |
| charlax/engineering-management | A large list of articles and books on engineering management and tech leadership | about 8.3k (August 2026 snapshot) | Read directly (the whole page, in two parts). Used in Lessons 0, 2, 3, 4, 5, 6, 8, 9, 10 |
| charlax/professional-programming | A reading list for developers: code review, incidents, postmortems, build vs buy | not checked | Read directly (the first 100,000 of about 176,000 characters) |
| poteto/hiring-without-whiteboards | Companies whose interviews resemble real work | about 50k | Read directly (first 100,000 of about 145,000 characters). Used in Lesson 9 |
| dwmkerr/hacker-laws | Laws, principles and rules of thumb for developers | about 27k (April 2026 snapshot) | Read directly (first 100,000 of about 117,000 characters). Used in Lesson 7 |
| danluu/post-mortems | A list of public postmortems grouped by cause | about 12.2k (July 2026 snapshot) | Read directly. Used in Lesson 6 |
| python/peps | Python's public decision process (PEP 1 explains it) | not checked | Read directly PEP 1. Used in Lesson 5 |
| kubernetes/enhancements | Kubernetes enhancement proposals (KEPs) and their template | not checked | Read directly the template. Used in Lesson 5 |
| engineering-management/awesome-engineering-management | Tools and learning material for engineering managers | about 2.4k | Found in search; not read |
| kdeldycke/awesome-engineering-team-management | Another list for team management | about 2.2k | Found in search; not read |
| jesselpalmer/the-engineering-managers-booklist | Books for people who lead engineering teams | about 1.6k | Found in search; not read |
| google/eng-practices | Google's public code review guide (archived Nov 2025, pages still online) | not checked | Read directly four pages. Used in Lesson 3 |
| ossf/scorecard | Automatic security and health checks for open-source projects | not checked | Read directly the checks list. Used in Lesson 1 |
| rust-lang/rfcs | The Rust project's public decision process | about 6.1k (May 2025 snapshot) | Read directly the README and template. Used in Lesson 2 and Lesson 5 |
| dora-team/fourkeys | The four delivery measures, as a project | not checked | Read directly. Used in Lesson 4 |
| etsy/DebriefingFacilitationGuide | Etsy's guide to blameless debriefs | not checked | Only the introduction was readable |
| npm/cli | The npm command line; its docs describe each command | not checked | Read directly four command pages. Used in Lesson 1 |
| semver/semver | The Semantic Versioning text | not checked | Read directly. Used in Lesson 1 |
Well-known documents
| Document | Why it matters | Status |
|---|---|---|
| Software Engineering at Google (free on abseil.io) | A book on how Google builds software: teams, code review, dependencies, testing | Could not open (the host was blocked). Not used |
| Google Site Reliability Engineering book, chapter on postmortem culture | The standard text on blameless postmortems | Could not open. I know it from web search summaries |
| Google re:Work, Project Oxygen | Research on what makes a good manager | Could not open. Summaries only |
| DORA research reports | The research behind the four delivery measures | Could not open the site. I used the DORA team's own Four Keys project instead |
| Dan McKinley, Choose Boring Technology | The "innovation tokens" idea | Could not open. Summaries, and the way charlax's list describes it |
| Michael Nygard, Documenting Architecture Decisions | Where decision records started | Could not open. I used the templates in the ADR repository |
| Martin Fowler, technical debt quadrant | Deliberate or accidental, prudent or reckless debt | Could not open. Summaries only |
| Andy Grove, High Output Management; Camille Fournier, The Manager's Path; Will Larson, Staff Engineer and his blog | Classic books and writing on leading engineers | Not read. Mentioned only because the lists above recommend them |
Want the missing ones read properly? The sites I could not open (abseil.io, sre.google, martinfowler.com, mcfunley.com, cognitect.com, dora.dev and rework.withgoogle.com) were blocked by this environment's network settings. If those hosts are allowed in the environment settings, I can read them and tighten the lessons.
How to use a reading list (an interview-friendly way)
- Pick three, not thirty. One about decisions (ADRs), one about review (Google's guide), one about incidents (blameless postmortems).
- Try one idea at work. Write one decision record. Label your next ten review comments as Nit, Optional or FYI. Run one postmortem with "how" questions.
- Keep a short note on what changed. That is your interview story: "I read X, I tried Y, the result was Z."
- Argue with it. No list is the truth. Several sources above disagree (for example about "innovation tokens"), and that is healthy.
Added later: sources for Lessons 12 to 17
Lessons 12 to 17 were added after this page was first written. What they used, and how:
| Source | Used in | How I used it |
|---|---|---|
| jorgef/engineeringladders | Lesson 13 | Read directly: a public career ladder. Other company ladders on the lists were title-only |
| ossf/scorecard and the OWASP cheat sheets | Lesson 14 | The Scorecard check list was read directly (see above); the cheat sheets were not read in full |
| OWASP GenAI Top 10 for LLM applications (official OWASP repository) | Lesson 15 | Risk pages were read through the AI Engineering series; I read no vendor usage policies and no productivity studies |
| google/eng-practices | Lesson 15 | Read directly (see Lesson 3) |
| Sections "Organizational structure", "Scaling an organization", "Culture", "Motivation", "Learning, retro, postmortem" of charlax/engineering-management | Lessons 16 and 17 | Read directly; most entries are title-only or one-line descriptions, and the lessons say which |
| On-call, SLO and incident entries of charlax/professional-programming | Lesson 16 | Read directly as one-line descriptions |
| etsy/DebriefingFacilitationGuide | Lesson 17 | Two chapters read directly: Structure and preparation and The art of asking questions (earlier I could only read the introduction) |
Interview questions
What do you read or follow to improve as an engineer, and what did you change because of it? (Must know)
I name two or three real sources, one idea from each, and one change at work. For example: "I read Google's public code review guide. I started labelling my comments as Nit, Optional or FYI, and I tried to reply within one working day. Our review waiting time went down." I do not list ten blogs. A short answer with a real change is stronger than a long list.
A popular GitHub repo says one thing, and your team does another. What do you do? (Senior signal)
I treat stars as a sign of interest, not proof. I ask what problem the repo's advice was made for (a huge company, a startup, a database team?) and whether our situation is similar. Then I try the idea in a small, reversible way and look at the result. If it helps, we keep it and write down why. If it does not, I note that too. The aim is to fit our team, not to copy.
How do you check that a claim in an article is true? (Must know)
I look for the primary source (the official documentation, the specification, the original research), not only a summary. I check the date, because tools and advice change. I try it on a small example. If I only read a summary, I say so: "I know this from a summary, I have not read the original." That honesty is part of being trusted.
Key takeaways
- Popular repositories and documents are a good place to start, but stars are a rough signal only.
- Prefer primary sources: official docs, specifications, and the teams' own published guides.
- Say what you read directly and what you only know from summaries.
- Pick a few ideas, try them in a small way, and keep notes on the result. That becomes your interview story.
- All sources disagree somewhere. Think for your own team.
What's next
Go back to Lesson 0 and answer three real "why?" questions from your last project using the six steps. Then choose one source from this page and try one idea this week.
Published by Jainik · Last updated · How these lessons are made
Keep learning
Part of the study guide
Related series