[Part of a series of articles on Fire Hazard's core values, but also useful by itself.]
"ENERGY: Move fast. Be big, loud, dramatic and decisive. Avoid delays. Keep the energy high."
We move fast, all the time, for two reasons:
1) We have to. Arts and entertainment companies exist right on the edges of financial feasibility. We don't work long hours, so to cover salaries we have to work, consistently, with incredible speed and efficiency. And for the company to remain relevant, we have to constantly produce new things.
2) It's really, really fun. One of the reasons we're doing this, not corporate jobs, is because making dramatic things happen on a timescale of hours rather than months is awesome.
This affects how we work. We have a concept called momentum: how quickly a big project is moving. It's doubly important because "an object at rest will remain at rest ... an object in motion continues in motion". With a project, or company, where everyone is used to moving quickly, it's much easier to continue to move quickly.
Everyone finds their own ways of building and maintaining momentum. Here are some of mine:
This doesn't work. By the time you've cleared them, there'll be another five hundred. Though you're ticking off tasks, it's a false sense of productivity, and the big project is losing momentum.
If at least some of the thousand things can genuinely wait for a day, put some blocks of time in your calendar where you only work on the big project. I try to do this twice a week, usually wearing headphones to avoid distractions.
Work is full of dependencies. Normally this looks like: "To do X, I need Y. Only Bob can do Y. I'll wait until Bob gets around to his bit."
No. Don't wait. If Bob is available - which is likely, if we're all in the office or on slack - get him to do Y right now. But if he's not:
Do this even if the new version is not quite as good, or even if it take you slightly longer to do Y than it would have taken Bob. It's worth it, both in the short term (preserving momentum) and in the long term (you've just learned how to do Y better).
All it takes to change this is a question, asked routinely either of yourself or of anyone you're working with: "Can we do this today? If not: what would we need to change so that we can?"
Often the answer is "oh, hell no", but it's worth continuing to ask the question.
We're a bit different. We're a very small, cross-skilled team (most of us could, at a pinch, do any job in the company, or could learn to do it quickly). Plus we have many different things we could work on, and it's more important that things are happening quickly than that any particular things are happening.
So, as Bob, asked to do X, you should respond by either:
This will often trigger Don't Wait on the person requesting X. It also helps to expose when people get overloaded - instead of ever-growing queues, we get active job rejections, so we can rebalance the workload.
If X is non-urgent, non-critical, and the end of a task chain (ie there is no Y that depends on X), then we might still opt to put it onto the end of a long, unknown queue and forget about it.
(Not necessarily permanently, and not necessarily destructively; we stash all the work-in-progress in a way that we could pick it up again in the future if things change).
We do not submit to the sunk-cost fallacy.
We're serious about this. Among others, it has recently happened to:
(Save the really fun thing for when you've Gotten Something Done and need a break)
The smallest number is not, unfortunately, one. This would be inefficient due to:
We'll adjust this, but my current feeling is that the right number is one to two projects per person. Anything else stays on the Ideas pile until you've shipped one of your existing ones.
For example, Project Test Fire includes, among other things:
A. Check speaker availability
B. Find out ideal dates/places from the members (via mailing list survey)
C. Find a venue
D. Choose a date
E. Organise everything
The trick is to plan out the project in advance, thinking through where the delays are likely to be - and then to make sure that they happen:
Task E above is the largest, but A, B, and C all come with delays. The opening salvo should be to start the clock running on A, B and C all at once (and this is a relatively quick thing to do).
Whenever you're not working, you especially want the clock to be running on the delays (so the project is still moving). So if the lasercutting you need is going to take three days, and you know that you're going to be away for three days, arrange things so that you get that order in first.
Generally anything that involves talking to or working with people outside the company should happen at the start of the project. It's often a good idea to burn extra work-hours to save clock-hours - ie to structure the work in such a way that's actually less efficient, but faster.
For example, don't contact Venue 1, wait for them to respond, then contact Venue 2 if the answer is no - contact them all and go with the best (or first!) response. Get a quote for the lasercutting even if we don't, yet, know if we're going to need it.
This is a starting point. We'll keep changing how we work, since we're a tiny startup in an uncertain world and we don't even know what we'll be doing in six months. But whatever it is, we'll be doing it quickly.