About two years ago, I wrote a post entitled “Toward a New Funding Model for Theater”.
It turned out to be one of the more popular things I’ve written. Over time I’ve heard from theaters around the world experimenting with the ideas explored in that post.
Here’s part of an email I got last month:
Hi Chris,
I hope you’re still at this address.
I read your blog post from ‘09 about discovering theatre models that are sustainable and actually move towards viability. We’ve started a theatre in Abuja (Nigeria’s capital) and are looking at innovative approaches to the business of theatre. We ran into some debt and are coming out of the woods. Now, we’re reinventing and also considering a government loan out of a fund that’s recently become available but we want to be as informed and tooled up as we should be. Also, case studies of successful models used elsewhere will be useful for us and encouraging to the banks, as you can imagine.
I wonder what other new and useful insights you’ve had over the years from discussing this — I guess what I’m asking is what models have worked for your friends, which we may stylise for our terrain and replicate?
Neat, right? The wonders of the Internet!
Totally neat. But also, truth be told, a little scary.
Is this thing on?
When real live companies with real live people and real live money are trying things based on something I wrote, I darn well want to feel comfortable that I’m not leading anyone off a cliff.
So, in that spirit,
An Addendum
Or maybe,
A Retrospective?
Anyway,
A Few More Thoughts On Designing A Company
Designing companies is hard.
As my own has grown, we’ve had to pick which new products we’ll tackle, how we hire new people, and how, exactly, we keep the office adequately caffeinated.
But it’s not just those things that go into designing a company. We design our company every single day. The creation of Figure 53 is a continuous act.
The little stuff adds up.
The little stuff is hard to copy.
People study successful companies. They look for what they can replicate.
Replication is hard. Actually, replication is impossible. Replication is copying. Copying doesn’t work.
When people copy the design of our software, I never worry about it. Someone who copies a design doesn’t know the next move. They didn’t get to that place because they figured out how to get there, they got to that place by a shortcut. But the shortcut cuts out all the important stuff.
Are you saying it’s impossible to learn from others?
No.
What I am finally circling around to say is this: I am proud of my original post, but if there is anything I would change, it would be to stress how inconclusive and exploratory those ideas really were, and are.
In retrospect, that post captures the initial moment of product design. A vision for a thing that Might Be, if only we can suss it out with a lot of hard work and corrections to our path.
It represents the point of departure for a unique creative act. The details have not been filled in. All the critical little stuff — the stuff that makes it or breaks it — has not been discovered.
It does not touch on many, many other pieces of the puzzle that will affect the design and implementation of the ideas in play.
And it definitely does not present the only valid option.
Fine, but can it work? Has it worked?
What’s “it”? The problem here is that there is no concrete “it”. There are dozens of possible implementations of those ideas. Some of them might work great. Many of them will fail.
(If you know any great examples of theaters that put memberships at the core of their being, please let me know in the comments, I’d love to learn about them.)
Design Patterns
Design patterns, in software, are architectural strategies that appear across many programs. They represent constructive techniques that appear frequently when dealing with particular kinds of problems.
Design patterns are a good place to start thinking about the high level form of a program. They also serve as a great communication tool; they’re coder shorthand.
But by definition, design patterns don’t dictate specifics, and they don’t determine whether a program will succeed or fail. They can help organize it, they can help clarify it, but they can’t, ultimately, make it good or bad. That’s up to the programmers, whose craft is to create unique software under unique circumstances.
It may be that my ideas from that 2009 post sketch out one design pattern for theater companies. I hope they do. I think they might.
But even if they do, they won’t dictate success. At best they can help organize and clarify. The devil is in the details, and the details are up to you.
