The Marketing Operations Compendium

Sample Chapter 3:
The Value of a Living Playbook – Why Documentation Is a Competitive Advantage

Field Notes: The Company That Writes Everything Down First

GitLab is one of the largest fully-remote companies in the world – over 1,300 employees, more than 65 countries, publicly traded on the Nasdaq since October 2021. It’s also, by wide agreement, one of the most heavily documented companies that has ever existed. The GitLab Handbook – a single, public, searchable document covering nearly every aspect of how the company actually operates – has grown past 10,000 pages. It’s not an employee manual gathering dust in a folder nobody opens. Sid Sijbrandij, GitLab’s co-founder and CEO, personally worked on the earliest versions of it, including the section that explains how to actually use it, so a new hire with zero context on the company’s culture could open the handbook on day one and start contributing immediately.

As the company scaled, “everyone documents things” stopped being enough on its own, and in 2019 GitLab created something unusual: a role called Head of Remote, held by a person named Darren Murph, whose job was explicitly to keep the culture of documentation strong as the company kept growing. Murph has said the whole philosophy comes down to one idea: in an environment without shared office chatter or impromptu whiteboard sessions, context has to be made explicit, in writing, or it simply doesn’t exist for the people who weren’t in the room.

The specific discipline worth borrowing is a different habit than most teams have: at GitLab, the norm is to write something down before a meeting happens, not to summarize it afterward. A decision, a proposal, a status update – it goes into the handbook first, in writing, so the meeting (if one’s even still needed) starts from a shared, explicit understanding instead of everyone re-explaining context out loud. Most teams do the opposite – meet first, maybe write something down after, if someone remembers to. That single reversal is most of what separates a real documentation culture from a well-intentioned wiki nobody actually reads.

You don’t have to be a fully remote company for this to matter. Every MarkOps team, whether everyone’s in one building or scattered across time zones, has the exact same underlying problem GitLab was solving for: decisions get made in a room, or a Slack thread, or a hallway conversation, and the reasoning behind them lives only in the memory of whoever was there. Documentation is how that reasoning survives past the meeting – and, just as importantly, how a disagreement six months later gets settled by pointing at a page instead of re-litigating a decision nobody fully remembers making.

Why It Cuts the Argument Short

Consider a scenario worth sitting with, because it’s the kind of thing that happens constantly and quietly in MarkOps teams without documentation, and almost never happens in teams with it. A Sales leader challenges the MQL scoring threshold in a QBR – “why does a VP title get 20 points and a Director only get 15, that doesn’t match how we actually sell.” Without a documented decision trail – what was decided, who was in the room, what data justified it, when it was last reviewed – the same challenge gets a completely different answer: “here’s the page, here’s the closed-won correlation data that set those values, here’s who signed off, and here’s when we’re scheduled to revisit it.” The disagreement doesn’t disappear, but it stops being a fight about who remembers what, and starts being a fact-based conversation about whether the data still holds up. That’s the entire value of documentation in one comparison – not that it prevents disagreement, but that it changes what the disagreement is actually about.

The Documentation Site: Where All of This Actually Lives

A naming convention, a scoring model, a data dictionary – none of it holds up if the only place it exists is in one person’s head or scattered across old Slack threads. Marketing Operations touches almost everything else in this book: the data model, the processes other teams follow, the definitions everyone reports against, the tracking implementation every dashboard depends on. If none of that is written down somewhere durable, every new hire, every audit, and every cross-functional disagreement starts completely from zero, every single time.

The goal isn’t just writing things down, though. It’s that anyone – a new hire, a Sales rep, an auditor – can be pointed to one page and get a complete, standalone answer: not just what the current rule is, but why, who decided it, and when it was last confirmed. A page that only states the rule gets re-litigated every time someone disagrees with the outcome. A page that also shows the decision trail settles the question for good, because the reasoning is right there instead of trapped in a meeting nobody else was in.

Why It Matters

• Eliminates key-person risk – the answer to “why does our MQL scoring work this way” shouldn’t depend on one specific person being in the room.
• Cuts onboarding time – new hires and contractors can self-serve instead of interrupting the team with questions that already have an answer written down somewhere.
• Ends repeated re-litigation – a decision documented with its rationale doesn’t get argued from scratch every time someone questions it months later.
• Gives every other framework in this book a permanent home – the data dictionary, metric definitions, and brand guidelines are all only as useful as people’s ability to actually find them.
• Supports audits and compliance reviews – a documented system is a defensible one.

Choosing a Platform

This matters less than picking one and actually committing to it, but the trade-offs are worth knowing before you decide. SharePoint is the default for organizations already deep in the Microsoft ecosystem – strong permissions control, easy for IT to govern, but search and everyday editing tend to feel clunkier than purpose-built alternatives. Confluence is the common choice for teams already living in Jira and the broader Atlassian suite – strong structure and version history, but it can get bureaucratic-feeling if every page requires the same heavyweight template. Notion has become the default for younger, faster-moving teams – flexible, fast to edit, genuinely pleasant to search, but its flexibility can turn into inconsistency without someone actively enforcing structure, the same drift problem this whole chapter is about. None of these is objectively correct. The wrong choice, chosen deliberately and used consistently, beats the right choice nobody actually updates.

What Good Looks Like

• A searchable, versioned wiki that covers the data model, process runbooks, metric definitions, brand reference, and tracking implementation – not just one of these in isolation.
• Every page is a complete, standalone answer: current rule, reasoning, who was involved, and when it was last reviewed.
• Every non-trivial decision – a scoring threshold change, an attribution model choice, a taxonomy revision – gets logged with what was decided, why, and who signed off, so the reasoning survives long after the meeting that made it is forgotten.
• Pages are owned and reviewed on a set cadence, not written once at launch and left to quietly go stale.
• Decisions get written down before the meeting where they’ll be discussed, GitLab-style, not reconstructed from memory afterward – the habit that actually separates a living playbook from a wiki nobody trusts.

Documentation Needs an Owner, Not Just an Intention

One real, well-documented pattern worth planning around: “everyone’s responsible for documentation” tends to work fine at small scale and quietly fail as a team grows, which is the whole reason GitLab eventually created a dedicated role for it rather than continuing to treat it as a diffuse shared duty. You don’t need a Head of Remote-equivalent role in a MarkOps team of five. But the underlying lesson holds at any size: assign an actual named owner to the documentation site itself, distinct from the owners of individual pages, whose job is to notice when it’s going stale, chase down updates, and keep the whole thing usable – not just hope it stays that way because everyone individually means well.

Every domain below already has canonical content living somewhere in this book or in a MarkOps-owned system – the documentation site’s job is to make each one findable, with a page that fully explains itself, decisions included.

Documentation Domain	Canonical Source	Page Owner	Last Updated	Status
Data Model & Data Dictionary	Chapter 4			☐ Draft ☐ Live
Metric & KPI Definitions	Appendix A			☐ Draft ☐ Live
Activity Type & Channel Definitions	Appendix A			☐ Draft ☐ Live
Tracking & Tagging Implementation (UTMs, pixels, tag audit)	Chapter 13			☐ Draft ☐ Live
Process Runbooks (campaign builds, lead routing, scoring updates)	Chapters 5, 11, 12			☐ Draft ☐ Live
Tech Stack & Integration Map	Chapter 2			☐ Draft ☐ Live
Brand & Creative Reference	Chapter 24			☐ Draft ☐ Live
Compliance & Consent Documentation	Chapter 19			☐ Draft ☐ Live
Decision Log (why, not just what)	New – see below			☐ Draft ☐ Live

Documentation Coverage Tracker

Page / Runbook	Priority	Owner	Status
Data Dictionary	Critical		☐ Draft ☐ Live
Metric & KPI Glossary	Critical		☐ Draft ☐ Live
Campaign Build Runbook	High		☐ Draft ☐ Live
Lead Routing & Scoring Runbook	High		☐ Draft ☐ Live
Tech Stack & Integration Map	High		☐ Draft ☐ Live
Brand Quick Reference	Medium		☐ Draft ☐ Live
Decision Log	High		☐ Draft ☐ Live
Onboarding Guide for New MarkOps Hires	Medium		☐ Draft ☐ Live

The AI Layer

A documentation site is only as useful as how fast someone can actually get an answer out of it, and that’s exactly where AI changes this chapter’s whole argument from “write things down” to “write things down so an assistant can actually surface them.”

Picture the real payoff: a new MarkOps hire asks, in plain language, “how do we define MQL?” – and instead of digging through pages or asking around, an AI assistant trained on the documentation site returns the approved definition, the decision history behind it, who owns it, and when it was last reviewed. That’s the Decision Log from earlier in this chapter, made instantly searchable instead of just theoretically available. The same AI layer can also do something no static wiki can: actively flag pages that reference a retired tool, contradict a more recent decision, or haven’t been reviewed in the window this chapter’s Ownership & Status table calls for – catching documentation drift before a new hire trips over it.

None of this replaces the actual discipline of writing things down in the first place, GitLab-style, before the meeting rather than after. It’s what makes that discipline pay off immediately instead of only paying off for whoever happens to already know where to look.

Getting started, concretely. This doesn’t require a custom-built assistant to start – most AI chat tools can already do a useful version of this if you feed them your documentation directly.

If your documentation lives somewhere exportable (Confluence, Notion, SharePoint), export the relevant pages as text or PDF and upload them into an AI tool that supports file uploads, then ask something like:

“Here’s our team’s documentation on [MQL definitions / routing rules / scoring criteria]: [paste or attach]. A new team member is asking how we define an MQL. Answer their question using only what’s in this documentation, and flag anywhere the documentation seems incomplete, contradictory, or out of date.”

That last instruction matters as much as the answer itself – it’s what surfaces the stale or conflicting pages this chapter already warns about. Once this is useful enough to want it always available, the more durable version is a dedicated AI workspace or custom assistant with ongoing access to your documentation site (most major AI platforms now offer this as a feature), so anyone on the team can ask questions directly instead of you running the export-and-paste version by hand each time.

Try This Thursday

Build a report pulling every row in the Documentation Coverage Tracker where “Last Reviewed” is older than its defined review cadence. This report should come back empty – every row overdue is a page one missed decision-log entry away from becoming precisely the kind of unwinnable argument this chapter opened with.

Sources: The GitLab Handbook and GitLab’s handbook-first culture, corroborated across GitLab’s own public handbook (handbook.gitlab.com), company history documentation, and independent reporting on Darren Murph’s role as Head of Remote (created 2019) and Sid Sijbrandij’s early involvement in building the handbook.