Ok. So. Status meetings. Planning. And communication.
If I didn’t know any better, I’d say I was teaching a shitty project management seminar at the community college. Or living my recurring nightmare, where everyone just talks in management buzzwords.
I work as a computer programmer in a pretty classic office environment. Cubicle walls. Motivational posters. The dull hum of the A/C unit directly overhead. Awkward coffee pot etiquette. But the work is interesting, and I feel capable and accomplished in doing it.
This year, I went in for a ‘lead’ position among programmers and somehow got it. The new position, while putting the ever-prestigious ‘Lead’ in front of my title, doesn’t really having me leading anyone or anything. I mean, I can inform decisions, and make recommendations, but I can’t really tell anyone what to do. Which, to me, is pretty perfect.
I like what I do, and I can’t really see myself being any happier if I ever get promoted to a management position. Management seems like one of the most boring things in the world, filled with budgets, due dates, and endless meetings. You are responsible, for better or worse, for your decisions and those underneath you. All that, and you don’t even get to swing wrenches anymore. Which is what turns me off the most.
I’ve heard similar from other programmers (a preference to stay technical), but not as many as you would think. Not all programmers are die-hard code monkeys, looking to sling/fling code all the live-long day. A good number of programmers are only programmers as a stepping stone to greater career aspirations. They have some talent in the technical realm, but they don’t enjoy it. They have a love for the sea, but maybe they don’t want to spend the whole time swimming in it. The details can be uninteresting, and probably those looking up the ladder would rather deal with the more abstract and larger-in-scope aspects of technology. The system architecture. Design. Requirements gathering. Whatever.
That, or they more enjoy telling other people to do those things.
I don’t really ever want to be a manager. But I can appreciate what they do. And not just in a “I’m glad you’re doing it, and not me” sort of way. Managers, to me, have two very difficult jobs, answering two very impossible questions:
- What should be done?
- Who should do what?
Being a successful manager is finding good answers to those questions. Answers that save money, time, and keep as many people happy as possible. I say they are impossible questions to answer because there is never a right answer. Or at least not “right” within the narrow band of perfection I have become accustomed to in my career dealing with flawless automatons and strict determinism. Nobody will be perfectly happy with a choice you make for them, even if was a better one.
So. Why go on about all this? You thought this was a blog about writing, wherein we discuss the subtle art of putting ideas to paper and maybe talking about what it’s like to co-author a book. Not some weirdly entitled rambling about that one time an office worker got promoted.
Well. If you’re writing with someone else, and you’ve outlined all your things and you’re about to start writing, there are two, very important, and very impossible questions you will be faced with:
- What should be done?
- Who should do what?
You may notice that these two questions are the same as those above. Which sort of implies that co-authoring a book is as much about writing as it is about managing the writers.
You will, at some point, reach a point in your project, where you will have a list of things to do. That list will probably look like your table of contents, or even your scene listing depending how deep you went with outlining. You might look to your co-author and shrug, haphazardly suggesting, “Halfsies?” You might even go so far as Mike and I did and just choose to go down the chapter list, interleaving Mike-chapters and Josh-chapters in an AB-AB rhyming scheme.
If you’re at that point, and you have the opportunity to be reading this, stop for a moment. Pause. Consider that an AB-AB rhyming scheme isn’t all that spectacular. And consider that it is rare that things in life are as easy as they seem. Rare, tending towards never. Consider that you have a management problem. You will have to find a way to manage each of your time and resources in a way that gets things done and hopefully keeps everybody happy.
Otherwise the project fails.
If you reached the same conclusion, please, benefit from our hard-fought list of things we discovered as we tried to manage writing a book together.
Not all chapters are created equal
Not by a long shot. The first chapter? The one that’s supposed to grip the audience? The audience you haven’t met? And agents you don’t know? And their assistants, sorting through their slush pile after lunch when they are tired and sleepy and want to go home? The part of the book that will probably be given away for free on the Amazon book preview in an effort to show the world what caliber of literary artists you are and ultimately determine whether they hit ‘buy’ or just keep scrolling?
Yeah, that’s not going to be the same amount of work as the filler chapter where the main character has a good time going fishing.
First chapter. Last chapter. Action chapters, where you’ll scrutinize every action for whether it is too Jackie Chan, or not enough. Heavy dialog chapters, where the characters have to deliver tons of exposition while sounding like real, relatable people that readers will identify with. Chapters that switch point-of-view, or use a different tense, or storytelling mechanism.
They will all have wildly varying difficulty. You can certainly try to guess if a chapter will be a challenge, particularly if you’ve never written something like it. Just know that your guesses will probably be wrong.
Not all chapters hold equal interest to the writers
There. I said it. Sometimes, I just don’t care about the worldbuilding chapters. Of every thing I ask, “Why is this relevant? Why should I care? And why should the readers care?” And I have to realize that I am not every person. Not everybody buys a coffee table book about the history of word processing. Or buys Craisins by the four pound bag. Not everybody enjoys reading about the same things, and more importantly, not everybody enjoys writing about the same things.
When Mike and I divvied up our chapters, we didn’t always consider what we wanted to write about. For instance, I like my worldbuilding in the background, barely present, dripping into your heart through a pinhole until you realize you’ve been steeped in it. But for the chapters that need it, no, demand it, I find it difficult. The geopolitics of a place I’ve never been only interest me slightly more than the geopolitics of a place I’ve always lived. However, a chapter needs a throwaway sentence about a fictional magic system? I’m on it. That’s where I live. There’s where I feel strong.
Be sure to consider what your interests and strengths are when assigning chapters. Otherwise, you get Josh yadda-yadda’ing through some important world history, and Mike yadda-yadda‘ing the critical principals of flight to your pulp airship fantasy.
Not every chapter is one chapter
There. I said that, too. Though, not exactly as cathartic as the last. Basically: you might be writing a chapter, and suddenly realize it’s not just one chapter. In that case, you have some stuff to figure out. And likely, you’ll need to talk to your writing partner to hash out a bunch of stuff.
We had a pretty classic case of this with Volume 2 of Skysail. We had a chapter that we just called ‘Travel’. The original notes just said, “Traveling,” or something equally vague. We intended it to be our first foray into the actual traveling aspect of our world. After all, you can’t just be on an airship and not satisfy a little wanderlust. However, we quickly figured out that we couldn’t just have a ‘travel’ chapter, cutting from place to place. It didn’t fit with the tone and pacing we had set so far, and we still had a ton of story to tell.
That single chapter turned into five. And introduced complex action scenes, mysteries, dialog, and all sorts of things we didn’t intend. And, at the outset, they were all assigned to me.
We divvied them up later. But the point is that these things have a habit of ballooning unexpectedly. So expect it.
Not all chapters can be written right now
In fact, I don’t know how we really started on any of our chapters, other than just blindly mashing keys and hoping it turns out for the best. Every chapter we wrote has some degree of dependency to it, whether it is plot reference, character reference, forward and backwards consistency, or even just flow between one chapter and the next.
The problem is there is no root to all those dependencies. No one single place you can start from to say, “Hey. Everything starts here. So let’s get this part down first.” Your first chapter will depend somehow on the contents of the last chapter. And your last chapter will depend on the contents of the first.
The point here is to acknowledge this dependency and then try to move past it. Find chapters that, even if they have dependency, seem to have less of a dependency than others.
If you have to whiteboard it all out, do so, drawing lines between your table of contents entries.
(Above: the original Pacman Source code, with lines drawn to show conditional and looping jumps that occur during execution. From Ben Fry).
Best case scenario: you find natural breaks to your story that you can use to split up the work. Worst case: you identify all of the things you both need to agree on before you get much further.
Two people can’t do the task of one person in half the time
In fact, there’s nothing that says it won’t take at least at much time as one person, if not more.
There’s been tons of study on the topic, but most of the phenomenon I’ve experienced firsthand in my programming career. Many hands are supposed to make light work, sure, but that’s, like, when you’re moving somebody’s couch. It’s not the same thing when you’re trying to design software, or, for that matter, writing a novel.
Novels have dependency (described above). Many hands make light work, but only if those hands can be directly applied at the same time. Some tasks can’t be done at the same time. Two people can’t work on the same chapter, same as two programmers can’t (easily) work on the same bits of code. They can work around it, or come to agreement on a common element in order to work separately, but generally they are serial tasks. Tasks that cannot be executed in parallel.
It gets worse. With every added worker, there is added inefficiency. There is increased need for communication, and increased likelihood of having to stop one person’s task to address another’s. There is friction, wherein two workers disagree on something, and therefore, cannot proceed without coming to some conclusion. There is the slipping of gears, where something catches, or breaks down, or misses a tooth when transferring work between systems.
We’ve suffered all of these in our project. Where some novelists can crank out a publishable piece in a year, it’s taken two guys four years.
Many hands don’t make light work. Many hands make a lot of work. But in the end, we are creating something that neither of us could create alone, so the ends justify the means.
There is an idea in computer science called reduction. The Wikipedia article states it better, but essentially the idea is that if two problems can be solved using the same solution, then those two problems cannot be more ‘complex’ than the other. Reduction is fun, because if you can mathematically prove that a problem can be ‘reduced’ to another, then you have mathematically proven that a problem has a certain complexity without actually having to figure out its complexity. Computer scientists get off on that.
But I don’t really consider myself a proper computer scientist. I have a degree in the field, but I can’t really say that I’ve directly used all that many of the theoretical concepts they taught us. We learned about the nature of complexity, and what about is computable. Both of which are great to have at ready when someone asks you why something is ‘impossible’ and you can pretentiously inform them that it is ‘yet unsolved by computer science.’ But I’ve never sought to ‘reduce’ anything since I graduated. I’ll probably never contribute to the field other than evangelizing to rudderless college students that you will never want for work if you can program a computer.
So. I’m a bad computer scientists. Which is why my hijacking of the idea of ‘reduction’ isn’t the best. There is no algorithm that applies to project management that can then be re-used to solve something in novelwriting. I have no real way to show that they are both of the same complexity.
But I can say that both are complex. Both problems involve humans. Squishy, weird mammals that taught themselves agriculture and how to type. And that wrangling those strange creatures to do work is a difficult, nigh impossible task.
Some time after I had gotten the promotion, my dad asked me if I would ever want to be a manager. I told him what I told you, dear reader: “Not really.”
He nodded, then told me he used to feel the same. But then when he got into the position, he found that he sort of enjoyed it. He could dictate how technical he wanted to be, how close to swinging a wrench. But more importantly, he had the agency to make the right choice where somebody else would just fuck it all up.
Managing people and managing a book aren’t exactly the same things. But they share some of the same complexity, and the same problems. And, to some degree, they share the same idea of responsibility and ownership. We might be writing the worst airship fantasy book out there. And it might be a little bit narcissistic to say, but if somebody other than Mike and I were writing it, they might just make it worse.
There’s some satisfaction in that.
