What It’s Like to Write Software on a Team

Imagine you are on a team tasked with writing a novel.

At first you all huddle together and figure out what it’s about. Who is the intended audience? What will readers take away from the book? You hash out the arc of the story, the characters, how they’ll interact with each other to drive the plot forward.

Your team starts to storyboard, passionately debating each other as you bring this story to life on the whiteboard. You squiggle, you erase, you draw diagrams and write a few paragraphs here and there to show that this story can work. You align on a vision of what this novel will be. 

And then, the real work starts. You open up a shared Google Doc, and each person takes a chapter, or a portion of a chapter, and starts writing, at the same time. Some people take on characters instead of chapters; others focus on a specific event in the story, perhaps the climax or a scene of rising action. This is fine— it takes some planning, but you can write your part as your teammates write theirs, as long as you all know what everyone is working on and how your part interfaces with everyone else’s.

Sometimes someone has a brilliant idea to change how their part reads: maybe they want to end their chapter on a cliffhanger, or engage in a little foreshadowing. What they do in their section affects the sections before and after as well, and so they must communicate to ensure the novel flows logically.  

Then there’s the question of voice. You want the novel to read smoothly and consistently, and not vary wildly from chapter to chapter. Not only does this make it pleasant for the reader, it also makes it easier for someone to come in and make edits in the future. So teams must agree on what that voice is, and must edit each other’s work to iron out the differences in style. This means agreeing on mundane things like whether to use oxford commas, as well as on more subjective things like how funny or formal you want the characters to sound.

Now let’s throw in some illustrators and designers into the mix too. They’ll play with fonts and sizes and colors, as the Google Doc continually unfolds. They’ll design a book jacket, and maybe add some drawings or graphs or photos. Ideally, they make their designs bespoke for what you’ve written and it’s exactly what your team wants. But sometimes they may draw something that doesn’t fit the tone you’re setting, or illustrate a scene that has changed given the latest edits. You need to work with them to modify those artifacts, as your team continues to write this book.

Sometimes people from outside of your team will want to have a say in what you write. Marketing might come to you and tell you that your novel needs a vampire to be commercially viable with teenagers. Sometimes legal wants you to take something out— maybe you can’t call your villain Vuelo de Muerte because it’s too close to someone Who Must Not Be Named. You have to negotiate how you write those things in, and sometimes you’ll win your battles but other times you just have to throw in a werewolf because the folks upstairs want one. All this while the Google Doc is continually evolving.

Writing a sizable novel in this manner will take some time, and as a result, maybe the team grows or churns as well. The original storyboarding must be clear and instructive enough, and the writing in the Google Doc must be consistent and cohesive enough, that a new person can walk onto the team, spend some time familiarizing themselves with the story, and begin editing and writing where someone else left off, without any noticeable difference to anyone reading.

Finally, at the end of all of this, your team produces this book. It is a work of art. You know how much effort went into it, and you are more astounded than anyone that it is a cohesive, comprehensible, dare you say enjoyable piece of literature.

And that, in a nutshell, is what it’s like to write software on a team.