I gave an internal talk last quarter on how our team handles background jobs. It went fine, a few people asked good questions, and then it evaporated the way internal talks do. The slides sat in a folder. New hires who joined a month later got a link to a deck with no context, which is another way of saying they got nothing. I kept meaning to record a proper version and kept not doing it, because "record a proper version" meant booking time, setting up, and editing, and I write backend code, not video.
So I tried the lazy-engineer approach: feed the material I already had into a tool and see what came out. This is a short writeup of that, including where it fell short, because I would have wanted that before spending an afternoon on it.
The problem with slides-as-documentation
Slides are a terrible standalone artifact. They are built to support a person talking, so without the person they are a series of bullet points missing their most important layer. A written doc is better for reference but worse for a first pass, because nobody learns a system by reading a wall of prose top to bottom. The thing that actually onboards someone is watching a walkthrough once, at their own pace, then keeping it around to re-scan. That is exactly the artifact I never had time to make.
What I actually did
I used an AI lecture video maker and gave it what I already had: the slide deck plus my speaker notes as text. It drafted an outline, laid out the scenes, and generated the narration. The part I did not expect to care about but ended up using: you set a narrative style and a level of detail, and you can name the audience. I set it to explanatory, comprehensive, audience "new backend engineer," and the script came out teaching the material rather than just reading the bullets.
A few things that mattered for my use case. There are built-in presenters and you can generate an avatar from a single photo, so I did not have to be on camera, which is the main reason this never happened before. And because the input was text I already had, fixing a wrong explanation meant editing the text, not re-recording a take. For someone who iterates on code all day, editing a script and regenerating felt normal in a way that reshooting never would.
Where it fell short
I said I would be honest, so: the presenter reads as slightly synthetic if you watch closely. For internal training I do not care; for something customer-facing where a real person builds trust, I would film myself. It is also much better at conceptual and procedural explanation than at anything that needs live screen interaction. When I wanted to show an actual debugging session in the terminal, a real screen capture was the right tool, not this. And the output is only as clear as your input. My first pass produced a mediocre video because my speaker notes were sloppy; once I tightened the notes, the video got noticeably better. The tool does not do your thinking for you.
Was it worth it
For turning existing talk material into reusable onboarding, yes, clearly. The specific win is that it collapsed a task I would never actually do (produce a polished video from scratch) into one I would (feed in notes, review, regenerate). Our new hires now get the background-jobs walkthrough as a video instead of an orphaned deck, and I did not touch a camera or a timeline.
If you have a folder of talks or internal decks that died the moment they were presented, that is the pile worth pointing at this. Take the one thing people keep asking you to re-explain, run it through a free tier from the notes you already have, and see if the version that comes out is good enough to hand to the next person who asks. For me it was.
Posted by a backend engineer who writes about developer experience, onboarding, and internal tooling.
Top comments (0)