The Business System
I Wish We Had Built Sooner

When Arrow Creative grew to a team of five, I thought more people would finally make the business easier to step away from.

More people. More hands. More people to divide the work between.

Instead, I learned how easy it is to build a team where five jobs can still depend on one person.

Me.

If someone got sick, took vacation or suddenly had to step away, there were entire chunks of the organization that nobody else knew how to run. The work had technically been delegated, but the knowledge behind the work had not.

Every job had evolved naturally. Someone learned a program because we needed it that week. Someone developed the relationship with a vendor. Someone figured out how registration worked. Someone became the person who always knew what to do when a certain problem came up. Over time, a role stopped being a list of responsibilities and became hundreds of tiny pieces of information living inside one person's head.

That was the part I hadn't accounted for. I thought I had delegated the work. What I had really done was move the tasks, but I was still the backup plan.

"Manage classes" was not actually one job

Once we started looking closely at each role, I realized how misleading our shorthand had become. "Manage the education program" sounded like one responsibility. It wasn't.

That job included helping choose classes, coordinating instructors, collecting contracts and tax paperwork, putting classes into registration systems, updating calendars, marketing the class, ordering supplies, setting up the room, handling cancellations, processing instructor payments and recording what we learned afterward.

"Run the marketplace" wasn't one responsibility either.

It included sales processing, returns, customer service, vendor onboarding, merchandising, inventory, artist payouts, vendor communication, opening and closing procedures and staff training. None of those individual tasks felt huge. Together, they made up a job, but too much of the HOW was living with the person doing it.

So we started building job blueprints

We called them job blueprints because I didn't want another job description. A job description tells someone what they're responsible for. I needed something that answered a different question.

If this person couldn't come to work tomorrow, what would another capable person need to know to keep this part of the organization moving?

So we started asking very basic questions:

Then we wrote it down. And rewrote it. And added things.

And three weeks later somebody would say, "Oh wait. I forgot one."

It was not glamorous. There was no company retreat where we disappeared with matching notebooks and came back with a perfect operating manual. The documents grew because the jobs grew. And that was the point.

The first change was obvious

Vacations got easier. If someone was away, another employee could look at the blueprint before immediately coming to me. A question that used to be, "Abby, what do we do?" became, "I checked the blueprint and I think this is the next step. Is that right?"

That is a very different question.

But the bigger changes were the ones I didn't expect. We could finally see where responsibilities overlapped. We could see where nobody actually owned something. We could see which jobs had slowly absorbed work that didn't belong there. And we could see where I was still holding onto things simply because I had always done them.

The blueprints also changed how we hired. Instead of saying, "We need someone to help with programming," we could define what that person would actually own.

Instead of handing a new employee a foggy list of responsibilities and expecting her to somehow make sense of the role, we had a starting map. And when a job changed, we could change the blueprint instead of relying on everyone to somehow remember the new version.

The business started owning the knowledge

That was probably the biggest shift. Before the blueprints, critical knowledge belonged to individuals. Afterward, more of that knowledge belonged to the organization.

That doesn't make people replaceable. Good employees bring judgment, relationships, creativity and experience that no document can capture.

It does mean the company shouldn't grind to a halt because one person is unavailable. And it definitely shouldn't mean the owner becomes the emergency backup for every job.

Start with the role that makes you nervous

If you're reading this and mentally listing 14 things you now need to document, don't. Start with one.

Start with the job where you quietly think, "I really hope she never leaves." Start with the process that only one person knows. Start with the recurring task that always creates panic when the usual person is out. Or, start with the place where every question still somehow lands on you.

Whichever one hits the hardest, start there.

That is enough.

I created the Job Blueprint Starter Kit to help you document that first role without turning this into a giant operations project.

I put the questions and structure we used into the Kit. It helps you capture a role’s responsibilities, recurring tasks, systems, contacts, and processes so someone else can understand how the work gets done.

The goal is making sure your business doesn't require one specific person to hold an entire part of it together.