How We Work- Energy

[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:

Put The Big Rocks In First

Faced with one big project and a thousand tiny things to do, the temptation is to do the thousand things first - to clear the decks so that you can focus.

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 you don't put the big rocks in first, you'll never get them in at all.

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.

Don't Wait

This one is unusual; an experimental Fire Hazard policy that I haven't seen anywhere else. I'm serious about giving it a shot because I think it's potentially very powerful, but we might end up changing it.

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:

1. Find a way to do Y yourself, or
2. Find a way to do X without Y, or
3. Find a different X that doesn't need Y, or
4. Find someone else who can do Y, or
5. Abandon X and do something else.

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).

Can We Do It Today?

This one is about changing expectations. I've worked for, and with, larger companies where the expectation is that if we're doing something, we'll do it on the timescale of weeks. "I'll get back to you on that" means "I definitely will, but it might be a few days, and I expect to hear from you a few days after that".

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.

Reject, Don't Queue

This is another dramatic departure from normal 'yes' culture. Larger companies are made of specialists; only Bob is really good at X, so if you need X done, you have to ask Bob to do it. Bob won't say no (because everyone wants to help out), but if he's really busy, it'll go on his list and he'll get to it when he gets to it. Because Bob is an optimist, he'll probably tell you that he'll get to it soon, but he might not, and meanwhile, the project stalls.

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:

1. Doing X. Yeah, now! Let's go!
2. Putting X in a very short queue ("just finishing this, will be about an hour").
3. Advising that the queue is long and unknown ("I don't have an ETA for this")

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.

Named Person

We don't have fiefdoms; we all work on everything. But if Everyone is responsible for something then nobody is (the bystander effect). So each project has a named person who is responsible, not necessarily for doing it, but for making sure that somebody is - that it keeps momentum, and that we don't forget about it.

Death or Glory

Low-momentum projects not only achieve nothing, but they drain the energy out of other projects around them, by getting us all used to moving slowly. If we start a project, Death or Glory are the options: a project that cannot be progressed quickly should be terminated.

(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:

• Dockhead (a potential office location; the landlords were consistently slow in responding so we abandoned the project and moved elsewhere, even after masses of prep work)
• The Alliance (a new game in development; paused by Gwyn after realising that we just didn't have the resources to progress it quickly)

Target Selection

Working here, by and large, should be fun. But still: don't work on the thing that will be the most fun to work on. Work on the thing that most needs doing right now.

(Save the really fun thing for when you've Gotten Something Done and need a break)

Focus Fire

As a company, we want to work on the smallest number of projects simultaneously that we can. It's both more fun, and more productive, to ship something every couple of days than to deliver a huge pile of work ... sometime ... a month or two from now.

The smallest number is not, unfortunately, one. This would be inefficient due to:

• External delays. If we're waiting on someone else and can't go around them, then with only a single project, we'd have nothing else to work on and would be forced to idle.
• Tripping over each other.

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.

Dependencies First (and In Parallel)

Most projects come with external delays. Even after applying Don't Wait, some of these will remain.

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:

• First, and
• All at the same time.

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.