In his big comeback post, Scott Walters illustrates very clearly the reasons for an artist to be proactively collecting and sharing the knowledge of what it is they do and the tricks and insights that make the work itself easier and more effective: knowledge is power.

… Those who wield power in the theatre — the administrators, the board members, the foundation staff — do read these studies, do recognize the value of the data and the ideas, and do put them into action — and that is how they maintain their power. They think more broadly about the art form. The result of lack of knowledge is a diminished power for artists, who give over control of their art to those who will take the time to study, to learn, to think.

The lifespan of an artist within a theater company is often a lot like the lifespan of a fruit fly. Artists often want to do one thing – say, perform – and get signed on to do that, and run box office, and figure out how to market a play, and raise money for that play, and keep the bathrooms clean… It’s tiring, and the passion for your work either carries you through the balogna or it doesn’t, and after five to ten years you start dreaming of a normal adult life that doesn’t involve begging and scrubbing and poverty.

For me, there is a lot of wasted energy in reinventing the wheel here. Let’s say a company is formed in 1983, and goes through five leadership cycles in that time. There’s a big difference in quality between the company with leadership that captures the collected knowledge of the company and the company that starts from scratch every time a company member moves on. It’s the difference between accruing institutional knowledge and burn out.

But when you get your feet wet, you’ll start to notice big challenges involved in passing complex knowledge structures on to a complete noob. Awful example from my own experience: Teaching a non-technical person how to mix their first musical. Let’s say your regular technical guru is moving out of town, and you have to basicially xerox them or face the loss of quality that comes with losing talent. There are two ways to go about this, neither of them ideal: You could label everything in the booth with a mountain of post-its and basically say “never touch this – or this – or this,” thereby simplifying the job. This definitely reduces stress in the training period, but it isn’t really a long-term solution – it cripples the student’s ability to explore and learn from mistakes over the long term. It leaves them to build their own foundation of knowledge, and it assumes that the choices you make in those final stressful and despairing moments of your tenure were the right decisions for the long term health of the company – which is almost never the case.

There’s another approach, akin to the development of a curriculum for self-study: the guru creates a comprehensive list of all the pieces of knowledge that one would need to do the job.

D) Common “Gotchas”
1) Everything plugged in?
2) Everything plugged in in the right place?
3) Best signal testing practices – start at one end of the signal path and move carefully to the other.
4) The psychology of monitors and mic placement – getting the performers and the producers on your team with the common goal of the best possible audience experience (or, “If I turn up your monitor there, we either won’t hear you in the house, or we’ll hear you and squealing feedback”)

To be sure, each one of these items could be a dissertation in themselves, and this is more overwhelming for a blank slate student. However, it creates an ongoing resource for the student to explore and research over time and as their experience expands. It also doesn’t set a time limit on the training period – it allows peer-to-peer learning to continue beyond the tenure of the burnt-out ex-company member.

The MOST important thing is of course to create this knowledge resource well in advance of those often gut-wrenching final two weeks of a company member’s tenure. Capturing this information while stress is a factor is a good way to get a crappy knowledgebase. If you’ve ever been trained as a temp, you know what I’m talking about – If you need to know A – Z to properly do your job, some folks will teach you A (“Turn on your computer”) and then B (“This is the Power Button”) and then when that goes off without a hitch, they’ll spring Q on you (“And so then we just need to you to file the 990 Form with Accounting”) without explaining, oh, H (“Accounting is near the elevator”), or M (“990 Forms are tax forms for non-profits.”) or even C (“We are a company that audits non-profits”). And some folks assume you know too much and will rifle through the instructions for X-Z (“Just tell the president your progress by the end of the day.”) and they’re out the door. There is never enough time for the trainer to go through A-Z. And yet real damage happens to companies in both of those moments when A-Z isn’t effectively communicated or learned by the trainee. The corporate world can easily absorb that damage, but theater companies can often die off or suffer direly in fundraising in those moments when leadership changes.

So manuals can cushion the blow as the company grows – or even simply ages – and folks move on. Some of the manuals that I have written for New Leaf and The Side Project include:

How – and when – to update the website

Run Sheets – how to preset and run a particular show

Box Office procedures

How to share files over the internet so that group collaboration is less time-consuming

Brand manuals (use this font, use these colors, use this page layout, use this logo, and the branding rules that you can bend, break, and the ones you can never ignore)

Production Timeline & Checklist (what needs to get done, and when it needs to be done)

What I’ve learned about these documents is that they usually need periodic revision – so the best time to write them is as the processes are being put in place or being revised. By writing a manual as you perform the task, you can often do a better capture of clear step-by-step actions and have a better retention of all the dependent knowledge that is helpful in performing your role.

Treating manuals like a simple dumping ground of everything doesn’t work, though – they need to be more or less a complete overview of day-to-day operations, but not an exhaustive archive of everything that has ever happened ever. That’s too overwhelming to be useful. So some diligent and forward-thinking editing is always a useful habit to get into.

For these reasons, the ideal medium for a company knowledgebase is often a wiki – a living, interconnected document that allows certain basic knowledge resources to be outsourced to say, Wikipedia or other blogs & websites. Knowledge can also be organized into a structure to make critical data more clear and supporting data settle into nested structures.

At New Leaf, we’ve used a wiki and a company discussion forum in tandem for about three years, and it’s proven to work very well with our own human natures. Most day-to-day company discussion happens on the forum, filling the forum with a rich silt of acquired knowledge, planning, brainstorming, and chat. It’s almost a daily journal for most of us, a big net that captures all our ideas. We have also worked out a quick sorting and archiving process that we do as part of our production post-mortem process. When a particular nugget of knowledge from the forum discussion proves permanently useful, it finds a home somewhere in our company wiki – the repository of permanent knowledge for the company.

And on the wiki, the information is clearly organized for future company or board members. It kind of looks like this:

Timeline & To-Dos (Each of these is a calendar for each production with template dates, like “Opening -3 Weeks”. We just plug in the dates before each production, and voila, we have a list of everything we need to get done.)
Production Timeline
Box Office Timeline
Marketing Timeline

Knowledge Base
Knowledge Base – Web Tools, Important Contact Info, Stuff to Know in case of emergency
Company Bylaws
New Leaf Culture – The way we like to do things, and why
Production History
Who We Are – Mission, Vision, Values. Learn them. Love them. Live them.

Over the past few years, we’ve had the typical internal turnover at both companies that happens as artists grow up and live their lives – and new artists with fresh ambition pursue their artistic lives as a part of the company. The forum / wiki / knowledgebase process has proven its worth through the shifting membership to our newest company members. As they have time, or when they’re confused about how something works, our old discussions and accrued knowledge resources can be skimmed through and learned as needed. This is often an exciting process for a new company member, like opening up an old tome filled with old words and old thoughts. It is a training period filled with knowledge and cloaked in mystery. Can you imagine that in a corporate environment? Our old show notes create a clear picture of our context and our history – and steeping in that knowledge has helped us avoid the dangers of repeated mistakes, without limiting us to a knowledgebase of post its that limit the agility of our current operations. Understanding and remembering the old risks we’ve taken inspire better risks to be taken next time. I’d wager that our effective capturing of knowledge has helped us stretch our annual budgets as well, because we have a memory and a process that allows us to allocate money towards our artistic growth and our newest risks rather than sinkholes of productions past. Best of all, creating the knowledgebase was a dirt-simple, efficient, low stress, and even fun part of the process.

Scott’s speaking the truth again: the key to better lives for you professional artists out there is taking responsibility for your own artistic goals, and empowering yourself with the tools and the knowledge you need to achieve and reach beyond those goals. For me, the thing I needed was a way of remembering where I’ve been. Breadcrumbs along the trail, so to speak.

6 Comments to “How (and why) to write a Company Bible”

Excellent ideas. I’m gonna say the hardest part would be getting each team member to actually follow through on this project. The other big thing is that you would need someone on the team who actually knows how to write well to edit each person’s manual. I know actors who are very articulate in their speech and can read a script all day long, but when you hand them a pen or pencil, they barely know which end is the pointy one.

That’s why the forum and wiki solution are a nice solution… using them on a regular basis creates the same kind of knowledgebase without all the formalism of a step by step manual. I mentioned those mostly to walk through my own considerations in finding a system that worked for a small theater – we did the manual thing for a while, and it does work, especially for more technical procedures. But for a more holistic approach that easily includes everyone’s input, Forum => Wiki is a great way to go.

Editing this collected knowledge is a very tricky process. It’s easy to undervalue the perspective of certain individuals based on your own perspective – especially when you have very different interpretations of the raw data. I think having a single editor archive all the captured information is not a sustainable way to go – that means that you’re essentially creating a knowledge gatekeeper position, and you’re ultimately subject to their interpretation of what the knowledge means and what knowledge needs to be stored. What happens when that person leaves the company, or when that person decides that a certain aspect of the company is less important than another (say, marketing is more important than the quality of the artistic product)? While it’s more work and requires more scaling of the ol’ learning curve, I think you’ll yield better results in a small company when information is held and processed transparently by the entire company or at least the department heads. If you leverage the use of a forum in your collaborative discussions, it can be as simple as selectively cutting and pasting the things you’ve learned.

I love going self-hosted in general, if that’s an option. For forums, nothin’ beats the new version of phpBB. Many hosting providers will have handy install scripts for phpBB built into their control panel. Tons of permission control, and fantastic organization features.

For Wikis, We’ve had great luck with using docuwiki – click here for an example of how it looks. Mediawiki, which powers wikipedia, is both the most powerful and the most difficult to use, so docuwiki fit our non-technical staff much more easily – but it wasn’t *so* easy that the basic wiki cross-referencing features became crippled.

At some point, I should write a tutorial for getting open source software – especially software requiring a database – working on your website. It can be tricky to go DIY, but most open source projects like these come with pretty complete instructions. phpBB is how I learned to set an application up on the web, connect it to a database, and launch, so that’s the best place to start.

If you’re looking for a fully-hosted wiki, rather than one on your own domain, for simplicity’s sake, there’s pbwiki, which I haven’t used… I haven’t liked wikiSpaces from what I’ve seen so far, which is another one.

One very promising development is the new Google Sites add-on to Google Apps for your domain. I pretty much insist on Google Apps – a completely free way to add gmail-powered email, calendering and chat to your domain – for all organizations when I work on their website. Google sites has some basic templates that you can use for internal project management, or company intranets, and I think some of those can approximate wiki-like features. I’ll try to play with Google Sites a little more in the future, and if anyone has some insight, speak up!

Thanks for the kind words. I think your ideas are spot-on, and your use of the wiki is perfect. I have used pbwiki and recommend it without hesitation. Basic and easy to use. As you know, I am a college professor, and it just occurred to me that a college drama dept would benefit from just such a handbook. (Now how to get my colleagues to do it!)