Teaching designers and PMs to build turned out to be 2 problems with a shared title. Splitting them changed the whole plan.
My engineering partner and I have spent 2 weeks circling one question: how do we get designers and PMs building in the codebase with confidence? The first instinct is a course, and I understand the appeal, because a course feels like progress you can point to and a line you can put in a plan. We also have a library of course content nobody finishes, and I’d hate for something this important to join it.
The data backs the hesitation. In Designer Fund and Foundation Capital’s AI in Design 2026 study, peer learning more than tripled year over year, from 24% to 80% of designers, while learning from leadership’s recommendations dropped by half, and designers at companies with a culture of tinkering were 2x as likely to say they feel more creative and capable, even with a higher bar. People are learning this from each other, on their own work.
What I’m seeing on my own team is that “teach people to build” is 2 gaps bundled together, and each needs a different fix. The first is a vocabulary gap: git, branch, repository, pull request. One primer, recorded by one of your own engineers against your own repo so the examples are yours instead of a stranger’s todo app, and it’s closed. The second is a judgment gap: when do you prototype, when do you pull a branch, when do you tap your engineering partner, and when do you stop? No course teaches that one, and it only forms on live tickets, in your own codebase, with someone experienced beside you while you read what came back.
The vocabulary gap is a 90-minute problem, and the judgment gap is an apprenticeship.
So the pilot we’re standing up is a formula of sorts: a primer as pre-work + 1 live ticket on a branch + an engineer paired through the PR review + a demo at the end instead of a certificate. The primer comes from engineering, a designer sits beside that engineer as the voice on when to prototype versus when to hand off (a call an engineer can’t teach alone), and the tickets come from a board a designer on my team already stocked, which is the next article.
The human side deserves the most care. People are going to miss, and the first “not the right approach” on a PR can’t become the thing that makes someone stop trying, so the pairing matters as much as the ticket. And some of our colleagues didn’t sign up to build at all; they became PMs or designers precisely because they wanted a different craft. I think leaders owe those folks clarity about their path, not a syllabus, and I’d rather say that out loud now than let anyone wonder in silence.