A free, structured guide for the engineering manager who needs to learn AI fast. Eleven modules take you from LLMs and RAG to hiring, evaluation and strategy, with 100 AI interview questions and the templates you need to build and manage AI teams. No ML background required.
- Engineering Managers and Senior EMs with a strong software background and little or no ML exposure.
- Directors, VPs, and TPMs who fund AI work and need to judge it honestly.
- Staff engineers moving into management who want the leadership half of the job.
New to this? Do these three things in your first hour.
- Take the self-assessment (20 minutes). Twenty questions across five areas. Your score routes you to the right path.
- Pick a learning path (15 minutes). Three personas, each with a 30/60/90-day plan.
- Read the top 10 interview questions (45 minutes). Even if you are not interviewing, these ten questions map the field better than any syllabus.
- The 100 question bank indexed by category and tier, with model answers for the fifty that matter most.
- Company guides for eleven employers and employer types, covering commonly reported themes.
- Templates you can copy today: an AI feature PRD, an eval plan, a launch checklist, and an incident postmortem.
| Module | What you get | Time |
|---|---|---|
| 00 Start here | A self-assessment that routes you, three learning paths with 30/60/90-day plans, and a 100+ term glossary written for managers. | 1 hour |
| 01 AI foundations | How LLMs actually work, the ML/deep learning/GenAI taxonomy, the capability map, the model landscape, and a worked monthly cost example. | 1h 45m |
| 02 Applied AI systems | Prompting, RAG, agents, the fine-tuning decision, the pattern catalogue, and evaluation, the cornerstone page of this repository. | 2h 25m |
| 03 Production and LLMOps | Deployment options scored, observability, guardrails, prompt injection with worked attacks, and cost management. | 1h 45m |
| 04 Building AI teams | Three org models, a roles matrix, hiring loops and rubrics, four job descriptions, career ladders as deltas, and a 12-week upskilling programme. | 2 hours |
| 05 Managing AI teams | Planning work you cannot estimate, eval-driven development, the three-layer metric stack, executive communication, ten named failure modes, and public case studies. | 2h 15m |
| 06 AI strategy for leaders | Build vs buy vs fine-tune, vendor selection and exit costs, portfolio roadmapping, the EU AI Act, and a responsible AI review you can run on a Tuesday. | 1h 50m |
| 07 AI for engineering productivity | Using AI to run a better org: the coding tools landscape, an adoption playbook with a policy template, and how to measure impact credibly. | 1h 5m |
| 08 Interview prep | A four-week plan, 100 questions across four tiers, eleven company guides, four worked system designs, twelve STAR prompts, and three mock transcripts. | 6 hours |
| 09 Resources | Courses, books, papers, newsletters, communities, mentorship, and a tools directory. Every entry annotated with why it is worth your time. | 1h 50m |
| 10 Templates | Six copy-paste templates with inline guidance and filled examples. | 1h 20m |
Work the four-week prep plan, which gives you a day-by-day schedule where every day produces an artefact. If you have less time, the top 10 questions and three well-measured stories will carry you further than any amount of reading. Candidates most often skip the story work and the mock interviews, and those are the two things that decide loops.
No, but you do need to judge. You will not write the retrieval pipeline, and you will decide whether the team's evaluation of it is trustworthy. The bar is being able to hold a technical conversation, challenge a design, and size a cost, which module 01 and module 02 give you. Evaluation is the one topic where an EM cannot afford to be shallow.
Four, roughly in this order: evaluation literacy (turning "is it good?" into a number and an owner), cost awareness (AI spend is an engineering decision that scales with success), security instincts about untrusted input, and the judgement to plan work whose feasibility is genuinely unknown. The self-assessment scores you against all four.
That they answer different questions. RAG changes what the model knows at request time; fine-tuning changes how it behaves. Fine-tuning does not reliably add facts and does not fix hallucination, and that misconception costs teams entire quarters. Most teams arguing about fine-tuning have a retrieval problem. The decision tree and trade-off table settles it.
Start by writing down what the team is for, because "AI team" is not a mission. Most teams building on foundation models need strong senior software engineers who think in evals, not researchers, and hiring the wrong role well is the most expensive mistake available to you. See team structures for the org models and the roles matrix for who to hire first.
In normal software, uncertainty is about effort, and you can decompose your way to an estimate. In AI work, uncertainty is about possibility: you cannot know whether a good enough answer exists until you spend money finding out. Everything else follows from that, including spikes instead of estimates, thresholds instead of done, and kill criteria agreed before the work starts.
Almost certainly use an API. Training from scratch is essentially never correct outside a foundation lab, and the differentiator is rarely the model. It is your data, your evals, and your workflow integration. Price the decision in engineer-months rather than licence fees, which is where teams get it wrong. Build vs buy vs fine-tune has the decision tree.
Start with the policy, not the seats, because if you have not chosen a tool your engineers have already chosen one and you have all of the risk and none of the learning. Then pilot with 8-15 people including a sceptic, capture a baseline first, and pair every speed metric with the quality metric that catches its abuse. The adoption playbook includes a policy template.
Contributions are welcome, from a one-line correction to a new case study. Read CONTRIBUTING.md for the style guide and the freshness review process, then open an issue to add a question, add a resource, or report outdated content. All participation is covered by our Code of Conduct.
If this saved you time, a star helps another engineering manager find it.
Released under the MIT licence.