A shared repo is not a shared way of working

I saw a post this week arguing that every marketing team will run from a shared repository next year, probably GitHub or Notion, with campaigns, ICPs, brand guidance and the rest of the team’s context all sitting in one place for AI tools to use.

I understand the appeal because I have effectively done this for myself.

My own Editorial Intelligence work now runs from repositories. The published site, frameworks, working methods, research notes, decisions and a lot of the context that lets different AI systems pick up the work are all maintained there. I can point ChatGPT or Claude at durable project state rather than reconstructing everything from a chat history. I can see what changed, what is current and what other work an argument connects to.

It has made AI much more useful. It has also made me much less convinced that the obvious next step is simply to give every marketing team a shared repo. The repository is the easy part; the harder part is turning it into somewhere people actually work.

A personal system is not a team system

When I maintain my own repository, a lot of difficult questions disappear because the person making the decisions is also the person doing the maintenance.

I know what deserves to be preserved. I know which document is canonical. I know whether a note is an observation, an established position or something I changed my mind about three weeks ago. I know why one file matters and another is historical debris.

The system can be opinionated because the opinion is mine.

A team changes the problem immediately.

Who decides what belongs in the shared context? Who removes something that is no longer true? What happens when product marketing and sales have different definitions of the ICP? Which campaign deck is the actual strategy and which is just the version somebody presented to leadership? Does a customer quote become reusable evidence, or does it remain specific to the piece of work it came from?

A repository can store every answer, but it cannot decide which answer should win. That is an operating model problem rather than a storage problem.

GitHub works for me partly because I am willing to use GitHub

There is also a fairly obvious adoption problem.

I like working in GitHub now. I like version history, explicit files, commits and the fact that the system makes me decide what is current. I have become comfortable treating prose and knowledge more like code.

Most marketers do not work that way.

That is not a criticism of marketers. GitHub was built around software development, and its basic mental model still reflects that. Repositories, branches, commits, pull requests and Markdown are normal concepts if you have spent years around engineering. They are not normal concepts for somebody whose working environment is PowerPoint, Teams, Google Docs, SharePoint, Notion or a CMS.

You can train people. You can build friendlier interfaces. AI itself can hide some of the mechanics.

But if the knowledge system requires everybody in the marketing organisation to adopt a developer-shaped way of working before it becomes useful, the adoption problem is already substantial.

This is why I wrote in Why every company needs a GitHub for knowledge that the important thing is not GitHub itself. It is the discipline GitHub enforces: a canonical source, visible history, reviewed change and connected knowledge.

The platform is negotiable.

The discipline is not.

The difficult bit is contribution

A lot of internal knowledge systems are excellent at reading and terrible at contribution.

Somebody sets up a beautiful Notion workspace. Everyone agrees it would be useful. A few people add material during the first month. Then actual work resumes.

The campaign gets launched. The new research sits in a deck. A useful customer insight stays in a Teams thread. Someone changes the positioning during a meeting but nobody updates the canonical page. Six months later the knowledge base still exists, but the organisation has quietly stopped trusting it.

This is the failure mode I worry about more than whether a company chooses GitHub or Notion.

A shared repository only becomes valuable if new work reliably improves it.

That means the act of publishing a campaign, finishing research or changing a strategic position has to include a small but real knowledge-maintenance step. What did we learn? What changed? Which existing guidance is now wrong? What should the next person inherit?

If that process sits outside normal work, it will eventually lose. People are already busy, so the knowledge system has to be part of delivery rather than an additional civic duty performed after delivery.

AI can make a stale repository more dangerous

There is another reason this matters now.

Before AI, an outdated internal wiki was irritating. People ignored it and asked somebody who knew the answer.

AI can make stale knowledge much more active.

If the organisation connects agents to a shared repository, those agents can retrieve the wrong ICP, the old product claim or the guidance that was superseded six months ago and reproduce it across dozens of tasks.

The same leverage that makes a maintained repository valuable makes an unmaintained one risky.

This is why I keep coming back to judgement as infrastructure. The useful knowledge layer is not simply a pile of documents that AI can access. Somebody has to own the quality of what the system is allowed to treat as true.

That means provenance, dates, ownership, review and occasionally deletion.

It also means accepting that not every piece of team context should become permanent organisational memory.

Small teams have an advantage here

This is where I think the shared-repo idea becomes much more plausible.

A small team with similar working habits, high trust and a clear owner can absolutely run this way. In some cases it probably should.

The same people are close enough to the work to agree what is current. There are fewer competing systems. Changes travel quickly. The person building the repository can usually see when the team has stopped using it and fix the workflow.

That becomes harder as the organisation grows.

The difficulty is not just more documents. It is more interpretations, more permissions, more specialist systems, more political ownership and more legitimate reasons for different teams to see the same thing differently.

At that point, “one shared repo containing all marketing context” stops sounding like a tooling decision and starts sounding like an organisational design project. That does not make it a bad idea; it means the work is larger than setup.

The interface probably matters more than the repository

I suspect the long-term answer is that most people will not interact with the underlying knowledge layer directly.

The source of truth might be GitHub, SharePoint, Notion, a structured database or some combination of them. Most employees may experience it through AI.

They ask: what is the current position on this market? Which customer evidence supports it? What did we learn from the last campaign? Has this claim been approved? What changed since the last version?

The AI becomes the interface. That can make repository-style discipline much more accessible because the user no longer needs to know where every file lives or how the versioning works underneath, but it makes the maintenance problem even more important.

A friendly interface can hide complexity from the person using the system. It cannot remove the need for somebody to govern the complexity behind it.

I would not start by migrating everything

If I were trying to introduce this inside a marketing team, I would start much smaller than “put all our marketing context in a repo”.

Pick one recurring problem.

Perhaps customer evidence keeps getting lost. Or campaign learnings disappear once the campaign closes. Or everybody keeps asking for the latest messaging. Or three people regularly recreate the same audience context.

Create one canonical place for that problem.

Make it genuinely easier to use than the existing behaviour. Give somebody responsibility for maintaining it. Connect an AI workflow to it if that improves retrieval. Then see whether the next piece of work actually starts further ahead.

If it does, expand.

That is much closer to how my own system developed. I did not sit down and decide to build an operating system for everything I know. I kept solving specific continuity problems, then noticed that the pieces were becoming a system.

Shared memory requires shared behaviour

I think the original shared-repo argument is directionally right.

Marketing teams do need better shared context. AI makes scattered documents and private knowledge more expensive because good tools can only work with what they can reliably access and understand. A maintained source of truth can reduce duplicated research, improve briefs and make every new campaign start from more of what the organisation already knows.

But the phrase “shared repo” makes the change sound more technical than it is.

The repository is storage, structure and history.

The operating model is the people deciding what becomes knowledge, who is allowed to change it, when it needs review, how it connects to live work and what happens when two parts of the organisation disagree.

I can run my own work from GitHub because I am simultaneously the user, editor, maintainer and governance layer. A marketing team has to distribute those responsibilities without making the system so cumbersome that everybody retreats to the old way of working. That is the real implementation challenge.

The future may well involve shared repositories behind marketing work. But the teams that make them useful will not be the ones that set them up fastest. They will be the ones that turn shared memory into shared behaviour.