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.
5 Comments
- “Replication is hard. Actually, replication is impossible. Replication is copying. Copying doesn’t work.”
Depends. Look at Intel. Intel has built a 50y old business with ~100,000 employees based on the principle “Copy Exactly, Copy Everywhere”. The company strives to duplicate even the subtlest of manufacturing variables, from the color of a worker’s gloves to the type of fluorescent lights in the building. Employees from around the world spend more than a year at a development lab in Oregon learning their small piece of the new recipe so they can bring it back to their home factory… Whole campuses & plants are replicated across the globe.
But I admit. There’s a difference here. Intel has only implemented “copy exactly” in the 80s, most probably to deal with its increasing size, global footprint, and growing number of employees.
Small companies are in a totally different boat. You hit the nail on the head. Small companies need to innovate by being creative and by being agile to the specific needs of their employees, their customers, and their immediate environment.
And those things, let’s be honest, can’t be copied.
Hi Nico!
Wouldn’t that be a different kind of copying though? That copying is part of the overall design of their company, rather than an attempt to copy the exact design of other companies.
Hi Chris!
You have a fair point, but keep in mind that there are many organizations (aka mini-companies) within a big company like Intel. In that sense the “copy exactly” mentality is not necessarily a tool to “learn” how to do things from other “companies” (in this case, organizations) but rather it provides a “framework” that’s “known to work well” for new “companies” (e.g. new think tanks within Intel) to bootstrap and therefore bypass some of the learning process that comes with a starting a company (in a very specific industry, be it IT, theatre, hardware vending, etc).
Ah, cool, thanks for the insight Nico!
I could not have stumbled upon this at a better time. I am currently in the research/business phase for starting my own theatre company, and as I read your first post, it was like you’d read my mind! I’ll be checking out your archives now.
One Trackback
[...] 26 2011: Please also read the addendum to this post: Two Years Later, Thoughts on Funding Theater This entry was written by Chris, posted on at 11:34 am, filed under Business, Design, Somebody [...]