Some metaphor in my monster

Like most areas of film-making the development process can truly bring you to the depths of hell, or heights of heaven. Its hellishness is well documented and most often comes from a lack of understanding of the writing process or how to work creatively with writers. The biggest single mistake made by well intentioned script advisers is to start telling you how to fix your problems, most often before they’ve even identified what it was you were trying to say in the first place. Anyone who’s ever written a script and given it to others for feedback will probably have experienced this somewhere along the line. The script isn’t working for the reader so they start to look for solutions. This is like trying to have a meeting of minds by bashing skulls together; they’ve got their view of the script, you’ve got yours and never the twain shall meet! It’s painful and frustrating. In my experience, when you come to understand the difference between this, (all too common), process and good development, it’s like seeing the light! The clouds part, everything becomes serene and clear. Now reader and writer have the tools to begin a productive dialogue.

How do you guarantee you’re getting the good stuff and not some sort of backstreet version cut with vim? The fact is good development advice could come from a producer, director, fellow writer, commissioning editor, development executive, script editor, actor or friend. The trouble is bad advice could equally come from any of these sources. They may be talented at what they do, but do they have the specific skills to facilitate a writer producing their best work? (Since a script editor’s job is specifically to work with writers we’d hope they at least have the skills, especially with all the talented people out there competing for the work, but there’s no 100% guarantee.)

Development remains a fairly fluid and amorphous area of the industry, with no widely understood benchmark standards. Organisations like The Script Factory are attempting to define some, but there remains work to be done to spread the word. As one of the first graduates of their Diploma in Script Development, I’m happy to help evangelise and wrote an article on this subject for Scriptwriter a while back. If there’s a general understanding of what makes good and bad development then we’ll all be better equipped to negotiate the process, avoid a voyage through hell and promote stronger working relationships and stronger scripts. I therefore thought it was worth starting 2011 with a few bullet points on what to look out for.

Good development input should:

· Identify problem areas in the script, rather than propose solutions
The main thing your developing partner should know is that development is not the same thing as writing. They should not be trying to force through their ideas or suggestions for ‘fixing’ your script without first attempting to get to grips with what it is you, the writer, are trying to achieve with the story. Taking the position of a kind of educated audience member, they can then reflect back to you where you’re so far succeeding in your intentions and where you may be losing the audience for various reasons. Once these areas for development have been discussed and identified you can go away armed with plenty to kick start work on the next draft.

The talent of a developer lies in being able to analyse a script and identify your intentions, or at least have the beginnings of an idea of your intentions, even if these are not coming across completely in the current script. Their talent also lies in being able to identify where this gap is occurring and why. The substance of a good development conversation is therefore a dialogue about closing the gap between a writer’s intentions for the script and the reader’s experience of it. Of course, it might also include some interrogation of these intentions and discussion of whether the best choices are being made as to what the story is centrally about. However, the base line of a good development conversation is a healthy respect for what the writer has already set out to do. In some development relationships, such as working with a talented director or writing team, it may be the case that they can then begin to brainstorm a solution with you. However, since real solutions can only be found by working an idea through in all its consequences and understanding the knock on effect to the rest of the script, it’s usually best for solutions to remain the preserve of the person who’s actually writing the script.

· Not become bogged down in minor detail
Arguments over a single word in a line of dialogue are the kind of bugbears writers often cite when complaining about bad development input. The fact is that a whole bunch of lines may get cut on the shoot because of time restrictions, or because an actor improvises the line differently. After that you’ve got the edit where more lines may be cut and scenes rearranged. Haggling over minor detail is therefore fairly pointless. Not only that, but if development input is really only scratching around in the surface detail, such as lines of dialogue or minor details of the action, this is a pretty clear indication that the person hasn’t fully got to grips with what it is you were trying to achieve. They’re therefore not likely to be able to give you the more useful development insight you might need regarding things like making your lead characters more engaging, your central conflict more gripping, or heightening the impact of how its structured over the course of the narrative. In my experience of development there is often plenty to talk about in the bigger, over all picture to ever get down to the close detail! If you are many, many drafts into the script and the discussion is down to minor detail then maybe this means you’ve fixed most of the big problems. Hurray! However, if you’re on an early draft and this happens; beware!

· Maintain a strong overview and grasp of the core concept
The problem with developers acting like writers and trying to ‘fix’ your script for you, or getting bogged down in the close detail, (apart from the basic pain of it!), is that they lose their more valuable asset of providing a detached overview. While caught up in a new plot detail, scene, or while playing with some solution for an issue with the script, it’s easy for a writer to begin to lose sight of the bigger picture and the reason for telling the story in the first place. As more voices wade into the process, (as is often the case), determinedly throwing around potential solutions, its possible for the core idea that everyone loved to begin to get lost. Whether working one to one with a writer or facilitating the discussion between many parties, the most valuable role of a developer is to keep a firm grasp on this overview so that a project can continue to move forward and not breakdown. They can help all parties to identify and reach agreement on what the project should be and then keep bringing attention back to this core spark should things begin to go off track. This is a bit like having a compass to guide you through the forest when you can’t see the wood for the trees. If someone in your development process is fulfilling this role that’s a fantastically potent development tool - one every project should ideally have.

· Recognise that writing is hard and takes time
Much of the pain of development is inflicted by people who have no real understanding of the fact that screenwriting, (for the majority of us anyway!), is actually f***ing difficult and that it takes time to work through problems with a script and find the right solutions. A script can quite easily get much worse before it gets better and this is not necessarily a cue to fire the writer, or start having a drastic rethink of the direction that’s been agreed. Quite often you have to go through this stage to come out the other side stronger. If you have someone on your side who understands the realities of the writing process, knows what you are trying to achieve and is keeping a firm grip on that overview for you while you work through to find your solutions; they can help keep everyone calm, on track and off your back. That sounds pretty much like development heaven to me!

· Attempt to filter all notes through one source
If you have a good development person on side who knows all of the above then the last thing they would want is for you to get lots of different sets of notes from different sources. This is perhaps the biggest archetype of development hell, where various producers and invested parties from all sides are throwing in hopelessly contradictory notes and development suggestions, leaving the writer’s head spinning and without a clue as to the best way to progress. This has been known to make even the most talented of writers begin to rethink their calling. However, if notes are filtered through one source then these contradictions can be recognised, (and ideally addressed or dealt with), before one clear set of feedback is delivered to the writer. A good producer might take on this role for their writer, or a strong script editor brought in to mediate a complex co-production process. It may not always be possible, but we can aspire.

· Inspire you to want to write the next draft
Finally, one of the most crucial aspects of good development is that rather than sapping your soul and making you feel like a defeated, clueless and no-talent hack it should help inspire and re-energise you to tackle the next draft. This may come from the developer’s ability to shed light on areas where a writer has become lost, illuminating a new path to explore and triggering the sparks of new ideas. It also comes from their ability to recognise and highlight what’s already working well in a script, as well as its flaws, and to be able to share a little in the writer’s vision of the work that’s still to come. As you stand like an artist attempting to conjure a beautiful statue from within a lump of rock, a good developer should be able to remind you of how much you’ve already achieved and how much it will be worth your while to keep chipping away.

How to negotiate the process

So that’s what development input might look like in an ideal world, but unfortunately, as mentioned, we don’t always find ourselves in an ideal world. In the fluid arena of development where input can come from all kinds of (variously qualified) sources or where the producer or director giving notes could also be your co-writer, it isn’t always a black and white relationship of developer facilitating writer. Short of throwing your script editor up against the wall in a strangle hold, or walking out on the whole ‘goddamn production!’, what are the tools the writer needs in order to negotiate a less than perfect development experience? This is, of course, dependent on many things, such as who’s giving the notes and your relative power in the process. However, some basic tools for dealing with notes are as follows:

· Just breath and buy time
I’ve heard a number of successful writers speak eloquently on the subject of dealing with notes, most memorably Sir David Hare, (whose speech at the Cheltenham Screenwriters’ Festival was the trigger for my Scriptwriter article), and Simon Beaufoy. Both have had plenty of those teeth-pullingly bad experiences, as well as receiving real inspiration and insight from other sources. Naturally a writer’s first reaction to most kinds of feedback goes something like this: ‘You idiot! That’s the most insane idea I’ve ever heard! That will ruin the whole script! Have you even read it?!’. Later we calm down and eventually come back to the notes ready to find a solution. As we think it through we may begin to see that some of the notes actually make sense and that tackling them should strengthen the script. Simon Beaufoy’s advice is therefore to bite your tongue, temporarily delete the word ‘ruin’ from your vocabulary and give yourself time to react properly. Some ideas may be easy for you to accept and incorporate, others more difficult. Beaufoy has a line reserved for such moments; ‘Hmm, that’s a tough one, I’ll have to go away and give that some thought’. No development exec or producer should have a problem with this, especially if you’ve been open to most of their comments thus far. They might however, take exception to being called an idiot, or to a writer who digs in their heels without even thinking about what’s being said.

Beaufoy also suggests that, if possible, ask for development notes to be forwarded to you a week before a development meeting. Then rather than having to react on the spot you can fully digest the input in advance. You can then already be over your initial hissy fit and be thinking productively about how to implement the notes when the discussion begins.

· Pick your battles
Similarly Tony Jordan advises writers to nod along to input, carefully noting everything down and cooing praise to the developer on their insight, while keeping a tight lid on your inner scream. However, should the developer suggest a note that tampers with the core of your idea then this is the time to stop them and take exception. As you’ve been such a sweetheart up until this point they’re naturally more likely to take your objection seriously. However, if you’ve been arguing with every tiny point all along then this just looks like more of the same pigheadedness. Though Jordan, like many writers, tends to play to the audience somewhat at a writers’ event and imply that most developers are idiots, on questioning he does accept that this isn’t always the case. It’s possible that your developer actually knows what your core idea is and is able to discuss potential changes back and forth while keeping this in mind. It’s even possible they can see this more clearly than you! As Simon Beaufoy observed at Cheltenham 2009, ‘at times I might not know what a script is about until somebody points it out’.

The beauty of Jordan’s advice, however, is that it’s effective whether you happen to be working with an idiot or a genius. Everyone prefers to work with a writer who can take notes on board and of course, the most important issue in any development process is to protect the core of your idea. This is the part of the narrative in which your writer’s voice can be found and as both Jordan and Beaufoy agree; without this you have nothing.

· Keep the process moving forward
Beaufoy likens the feature development process to a shark; it has to keep moving forward otherwise it dies. If you want the project to go ahead then it may be useful to see development meetings a bit like talks in an employment dispute. When ACAS moves in to help resolve a dispute their strategy is to ensure that everyone in the room must gain something; preventing the process from stalling. Being able to listen and be open to new ideas is therefore crucial. Beaufoy says that rather than being threatened by new ideas he’s learnt over the years that everyone at the table has a right to their input. Screenplays can actually be quite flexible creatures and bend to incorporate lots of new ideas – as long as you keep that all important core intact.

· Know that you don’t have to implement every note you’re given
Experienced writers like Beaufoy and Jordan know that a writer will not have to implement every note they get and you should not sweat blood trying to do so. As long as you address a good percentage of the concerns that are voiced and the material moves forward your development partners are unlikely to keep harping on about one or two small points. This may not be, as Jordan jokingly suggests, because they’ve forgotten the notes they gave. It probably wouldn’t serve you well to assume that the majority of developers are stupid and don’t realise if you’ve just gone away and tinkered with a script rather than addressing the major issues. A developer may not bring up notes you didn’t tackle because they’re picking their battles. Perhaps the changes that you have made have dealt with their main concerns. Maybe the developer realises that a previous note doesn’t matter now with the solutions that you’ve found, or maybe they have so many new, major notes that they’re not bothering with their old ones! Once again however, the principle remains true, whether dealing with an idiot or a genius – if you successfully get to grips with most of the major development issues at stake within the script then the rest of the notes may be allowed to fall by the wayside.

· Try to get notes from one source
Just as a good developer might have an eye to protecting a writer from a deluge of contradictory notes, so writers can be aware of this themselves. After one such excruciating experience Beaufoy now asks that all notes on any project come through one source. Obviously he’s highly successful and therefore has a little more clout in asking for things. However, there’s no reason why any writer couldn’t at least ask for this, if it’s clear that there are going to be lots of notes from different sources. It’s not a particularly weird or demanding request, so why not at least try to start as we mean to go on.

In the end perhaps the best advice when approaching the development process is to hope for the best and prepare for the worst. Don’t assume the producers, executives and script editors you meet will be idiots who don’t know how to work with writers. You may find the process to be a joy and a pleasure, a chance to gain real insight into the progress of your work, like a breath of fresh air bringing new life and energy into the process. They might be like a firm hand on the tiller helping keep all aboard on track. Of course on the other hand you may find you are lost at sea with a bunch of mutinous monkeys all chucking their ideas around like faeces. If so, you can take the advice of writers like Beaufoy; take a deep breath, quash your inner hissy fit, take your notes home and attempt to sort the shit from the Shinola. My advice to you is when you find people to work with who can offer you the former, whether producers, directors, editors or writers, build those relationships and keep them with you as you go. Good notes may come from any source, but while the basic principles of good development are still not broadly accepted or understood, (even by some writers), that taste of development heaven may still be harder to find than development hell.