A branch per idea
Teaching designers and product managers to work the way engineers already do. I have taught a lot of design curricula. This is the one that changes how a team argues.
The interesting problem now is not the repository. It is teaching people to work in it, and this is the part of the job I am best at.
A designer who can generate a working interface can also generate a great deal of code nobody asked for. So the first question engineering leaders ask is who reviews all this. It is the right question and it deserves a confident answer.
The answer is boring, deliberately. Work arrives as a pull request and gets reviewed before it merges. Designers and product managers meet the same gate as everyone else. Larger efforts move in passes: a first pass, a second pass, a cleanup pass. We did not need a new governance model. We needed the existing one to cover more people.
Every proposal I have seen for a special review track for design-authored work has been a way of saying we do not really trust this, without having to say it out loud. I have declined those proposals here and I would decline them again.
What I am actually teaching is not Git commands. I wrote a ten-week UX curriculum years ago and trained a couple of hundred designers through it, and the thing that makes a concept land is never the tool — it is finding the thing people already understand and naming it.
A branch is a cheap place to be wrong. That is the whole pitch, and it lands every time, because it is what a sketchbook is. You are not proposing a change to the product. You are making a copy where the change is already true, and anyone can open the copy and click around in it before a single decision gets made.
The pattern settling in: a prototype repository per feature, a branch per idea inside it, a spec file per branch saying what that branch is arguing for. The spec file does more work than I expected — it gives a branch a thesis. Without one, a branch is a pile of divergent screens.
And here is what it does to a team, which is the part I care about most. Disagreement gets cheap. Two designers with different instincts about a flow no longer debate it in a meeting with two drawings, where the outcome is decided by seniority or stamina. They each take a branch, build it, and we look at both running. That conversation takes an afternoon and ends in evidence.
The hardest part for designers is not branching. It is that a pull request is a proposal, and someone may decline it, and that is ordinary rather than a verdict on your competence. Engineers absorbed that years ago. Design culture routes around disagreement far more than it admits, and this practice quietly fixes that.
Where I am taking this: a design organisation that argues in branches instead of in meetings, where the most junior person can make their case by building it, and where being wrong in public twice a week is completely unremarkable. That is a better place to work and it produces better software. I have wanted to build it for most of my career and this is the first time I have had the materials.