I ran developer education at Netflix for close to five years, from October 2019 to August 2024, for an engineering population of several thousand.
My focus was on getting new engineers productive, and re-teaching the engineers already there every time a migration or a new platform changed how the work got done. In practice that meant curriculum, live sessions, onboarding, documentation, communities, and the tools that maximized everyone's time.
When a platform changes, the org does not get slower because the new thing is worse. It gets slower because several thousand people have to relearn a workflow at the same time, and almost nobody plans for that. The dip is predictable, and it is shorter when someone scopes the education work before cutover.
The problem this work solves
The first failure mode is the obvious one. A new engineer joins, gets pointed at pages several teams have edited in different directions, and spends their first weeks reconstructing a path that should have already existed.
The second failure mode is more expensive and gets far less attention: a tenured engineer asked to migrate to something nobody ever taught them. They are already productive, so nothing looks broken from the outside. What happens is that a strong engineer quietly slows down, works around the new system instead of with it, and forms an opinion about the platform that takes a long time to undo. Multiply that across an org and the migration costs far more than the technical work suggested.
How I ran it
- Segment the audience before writing a single slide. A new grad, a tenured backend engineer, and a data practitioner do not need the same course.
- Ship one universal baseline, then add role-tailored depth on top of it. Everyone gets the same short foundation so the company shares a vocabulary. Depth splits by role after that, which also keeps the hand-built material narrow enough to maintain.
- Deliver hub and spoke. A central team cannot teach every org and should not try. The hub builds and maintains the material, and local advocates deliver it inside their own teams, because they know where their people will get stuck.
- Evaluate with the Kirkpatrick model. The point is to judge the program instead of assuming it works. Level 1 satisfaction is the easiest thing to collect and the least informative. A 4.9 out of 5.0 tells you the session was well run, not that anyone changed how they work on Monday. Level 3, behavior change, is what matters, and it is the level nearly everyone skips because observing it is work.
- Treat documentation as a product, with an owner, a health score, and a feedback path. Docs without an owner do not stay accurate, and docs without a feedback path fail silently: the reader who spots an error works around it and moves on.
Project Examples
Rebuilding engineer onboarding end to end
I rebuilt onboarding whole instead of patching pieces. I rewrote the live engineering bootcamp with matching learner and facilitator guides so anyone could run it, and consolidated scattered resources into one onboarding site with a course catalog for new grads. I recorded a computer setup walkthrough, since setup was where new hires stalled first, and standardized the onboarding document set.
I automated the manual overhead that came with running it, and wrote the strategy for operating it, so the program did not depend on me remembering how it worked.
A course portfolio built to order
Over nearly five years I built and taught 30+ custom developer training courses, averaging 4.9 out of 5.0 in learner satisfaction. Subjects came from what engineering was struggling with: SDLC 101 on the software development lifecycle, Spring Boot 101 on backend framework fundamentals, Being On-Call and Incident Management, and How We Code Explained, which covered how the company really writes and ships code and which everyone assumed was written down somewhere and was not.
I also ran hackathons and documentation sprints, including Stackathon, the Spring Boot hackathons, and Docathon, and built the Learning Developer Toolkit so other people could build a course without starting from a blank page.
Upskilling for migrations and new platforms
What works is putting enablement in the migration plan as its own workstream with its own timeline and owner, teaching the new workflow rather than the new tool, and shipping the material before cutover, not in response to the support queue afterward. People do not need a tour of an interface. They need to know how to do the thing they did yesterday. The cost showed up as a support queue and slower delivery rather than as a line item.
Teaching a brand new category of tool
When AI coding assistants arrived there was no curriculum anywhere to copy. I led the adoption and enterprise rollout of GitHub Copilot, OpenAI, Gemini, and the internal GenAI Platform across engineering, which meant teaching four moving targets at once. I wrote the material from scratch and revised it constantly, because the tools changed underneath the courses faster than I could review them.
Later I ran hands-on labs on agentic coding tools for program managers and people managers, who are not developers. Teaching non-developers a developer tool is a different problem than it looks. The blocker is not syntax. It is the fear of breaking something, so the lab has to prove early that this is a safe space to explore.
Alongside the courses I wrote the guides and best practices people actually reached for, and built proofs of concept so the advice came with something working attached to it.
Documentation as a product
Documentation decays quietly, and nobody files a ticket about it. I gave docs an owner and a Documentation Health Score, which turned a vague complaint into a list of specific pages. I added a feedback mechanism on every page so readers could report a problem where they found it, and ran a communication plan and a newsletter so people knew what had changed.
Communities that outlive a course
Courses expire. The people who took them do not. I set up communities of practice, ran a mentorship pilot, built the DevEd volunteer instructor program for engineers who wanted to teach, and started Engineers Outloud, an internal speaker series. I also founded the GenAI Knowledge Series, a community for people working with generative AI that reached 900+ members and later became a formal program in the platform org I moved to.
Tools built to optimize time
Every recurring manual task in this program was a course I could not build that quarter. I built a tool that turned a recorded session into structured written notes, so nobody had to rewatch the recording. I automated a weekly digest of a busy chat channel, and built a bot that collected structured feedback from pilot participants instead of chasing them individually. I also built a GenAI documentation assistant, so people could ask a question instead of guessing which manual held the answer.
Skills
Technical program management · Developer enablement · Developer education · GenAI and AI tooling enablement · AI coding assistant rollout · Instructional design · Curriculum development · Program evaluation (Kirkpatrick) · Onboarding design · Documentation strategy · Community building · Cross-functional stakeholder management (Engineering, Product, Legal, Security) · Node.js · React · Python · Cloud
