Again, amazing to be seeking feedback (or open to it). I'm at minute 13 (code review management / bookmarks, etc.), and will give my feedback from there:
https://www.essayselevate.com/post/how-to-structure-a-winnin...
"SCAR", which I learned as "Situation, Consequences, Actions, Results" but the above essay will let you go deeper.
Bad: "Two people stood up there, said a few words, and then everybody had cake and went home"
Good: "The situation was... it was a beautiful venue, everybody was dressed nicely, there was music, a slow walk. What these two people were doing was going to bond them together for the rest of their life (or until they had an ugly divorce, whichever came first). They gave a great speech that they'd been practicing all morning in the mirror, gave each other a kiss and a ring to seal the deal, then everyone had cake, danced, and went home tired but happy!"
...this is obviously (hopefully!) exaggerated, and there's a whole bunch more fluffery in the 2nd than the first but imagine this:
1) The situation is that google on perforce or git was dog slow and blah blah not designed for the scale of our monorepo, etc.
2) The consequences was reduced development velocity and increased errors in prod b/c people were trying to bypass CI/CD steps b/c everything was so slow
3) We introduced CitC / Cloud Commits, and => {your technical brilliance described here...}
4) ...and the result was butterflies and rainbows, and here's a graph that shows the production incident rates going down and the changelist rates going up after we GA'd `jj` on linux.
5) The End!
As it stands, much of the presentation is #3 but you're not even giving yourself the credit of bragging about how you discovered the problem (challenge) and the cleverness that went in to inventing your solution.
re: bookmarks:
"We often had people mailing around patches -or- Sometimes PR's were tough to review due to ... -or- I've always wanted an easy way to ..."
=> "Without good bookmark support [adoption would suffer|it would be seen as a step back|collaboration wasn't instant|...]"
=> "So I built bookmarks for `jj`, they work like ..., and solves most of the problem"
=> "It's [better|faster|cheaper|quicker|more fun] than [GitHub|Our Old System|getting yelled at by Linus Torvalds|...etc..."
=> "The IMPACT of bookmarks is: ..." => "It IMPACTED the technical bits here: ..." => "The USER IMPACT is: ..." => "...and finally the business gets: ..." => "What a powerful impact!"
I'd _LOVE_ to see you run a breakdown of any kindof arbitrary slide in the deck and post a deconstruction in this format as kindof a practice/workshop.
It's very OK if (at first) it's pretty mechanical! It's just super-helpful to basically "disassemble" what you're trying to talk about in this mechanical way, and then you can take the proper bits and put them back together.
Situation => Consequences (or Challenges) => Actions => Results => IMPACT!
If you just string a bunch of technical details or technical choices together, you're missing the whole "compelling story" that exists. Even if you just "set the stage" with a single "Situation" slide at the beginning, and a single "Results/Impact" slide at the end... each interior "loop iteration" can be easily set up with a short "Challenge/Consequence" & "Action/Detail/Choice"
"Git + Monorepo was yuck!" => [ "Slow FS" + "CitC" ] => [ "Big Checkouts" + "VFS" ] => [ "Branches?" + "Chose `cp $FILES branches/*` ; Feedback?" ] => "JJ has been well accepted and has a bright future, inside and outside of el-goog!"