Leadership · Episode 01 of 6
I turned a Git repo into a team OS.
I put our work, OKRs, availability, agent skills, assets and team history in one shared workspace. The practical reason was simple: a new person should not need five accounts and a tour from me to find out how the team works.
The problem
Knowledge was spread across tools and people.
We did not have a shortage of tools. We had tasks in one app, OKRs in a spreadsheet somebody owned, and the domain map in a slide deck that had not been opened since planning. Each tool was fine on its own. Together they meant that who owns this, and what did we decide? had four possible answers, plus one person’s memory.
When I took over the twelve-person studio, I wanted one place where the department’s working knowledge lived. What I built instead of buying was a departmental dashboard on top of a git repository.
The idea
Why I put it in Git.
The honest answer is that each of them models a way of working and asks you to adopt it. That is not a criticism; it is how a good product earns its keep, and for most teams the trade is worth it. It just meant that our six-field intake, the ownership matrix, the published turnaround bands and our OKR structure would each need heavy configuration, or would lose the parts that didn’t fit the template.
Git did not ask us to work like a project-management product. It gave us a place to put the way we already worked, with a history of what changed.
The system
Six kinds of working knowledge, in one place.
- Tasks and their intake records, as files, so a request and the reasoning behind it stay together.
- OKRs, in the same tree as the daily work, so a designer can see how today’s output moves a quarterly goal.
- The domain ownership matrix: primary owner, secondary, and me as the backstop.
- The team’s agent skills, versioned like anything else in the repository.
- A decision log, so a settled call doesn’t get re-litigated three months later.
- Assets, versioned in the same tree as the work they belong to.
Skills as committed artifacts
This was the part I had not planned for. Designers started building small agent skills for the tasks they repeat: a naming pass, a resize batch, a first-draft layout. Left on one laptop, those would still belong to one person and disappear when they moved on.
Committed to the repository, they become an asset the whole department can pull, run and improve on. An hour someone spent automating their own tedium is now an hour saved eleven more times.
The unexpected benefit
The bonus: we started speaking the same language.
Running the workspace on git principles put our design workflow on roughly the same rails as our engineering partners’ release architecture. That was not a goal, but it gave us a shared technical vocabulary across departments, and we lean on it more than I expected to.
Impact
The team stopped waiting for people.
Anyone can pick up unfamiliar work from documented context instead of someone else’s memory. The operating context, the domain map and the agent skills are all committed and readable, so nothing load-bearing sits only in one person’s head.
The administrative saving was real, and the least interesting part of it. What matters is that this holds equally for a new hire in their first week and for a secondary owner covering an absence, which is the subject of the next episode.