Creator’s Companion is designed with team use in mind. While the template works well for solo creators as well, it started life as our internal content planning system, which I developed from scratch to improve my team’s content-creation workflow.
Fun fact: The very reason I started using Notion back in 2018 was because I found it so useful for managing the editing process for YouTube videos.
If you’re creating content with a team, Creator’s Companion can absolutely help you do it more efficiently. In this document, I’ll share a collection of tips and practices I’ve developed through working with my own team, as well as through advising customers in our support community.
This doc is a work-in-progress.
Which Version of Creator’s Companion Should I Use?
TL;DR: If you’re managing a team, I highly recommend doing it in a standalone copy of Creator’s Companion. Ultimate Brain is designed primarly for personal use.
If you intend to use Creator’s Companion with a team, I generally don’t recommend using the combined Ultimate Brain + Creator’s Companion version of the template to do it.
Instead, I recommend using one of the standalone editions:
- Creator’s Companion: Ultimate Tasks Edition (if you need integrated task management)
- Creator’s Companion: Base (if you don’t need task management)
Note: If you purchased the UB+CC bundle, you get both of these in addition to standalone UB and the fully-integrated UB+CC template – so you can choose any version you like, and switch between them if your first choice isn’t what you want.
This is exactly what my team and I do. We use Creator’s Companion on its own for managing our content-creation process, and then I use my own, private copy of Ultimate Brain for my productivity system.
In years past, the idea of splitting things up like this frustrated me. I really want everything to be integrated; I wanted to see all my team-related content tasks in the same task manager as my personal tasks.
But I’ve come to the conclusion that Notion simply isn’t ready for this yet due to its issues around database permissions. To me, that dream of perfect integration is not worth giving up the privacy of my personal Tasks and Notes databases.
However, I have another reason for now keeping things separate: simplicity.
Creator’s Companion has a lot of features, but it’s also quite simple to use. Anyone on your team can see your active projects right on the home page. You can click a project and see the Script or Outline right away. Things are easy to find.
When you’re working with a team, this is crucial.
If you’re any shade of the type of nerd that I am (you like Notion and task management apps, you play Satisfactory, music with weird time signatures is your jam), then you’re probably fascinated by creating powerful, intricate systems to manage your life.
In your personal life, this can be fine. “Tool you enjoy” beats “Tool that is simple, but you won’t use”.
But once you add more people into the mix, things have to be simple, clearly-communicated, and consistent.
In 2025, my team and I plan on releasing more team-focused educational content and products – join the newsletter if you’d like to stay up-to-date on them!
SOPs and Process Documentation
One of the best practices you can adopt with your team is documenting processes.
A small story: In college, I spent a couple years working at the Solution Center – my school’s crack team of tech support specialists.
Every one of us was a certified, black-belt IT wizard, packing dozens of certifications under the belt, despite all of us being 18-year-old freshmen barely out of high school. There wasn’t a problem we couldn’t solve.
Emeritus professor’s Palm Pilot accidentally got baked into the department holiday party’s Bundt cake? I was there with a screen replacement kit and a dessert fork.
Ancient COBOL server on the fritz in the 9th-level basement of that old Dept of Defense building, still guarded by an old vet who never got the VE Day memo? I’m crawling in under the raised floor.
Truth be told, it always fascinated me how lucky the Solution Center got with the level of expertise in its student employees.
…alright, I might be stretching the truth ever so slightly here.
Here’s how things actually went. I show up for my interview, which takes place in a classroom. In walks a student employee, just a couple years older than me. He starts asking questions… only they’re not about computers at all.
“Name as many uses for this paperclip as you can think of.”
“How would you estimate how many jelly beans are in this glass jar?”
As it turned out, the Solution Center didn’t hire students who knew a lot about computers. They hired students who could solve problems.
As for all the highly domain-specific computer knowledge they’d need to solve actual computer problems?
It was all in our docs.
The Solution Center maintained a massive Knowledge Base (the K-B), which had a dedicated support article for every phone call, email, and hapless walk-in we’d ever handled.
In the event that the K-B didn’t have an article, the solution was on Google 99% of the time. The Solution Center hired me because I was smart enough to Google things.
But there was also a rule:
If you take a question for which there’s no K-B article, you take youself out of the phone queue afterwards and you write that article.
This is called just-in-time documentation. Solve the problem, then write the doc.
This practice ensured that the many, many student employees they hired (campus jobs have high turnover) could all more-or-less solve any problem. This was because the solution to most problems was:
- Find article
- Read article to customer
This practice of documenting common questions and processes takes extra time up-front, but over time it pays dividends. If you start doing it in your own business, you’ll see those dividends.
However! I will caution you against going overboard in this practice. It’s easy to read a story like this, get excited, and issue a pharaohonic edict to your team: “All shall be documented!”
I urge some restraint here… because you’re probably not hiring level-1 tech support monkeys straight out of high school. You’re likely working with talented writers and editors who know their craft, and who will likely be slowed down if they’re forced to write and follow checklists all day.
What I recommend is the following:
- Document with discretion. If a process seems like it would benefit from documentation, quickly create an article in the Wiki database.
- Look for common oversights and mistakes. Don’t force your editor to check a million checkboxes, but if he keeps forgetting to normalize the final mix to around -18 LUFS, quickly write up a doc about that.