How do I know if my team runs on heroics instead of standards?

Look at what happens the week you are out. If quality dips, deadlines slip, or someone quietly works a weekend to cover the gap, the standard lived in a person, not in the system. A team on real standards produces work at the same bar whether the lead is present, on a plane, or on vacation. The absence test is the only honest one.

Does writing down standards kill creativity?

No, it protects the part worth protecting. A written standard handles the settled questions, file setup, export specs, the non-negotiables, so nobody spends judgment on them twice. That frees the real creative attention for the choices that actually deserve it. Rules on the mechanical layer buy you room on the layer where taste matters.

Where do I start if nothing is written down?

Start with the failure you have seen twice. Pick the mistake that keeps recurring, write the smallest rule that prevents it, and wire it into the template or checklist where the work already happens. One rule that sticks beats a handbook nobody opens. Build the system out of scars, not from a blank page.

Standards That Travel: Building a Creative Team That Holds Up When You Leave the Room by Tyler Garner

Here is the thing nobody puts on the recruiting page. A lot of creative quality, maybe most of it, runs on one person deciding at eleven at night that the work is not good enough yet and staying to fix it. I have been that person. I have led teams full of that person. For a handful of projects, it is the best feeling in the work, the pride of rescuing something that was about to ship soft. Then the count goes from a handful to forty at once, and the same instinct that made the work great becomes the reason it cannot scale. You cannot stay late on forty things. Nobody can.

I learned this the slow way, first as a producer and editor who could personally carry a piece over the line, then as a leader who suddenly could not touch most of the work at all. The lesson was not that heroics are bad. The lesson was that heroics are a symptom. Every all-nighter that saves a launch is telling you the standard was not built into the system, so a human had to become the system for one more night.

Why do heroics stop working as a team grows?

Because a hero is a single point of failure, and single points of failure do not survive scale. When quality depends on one person catching the problem, you have quietly capped your output at whatever that one person can personally review. Past that line the misses do not announce themselves. They ship. The work gets a little worse in a hundred small ways nobody had the bandwidth to catch.

The math is unforgiving. One reviewer can hold the bar on five projects and maybe fake it on ten. At thirty, the reviewer is triaging, not reviewing, choosing which fires to reach and letting the rest burn a little. The team reads that as the standard dropping, and they are right. What actually dropped was the coverage of a system that was never a system, just a person working harder than the work allowed.

What does it mean for a standard to travel?

A standard travels when it produces the same quality without the person who set it in the room. That means it lives somewhere durable, in the template, the default settings, the checklist, the export preset, the shared reference of what good looks like next to what off looks like. If the standard only exists as taste in one leader's head, it stays in that head and dies at the edge of that leader's attention.

Traveling is the whole test. A note you give once and have to give again next month did not travel, it echoed. The goal is to give the note a single time, then build it into the place where the work happens so the mistake becomes hard to make. Wrong file setup should fail a checklist before it fails a client. The premium look you keep asking for should be a starting template, not a plea you repeat every round.

How do you actually build a standard into the system?

You externalize the judgment. Take the calls you keep making by reflex, the ones your team cannot yet make without you, and move them out of your head into something they can use without asking. A default that is already correct. A checklist that catches the recurring miss. A pair of examples, on-brand and off, with the reasoning written beside them so the next person learns the why, not just the verdict.

The reasoning is the part everyone skips and the part that matters most. A rule with no logic attached is brittle. It covers the exact case you wrote it for and breaks the moment reality shifts an inch, because nobody downstream knows what it was protecting. Write down why the call was made and you hand the next person the ability to extend it, to apply the same judgment to a case you never anticipated. That is the difference between a rulebook that ages into handcuffs and a standard that grows.

Build it out of scars. Do not sit down to author a comprehensive quality manual, nobody finishes those and nobody reads them. Watch for the mistake that shows up twice, write the smallest rule that would have stopped it, wire that rule into the template or the checklist, and move on. The system accretes from real failures, which is the only version teams actually trust and use.

What is the real test that it worked?

The absence test. The work stays good on the day you are unreachable. That is the whole scoreboard. Not whether the team admires the standard or nods along in the meeting, but whether the launch that ships while you are on a plane holds the same bar as the one you personally watched over.

Heroics do not scale, and the all-nighter that saves the launch is a warning, not a badge. The point of building the standard into the system is not to stop caring about the frame at midnight. It is to make sure the frame was already right before midnight, because the standard was in the room the whole time even when you were not.