Theater For The Future

Ever seen one of these? It’s a big binder filled with knowledge. Procedures. Contacts. Lists. Accessible Information.

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.

A) Acoustic Physics - How Sound Works
1) How sound waves mix in the air
2) The controllable properties of sound - Volume, Direction, Frequency, Timbre, Duration/Envelope,

B) How the Equipment Works
1) Microphone Pickup Patterns (what microphones “hear”)
2) Speaker Dispersal Patterns (cabinet distortion, directionality, phasing problems.
3) How Theatrical Sound Equipment can distort and shape sound waves
4) Mixer routing - Inputs, Faders, EQ, Inserts, Trim, Bus/Group Outputs, Auxillary Outputs

C) Cue Operation and Programming procedures
1) Mixer Manual - for Mute Scenes / VCAs or Scene Presets
2) Sound Playback Manuals - QLab, SFX, CD Players, etc.
3) MIDI and automation - getting equipment to trigger other equipment for simple show operation

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 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)
• Marketing distribution (a checklist of places to put posters and postcards)
• 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:

New Leaf Department Knowledgebase
Artistic
Play Readings
Marketing
Development, Fundraising & Grants
Production
Box Office

Agendas (these contain items that require discussion in our next face-to-face meetings so that everything gets captured)
Company Meetings
Production & Design Meetings
Marketing Meetings
Board Meetings

Meeting Minutes
Company Meeting Minutes
Post Mortem Minutes
Marketing Minutes
Committees Minutes

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.

In Our Town, we like to know the facts about everybody.

There’s David Cromer, who I first knew as one of the directors of Cider House Rules (my first sound op gig in Chicago). Our affectionate nicknames for him and Marc Grapey, our other fearless leader on that show, were “Tigger and Eeyore.” Corrie Besse, that’s a name you don’t want to forget, she was the teensy powerhouse that wrangled the cast of 32,000 backstage in the upstairs Victory Gardens space. Look at that, she’s worked her way up from ASM to SM. Still wrangling a cast of thousands and a props setup to make the fearless quake.

Alison Siple is one of those mad genius types. My favorite work of hers remains these angel wings made of umbrellas (her specialty!) that she did for one of our plays at Cherubs. Then there’s Jonathan Mastro over there by the piano. You might have seen him before on the piano with the Monkeys, or perhaps you were lucky enough to see him tickling the ivories for the Chicago Children’s Theater premiere production of “A Year with Frog & Toad.” We still sing the grand finale of act 1, “Cookies” up in the Owen booth. No matter what the show.

Then there’s Tim Curtis. Last time I saw him was back on the Visions & Voices stage during Accidental Rapture. I still play my Four Horsemen of the Apocalypse sound cue from that show to demonstrate sonic storytelling (and you can get a great Lord-of-The-Rings horse breath effect using the snort of a walrus).

And good old Devin Brain. He’s one of the guys that helps make things work on all those Hypocrites shows you’ve been seeing - I remember sitting with him on the orange carpet during Porno at the Side Project with Grant Sabin trying to figure out how to best rig those damn TVs to the grid. He’s a pretty stellar director, too.

The structure is nearly at the beta testing stage. Obviously we’ve got a long way to go yet - it’s ugly as sin and there’s some duplicate data in there. And missing! Where the hell is John Wehrman? He’s a part of this show too, just off of New Leaf’s Girl in the Goldfish Bowl. And to bring it full circle, there’s in the space itself the memory of the last event that took place here - the beautiful wedding and reception of Kaitlin Byrd and fellow Plagiarist Ian Miller a few weeks ago. She lead that cast of GGB and, if you look way back, you’ll notice that she was in that cast of thousands in Cider House as well.

I just love a wedding, don’t you? They’re just so beautiful. We are carving the gravestones of these memories here. To leave a mark where there was none. To draw connections. To remember.

And this is only one window into our history. We’re ready to start collecting your info if you have some to give.

Laura at Trailing Spouse Blues tuned me into this article which is just a wonderful working example of the theory at the core of this blog: that an open sharing of information leads to a “bigger pie” - more influx of thought, funding, and participation in theater, which leads to a reinvigorated and strengthened theater community.

When you share your knowledge you strengthen your industry and gain unexpected rewards.

I’m certainly not suggesting Coke publish the secret formula on their web site. But for a creative person sharing knowledge, especially business knowledge, will help the community has a whole.

The more knowledge amateurs, students or beginners have the greater their ability to make quality decisions. People can’t be forced to follow best practices or charge a professional rate for their work. But, more often it’s a lack of knowledge and experience that leads to such poor decision-making.

It’s hard to let go of the knowledge that we think is at the heart of our success. The note-taking system I detailed in the last post is an example of something that I do to help keep me as organized a sound designer as possible. I think it makes me better able to cope with the demands of a sound designer - where you must overlap many shows at a time in order to pay bills. At those times, it’s important to remember that our knowledge - which is the sum total of our history of choices, experience and conclusions of that experience - is both valuable to a newcomer, but it is also build and really only works for our brain. People can take your open-source knowledge and they necessarily will reshape it to their purposes. Virally, new thoughts and solutions will be created that you wouldn’t have dreamed possible. At the same time, those new thoughts wouldn’t have been possible without the seed of your own knowledge.

Sharing your best practices extends the collaborative ethos of theater into your business, not the other way around. It doesn’t guarantee the success (or domination) of a particular individual or a particular company, because it doesn’t guarantee ‘credit’ - it strengthens the entire industry first.

When I first started designing, I took handwritten notes. Scribbles, really. Each note said something like “dloor up 7 after…” I have horrible handwriting under pressure in the dark. Also, I didn’t write very quickly, so I’d leave a lot of trailing sentences as the play progressed and new cue mishaps grabbed my attention.

Frankly, I didn’t yet have a process, and I was designing in a panic. I used notes as shorthand to trigger my memory of what happened particular run, and then doing the notes meant reconciling that memory with the director’s divergent memory and then taking an appropriate measure to correct that cue for the next run.

The problem with me and this method became clear the first time I designed my annual summer juggernaut - the ten repertory shows of Cherubs. Each show ran an hour, and teched in an hour and forty five minutes. After tech, I would have one dress run to make any last adjustments, and then performance. Each night you tech two shows, and then the next night you tech two more. At the end of my first week of Cherubs tech I had a pile of incomprehensile scribbles like “Fade out the drone when she does that thing upstage” with little memory of the play itself. I needed a better way.

And I didn’t just need it for Cherubs. I looked at the designers whose careers I wanted to emulate - Andre Pluess, Lindsay Jones, Ray Nardelli, Josh Horvath. These individuals are unbelievably prolific, if you haven’t noticed. I think Lindsay pulled off something like 30 shows in 10 states last year. They worked everywhere, all the time - in Chicago and regionally. In watching their processes, I noticed patterns in how they organized their notes, cues, and files into standard formats and structures no matter how different the show was.

I experimented with excel spreadsheets and text files. The disorganization and lack of clarity continued - though I did notice that I had a speed increase and a greater percentage of complete sentences because I’m a faster typer. So I was capturing more of the same bad information I worked on self-discipline in the moment and looked into some preliminary shorthand lessons. It didn’t click with me. New problems started emerging as I experimented with new methods - I would bring a level up one day only to bring it down again after sitting in a new seat only to bring it up again after sitting in the first seat again. I was pushing and pulling my hair out.

The breakthrough came for me when I thought about the nature of the information I was trying to retain. Levels. Cues. Moments. Memories of the events of a run. Records of previous runs and notes. Whether I had taken care of a note or not. Notes from a director. Notes for a stage manager. Notes for myself.

I decided to create (ta da!) a relational database and see how that worked for me. I broke the information of my work into core models - cues, subcues (like fades and layered sounds in a cue), notes. Five years later, it looks like this:

Not the greatest interface, but it’s been built incrementally with only my brain, so it works great for me. Notes are in yellow there. As a show progresses, I scroll through my cue list. If I have a note, I just type in one of the yellow boxes and I have a quick pull down menu of basic types of notes to give me some quick context - “Director” means it’s something I need to ask the director. Its direct, and in practice, simple. I should note while the data structure is complex enough for me to use this system in every show, it’s also flexible enough that I can ignore great sections of it when time demands that of me. I really only use the subcue table, for instance, when I run using CD playback shows where overlapping sound files still need to be managed. Computerized playback often makes that paperwork more or less moot, so it just sits there.

By capturing the data I also noticed an immediate benefit - separating the data from the display of that data by taking it off a piece of paper or a spreadsheet freed myself to use the data in new and different visualizations. I could create a new layout that automatically created a cue list easy for a stage manager to read:

Or a quick pull list of notes to do in a hurry:

With six or seven shows and some troubleshooting, it became a system that I trust more than my handwritten notes and my swiss cheese memory. It became a way to freeze those pure, immediate reactions that I have in the space and in the moment and use those to inform my notes. And since I began analyzing the way that I captured information and the structure of the information that needed to be captured, my handwritten notes have become decidedly more disciplined and focused.

But that’s what works for me. What’s important is the way that you structure your own capture. You need a way to capture all the relevant data that you can fit into your bucket, and a way to intuitively and simply filter that information later. We are flawed creatures, and it’s not only possible but likely that at some point you’ll try to fool yourself into thinking you took one action when you took another.

There was another important capture that took place in recent months - the company members of the side project sat down and captured through a brainstorm all the roles and responsibilities of the company so that we could better enlist and provide support to Artistic Director and theater operations superhero Adam Webster. By capturing and filtering the things we did as individuals over the course of a season, we began compiling a bible of simple manuals for tasks and procedures that were involved with running a theater - everything from filing taxes to taking out the trash to repatching the lightboard. We took this information out of our cluttered minds and put it in a repository where anyone can come in and take over, and in doing so the problem of “running a theater” became smaller and more manageable. When you look at the life cycle of company membership, that kind of capturing and filtering process creates institutional knowledge that is the difference between the life of a theater company and its demise.

This is one of the reasons that I think creating a database of Chicago Theater is a worthwhile project and not simply navel-gazing. It is made up of collected and searchable and therefore endlessly useful data. If it is successful, it creates a model for other public resources of data in the theater community that by necessity would be more accessible than say, TCG’s data that Scott Walters used to such great effect. It captures hard facts that can be organized to suit your purpose that day. It allows us to check things that we believe are true (”You know what Chicago needs? A production of Our Town in April 2009!” They’ll never know what hit them!) against the captured data of collected memory that inarguably is true.

On a side note: Speaking of manuals, I’ve been exploring the utterly hilarious Poignant Guide to Ruby in my learning process of the Ruby on Rails programming environment for the CTDB. I think the devilvet in particular will appreciate the use of off-the-cuff cartoon foxes and elves to spice up the process of (yawn) learning a programming language.

When you’re reading and writing a manual, I cannot stress enough the importance of retaining your sense of humor. This is the thing that I often forget.

Some brief updates from the forge:

• Tech is going well. That’s the sound playback software LCS you’re seeing there. It’s pretty sweet - it’s the secret behind the complex sonic routing of things like Disney World, cruise ships, Cirque, and, well, the Goodman.
• You have like three days left to see Vivian Girls. Run, don’t walk, to Theater on the Lake at 7pm. I’m probably going to refrain from actually reviewing work on this blog, because 9 times out of 10 I have some sort of relationship or investment in the shows that I would review, but this show stands out. Dog & Pony’s opus isn’t simply a show - it’s an entire emerging genre of performance, and whether you like the show or not (you will) you’ll leave with your head abuzz with possibility. And no, you won’t be weirded out by the masks. You’ll dig it. Scout’s honor.



• The push is on for the Chicago Theater Database. Dan Granata and I have met with a number of interested parties, and it looks like the database will be beneficial to a large number of projects - and the Chicago community at large - without stepping on too many toes. As a result, I’ve taken the plunge to learn a new web development language, Ruby on Rails to simplify the development of the database. My head is swimming right now in: rake db:migrate Lions, script/generate model Tigers, and script/destroy controller Bears, Oh:My! If you’re interested in the project and less in the building of it, send a note. Why should you care? Because data is important: it helps us learn and know things for sure. Update: No, seriously, our data is important.
• The 10 scripts are in for “Cherubs,” a theater training program at Northwestern I’ve taught at for the past five years - a program that has been formative for me as a designer and a teacher. I’ll be designing these 10 shows in July with the assistance of 160 brilliant high schoolers from across the country (and sound designer/composer extraordinaire Steve Ptacek). Preproduction for 10 fully produced repertory shows built and run by teenagers is obviously an undertaking, of course. So those scripts and concepts have started swimming around in the kiddy pool of my brain with the Ruby and the LCS.
• So, as this season prepares to comes to a close, I’m finding myself knee-deep in delicious theater smoothie. Set to frappe. I’m glad I’ve got momentum as I ride around in the blender - and a full plate of projects that I think will do a lot of good for me, us, and the kids respectively. But of course it all means that posting here will continue to be spotty through June, and then blip out entirely in July as I pull daily allnighters - kind of like that period of radio silence as you round the dark side of the moon. But never fear - the summer always has this gravitational pull that flings me back out the other side with a new kind of velocity.