In the beginning, we're keeping a single gatekeeper: me. I'm the only one who can merge PRs into the main branch. Marketers aren't familiar with GitHub, so accidental mistakes happen (we had someone unknowingly submit a PR that deleted a bunch of files). People also aren't yet familiar with the folder structure or where files should live. And I'm learning that you actually want fewer of the right files. Too many and they start competing with one another for clarity and priority. A central gatekeeper catches all of that.
That said, it's not sustainable. As the team gets more comfortable (and let me be clear, changing people's way of working is by far the biggest challenge), you want to start letting others take on that role. I've seen two models for this. The first is simple peer review: any PR requires at least one other person to approve it before it merges, while I keep the ability to push directly during the building phase. The second is folder-based ownership, where function leads own the folders in their domain. For example, our Head of Product Marketing gatekeeps the positioning and messaging files. That's a bit more involved, but still nowhere near the complexity of an engineering setup.
Thanks, Bruno! Such a detailed answer - single gatekeeper makes sense until everyone gets the hang of PRs etc. I guess the more a team grows (together with campaign and PR output), the greater the need for decentralized gatekeeping will be.
A practical follow-up question: is your propose folder structure, where would designers or marketing contractors would live? A separate project folder under /projects?
Yep. Our designer mostly lives under /projects. We create a ‘creative assets’ folder under each specific project where her deliverables for each project go.
We’re experimenting with adding context files that help Claude go a bit further on design for us, but haven’t found anything where the quality of deliverable is good enough. Maybe now after last weeks big release; Claude Design. Need to experiment.
Regarding contractors, it depends what kind of job they need to perform and what information they need or are allowed to have access to.
Super read - and thank you for the detail provided.
Question re: Step 4: Review through pull requests - do you see a single gatekeeper for this or multiple ones?
I'm trying to draw analogies from how ENG teams work on this.
Great question, and a super relevant one.
In the beginning, we're keeping a single gatekeeper: me. I'm the only one who can merge PRs into the main branch. Marketers aren't familiar with GitHub, so accidental mistakes happen (we had someone unknowingly submit a PR that deleted a bunch of files). People also aren't yet familiar with the folder structure or where files should live. And I'm learning that you actually want fewer of the right files. Too many and they start competing with one another for clarity and priority. A central gatekeeper catches all of that.
That said, it's not sustainable. As the team gets more comfortable (and let me be clear, changing people's way of working is by far the biggest challenge), you want to start letting others take on that role. I've seen two models for this. The first is simple peer review: any PR requires at least one other person to approve it before it merges, while I keep the ability to push directly during the building phase. The second is folder-based ownership, where function leads own the folders in their domain. For example, our Head of Product Marketing gatekeeps the positioning and messaging files. That's a bit more involved, but still nowhere near the complexity of an engineering setup.
Thanks, Bruno! Such a detailed answer - single gatekeeper makes sense until everyone gets the hang of PRs etc. I guess the more a team grows (together with campaign and PR output), the greater the need for decentralized gatekeeping will be.
A practical follow-up question: is your propose folder structure, where would designers or marketing contractors would live? A separate project folder under /projects?
Yep. Our designer mostly lives under /projects. We create a ‘creative assets’ folder under each specific project where her deliverables for each project go.
We’re experimenting with adding context files that help Claude go a bit further on design for us, but haven’t found anything where the quality of deliverable is good enough. Maybe now after last weeks big release; Claude Design. Need to experiment.
Regarding contractors, it depends what kind of job they need to perform and what information they need or are allowed to have access to.