Lessons Learned While Leading a Narrative Design Team

Last April I made a huge step in my career and got a job as a lead narrative designer. I didn’t know what to expect and what to do: before that, I always worked alone. So I launched up my browser, went to google, and looked for a talk or a lecture on how to lead a narrative team. What I found startled me, I was so surprised and mesmerized.

There was NOTHING.  

Well, not nothing at all but rather nothing substantial. So a year and a half passed and the release of the game is upon us. I’m in no position to make a guide for leading a narrative design team. What I can do is tell you some things that I learned.

Team Setup

Just to give you an idea to what I was dealing with.

A lead narrative designer (English, Russian), a senior narrative designer (Russian), a junior narrative designer (English, Russian), a translator (English, Russian).

1. Write less yourself.

In the ideal situation, I should’ve concentrated on effective management, revision, and editing. But nooooo, I like writing too much. Which eventually was hard to juggle at best.

Screw that, though, I still like writing. I’m not ready to put the pen down.

2. Set up a virtual writer’s room.

Reasons for this are selfish. Basically, I’m lazy and wanted to go to Vilnius for a week two weeks after getting hired.

I set up a trello board to work as corkboard with post-notes. Every card was done in the same fashion as should it be user stories. Name of the episode/level as a card name, outline and a link to the main file inside. While I was away, we used it as a visual aid on skype calls.

I enforced Google Drive, Word, and Spreadsheets as the main tool. We had a definitive place for all things story with a uniform file format.

It gave us easily presentable production plan, I can always know and show who is working on what. Other team members have easy access to short files on every episode.

3. Ordnung und disziplin.

I used to be a producer on agile managed projects. I had a vision for my team to work as a scrum team on narrative. I was sure that would work. I didn’t follow through, though.

It required discipline, weekly reviews, revisions, meetings and keeping track on the tasks at hand with exact precision. None of which I was able to achieve.

Concentrate on getting the processes right first. That would result in a faster and more efficient work. Or a total disaster.

4. Ensure cuts and rewrites are perceived as a healthy practice.

I worked with the team to ensure that they see the result of rewriting and cutting. The results are obvious to me. Scripts aren’t written, they’re rewritten. Guys didn’t have the same perspective.

Here’s the key: It’s okay to rewrite if there is a foreseeable end to it. I’ll talk about it later pro.

Here is how my perception of the whole story went from rewrite to rewrite: Utter crap, miserable shit, shit, acceptable. In my book, that’s a win.

5. Write in one language.

I doubt this happens a lot but we’re talking about my experience. So out of three guys on a team three could write in Russian to various extents and two in English to various extent. It makes it logical to write in Russian, right? Well, not for me.

We write in both. That is me and the junior write in modern lingua franca and the senior in Russian. This produces a lot of friction, however, both I and the senior are writing in the language we prefer. The junior is stuck in between but they always do.

Solutions for these are easy:

All write in Russian! At which point I’d probably quit.

All write in English! At which point I’d have to fire the senior.

6. Filter feedback.

Rest of the team is welcome to provide feedback and offer solutions to the problems they identify. We’re welcome to ignore or implement that.

I see my job as a filter between them and the team. The feedback in its raw form is often useless or even harmful when delivered from non-writers.

You can rewrite a synopsis endlessly based on just feedback. This feedback may hurt your confidence and destroy your fighting spirit.

What I see as the most important part of my job is translating feedback into solutions and ideas that one can work with.

For example: “This character’s actions are irrational.” can be treated as “Character’s explanation is off.” or “Not enough foreshadow for the action”. It can be ignored because the guy who gave a feedback is hell bent on having logic control everything.

Ensure your team gets only the constructive feedback. It ensures more appropriate iterations and less alcoholism.

7. Mentor your team.

I suck at conveying my way of thought to others. Why do I think these dialogues are good and these aren’t is an impossible question to answer for me. I can provide feedback but once it’s done precisely, I’m still not satisfied.

I can provide better solutions to their problems but not the explanation why. Unless I spend a couple of days decomposing that. Which I do preparing for lectures and talks at the events.

Mentoring is important and I’ve considered training this by teaching a course for kids. With that in mind, I could’ve built a lot of trust and avoid many unnecessary rewrites.

8. No common character.

When I first got a job one thing terrified me the most: a team of people writing a set of characters.

I did the only logical thing - asked for an advice. Good Guy Chris Avellone suggested assigning characters to writers. That is every character worth having a name has a writer attached to it.

It sounds simple but I had no earthly idea we could do that. We assigned characters sometimes based on skill and background (I write assholes), sometimes for educational purposes (Guess who got a generic soldier type).

It creates Character-Writer bonds and a responsibility for a character.

9. Writers must script.

Maybe it’s just me, but I believe a narrative designer has to be able to script his story in an engine. It’s no problem for me since I started my career as a scripter. For others - not so much.

We hooked up the Inkle writing engine (Super simple by the way. I repeated the process at home and it took me like an hour tops.) and I forced my designers to script their episodes.

We skipped the documentation stage entirely. Took the coding of a story from the programmers. We also gained some more control over the story implementation.

Conclusion

Here are some lessons I learned while working on Panoptes for Suricate Games. I hope they will help those of you who are transitioning into a leading role.

To those of you who already are in a leading role:

Write a proper manual so I can stop this lunacy and salvage the freaking project, would you kindly, please?