Attempts at grasping management of writing a book in groups

02 Oct, 2026

Wait what

Homework.

Creative work and the need to deliver

I've heard about video makers in YT (often known as YouTubers) that they consider heavily the title and the thumbnail of their videos before starting work because they want the videos to be successful. Normally in pure creative work there's a very loose definition of success, but in the case of doing creative work for a living the mark becomes clear; "we need to eat".

In my case the criteria of success is better defined. An academic book ¹, being done in a team, about something concrete, that must be done and possibly printed by December.

The theme is videogames. An academic book about videogames, gamedev and gamedesign. This doesn't free us of hard topics. Here's an 'introduction' to game design. (not really an introduction, each of those paragraphs could be (and probably is / are) multiple books). Learning how to make a videogame is easier than ever, you could follow a tutorial on youtube (and there are some great tutorials!) and have a great working game.

I promise, being sincere, if you want to learn to make games and make one yourself, now is a great time to do so (also, its fun!).

But if you're buying a book about videogames (and an "academic" book, nonetheless), then I'm assuming you're looking for something else than a tutorial, something that cannot be conveyed through tutorials.

So this is a research project. Great! I love research. But there's no such thing as JUST research. There's a great deal of creativity being put into choosing what to say and how to say it; you're not free of choice of words. And there's an additional constraint about making an unique project, which in our case probably means making a game too with what we do (or making baby's first House of Leaves). And there's the fact that we're working in groups, so there's group coordination.

Part of the assignment is choosing a group leader. And grading the group leader on good of a leader they were. I guess that's me, given how we've been working so far.

There are other constraints like presentation format, design, page count, etc. Not necessary to mention extensively here, except design. I don't want any AI made asset in the final presentation. I cannot control how each member works - nor is it desirable, but there's a review phase. Quality Assurance. That's a good moment to replace AI assets².

Here's the outlook. This leans closer to research projects, so it becomes hard to plan for this because you can't plan for insight and creativity to happen. There's also the design work and format work that must be conducted, along with review phase and coordination in group, all of this feeds into the performance of the chosen leader. In a time constraint of two months, give or take.

Structure

Where do I even begin setting up an structure for the project?

Alright, first of all. What do I know right now about projects? You understand your problem. I don't know how much this is generalizable but I've observed that the best ones (in various areas) spend a ton of time getting to know their problem, rather than jumping into action quickly.

And I've noticed that I'm confused. Because I know the obvious pain points that I've raised, but I don't know the unknown pain points that may come that I'm unaware they exist.

Methodology, methods, techniques and tools.

• Methodology: Serves as a framework behind the work being made. The broad philosophy of inquiry. SCRUM is a good example here. Defines the why behind an approach, the system of principles and reasoning that justifies how and why you do things.

Quantitative vs qualitative vs mixed methodology. A large etc.

• Method: Structured procedures inside a methodology. About what you do. Planned, step-by-step strategies to achieve something.

Interviews, focus groups, observation, a very very large etc.

• Techniques: Specific way of executing a method. How you do something. Practical skills and/or procedures to carrying out a method.

Semi structured questioning, active listening, probing, another huge etc.

• Tools: Physical and/or digital instruments to apply a technique. With what. They don't do anything on their own, they support the process.

Voice recorder, transcription software, excel. Another etc. But large use of excel.

I mention this because this gives me a lot of clarity on how to approach this project. Of course, there's no clean transference between research methodology and writing a book³ (unless you're writing a book filled with research, not my case). But there's also not a clean cut from writing and research.

Writing about writing

There are tons of schools of thought about what is writing and how it should be thought of. Its good to know; and its interesting, too, but not largely useful for my case⁴.

The really interesting one I've found is Cognitivism (Flower & Hayes, 1981)⁵.

As every writer knows, having good ideas doesn't automatically produce good prose. Such models are typically silent on the inner processes of decision and choice. (Flower & Hayes, 1981, p. 367)

Thanks. Good to know.

"Pre-Writing" is the stage before words emerge on paper; "Writing" is the stage in which a product is being produced; and "Re-Writing" is a final reworking of that product. Yet both common sense and research tell us that writers are constantly planning (pre-writing) and revising (re-writing) as they compose (write), not in clean-cut stages. (Flower & Hayes, 1981, p. 367)

At the risk of citing too much and leaving too little of my own thoughts, I prefer to put an extract of the article here that I find particularly sobering.

3. Writing is a goal-directed process. In the act of composing, writers create a hierarchical network of goals and these in turn guide the writing process.

This proposition is the keystone of the cognitive process theory we are proposing and yet it may also seem somewhat counter-intuitive According to many writers, including our subjects, writing often seems a serendipitous experience, an act of discovery. People start out writing without knowing exactly where they will end up; yet they agree that writing is a purposeful act. For example, our subjects often report that their writing process seemed quite disorganized, even chaotic, as they worked, and yet their protocols reveal a coherent underlying structure. How, then, does the writing process manage to seem so unstructured, open-minded, and exploratory ("I don't know what I mean until I see what I say") and at the same time possess its own underlying coherence, direction, or purpose? (Flower & Hayes, 1981, p. 377)

If any of this proves interesting, please look up and read the rest of the article. It's a very good read, clarifying and robust. Sanity inducing for me.

Either way, from this point on Flower and Hayes propose that writers create a network of goals as they go into their main objective. This includes high-level goals like "write an introduction" and local-level goals like "explain things simply".

This does not mean that a writer's goals are necessarily elaborate, logical, or conscious. For example, a simple-minded goal such as "Write down what I can remember" may be perfectly adequate for writing a list. And experienced writers, such as journalists, can often draw on elaborate networks of goals which are so well learned as to be automatic. (Flower & Hayes, 1981, p. 379)

Next, they elaborate on how writers often "come back" to their high-level goals as they write. Since writing is an iterative process.

Our understanding of this network and how writers use it is still quite limited, but we can make a prediction about an important difference one might find between good and poor writers. Poor writers will frequently depend on very abstract, undeveloped top-level goals, such as "appeal to a broad range of intellect," even though such goals are much harder to work with than a more operational goal such as "give a brief history of my job." [...]

[...] Therefore, one might predict that an important difference between good and poor writers will be in both the quantity and quality of the middle range of goals they create. These middle-range goals, which lie between intention and actual prose [...], give substance and direction to more abstract goals (such as "appealing to the audience") and they give breadth and coherence to local decisions about what to say next. (Flower & Hayes, 1981, p. 379)

Alright enough of this. This is workable enough.

What really bothers me

Is working in groups.

Its good and interesting to know more about writing. I have a very loose writing technique and I can surely say that "it just works" for me and its good enough⁶. But what bothers me is that this is personal knowledge, hard to transfer to other domains and people in a way that's needed here.

I realize most of this research is a form of productive procrastination. Researching how I should work in groups isn't the same as working in groups. Most groups of writers that did write a book didn't know this (probably) and, therefore, didn't need to know this to finish a book.

But I feel safer this way. I like having a structure to rely on, but I know very well the dangers of spending too much time building something rigid. Before you notice, you have a notebook with at least ten pages full of rules and guidelines about how you should write a notebook.

I need to have an structure. I can't run up ahead like a chicken with its head cut off. But I cannot prison myself either in structure or we'll never get anything done. Specially now that we're talking about a project involving creative work.

A structure for not running ahead blind

There are guidelines and processes to writing an academic book. And to writing anything, really. Most commonly regarded as "structured writing" and "free writing". But work on projects often looks more like the snowflake method. Where you begin on the very core of your story (or topic) and expand from there.

It seems we'll have a looser structure. Very much in the form of "considering this, do whatever you want while you work up to this". Because we have a very broad set of skills and interests.

But we need some things to anchor us. At least to keep simple the things that would otherwise become a nightmare.

These things will need constant maintenance.

• Style guide. It would be a good idea to define firstly the style of writing this book and keep it somewhat consistent across authors.
• Glossary. Unique source of truth for technical definitions. Shared across all of us. I hope this will avoid us like 90% of inconsistency across reviews.
• Versioned outline/index. Its expected that whatever shape our table of content has right now will change and evolve across the lifetime of the book. We should keep this updated at all times.

The general outline serves as the main objective we work towards.

As for personal writing, idk. Do whatever works for you. But I think this is workable for me here.

1. Outline. Bullet points. No prose.
2. Draft. Expand each bullet point into prose and content. Badly done but done.
3. Structure review. Whether what I'm saying makes any sense.
4. Clarity review. Whether what I'm saying understandable.
5. Rigor review. Citations, references, technically true affirmations.
6. External review. It has to be reviewed by someone else. Nothing gets out unless its reviews by someone else.

As for organizing the work you do.

• Block time for and for writing. Don't do research while writing, that's a bad idea.
• "Reserve" document. While you're writing, put ideas there that don't belong in your current document but you want to keep.
• Define goals by week, not by day. As some days you just don't write that much, and other you write the whole document.

Iterative. We'll need probably a lot of experimentation to get a workflow going, but I think it's something we need. Like, need need, is a way to mix ideas between us in a safe way. Creating a safe place to fail and to experiment.

In practice, this means that we should probably work in a shared wiki before putting it all into the document. Like in notion, or a google docs. Where I'll put all my material and references and drafts. And hopefully everyone else put their material there too. Of course, expecting all material to be public is insanity, but at least the references and outlines. On reconsideration, this is a bad idea. For projects that require higher levels of coordination, sure, its useful. But for this... we'll arrive when we arrive. Premature optimization is the root of all evil.

Regarding framework... There's mixed results on this. I want to elaborate more on this, but, I'm tired boss.

• One-for-all - One person writes for the team.
• Each-in-sequence - Draft passes person to person.
• All-in-parallel - Split into discrete units, simultaneous.
• All-in-reaction - Real-time mutual adjustment, no pre-planning.
• Multi-mode - Combination over the project.

(Lingard, 2021, p. 163)

The final work will probably lean more into All-in-parallel work. Mixed with Each-in-sequence for review. We'll probably need to mix and react to whatever happens.

About the central topic... The way we've put up the work so far, it seems like there'll be a central question that must be answered from a variety of perspectives. Each of us carry a different expert hat. This enables us to be way more flexible in output and content, and also allows us to work in parallel. Though the main idea was to have different experts chip-in in other articles. Ever heard of Disco Elysium?

Then there's this structure.

• Main question. Answer it.
  • Different POVs answer from different perspectives.
    • Thus, different POVs set up a network of minor questions.
  • POVs react to other POVs. Mixing of knowledge across domains.
  • Expand beyond what a tutorial can teach you.

Main problem.

Schelling point

I'm sure most of this won't be useful at the end. I'm writing for an "ideal" workflow of one hour documented and all. But in reality, what will probably happen is that this homework will be put in hold until the presentation day and then done one hour before due date. I'll be guilty of this, probably, better be ready for it.

When I was in high school, I had many tasks about writing a summary of a book. A short one, each week. If not a summary, a comic, a poem, a presentation, etc. You know the drill. I've read the books, almost all of them, eventually, because its interesting. But I remember almost never doing the homework. Back in my days, we cheated homework without even reading the book. It took creativity in its own way. At least in a way that prompting an AI doesn't.

I think I can trust that everyone will use AI for this. I hope not in the sense of "write the whole chapter", but for outlining, research topics, bullet points, design, I can go on. I personally don't use AI in a way that leads me into dependency on it, but its still a useful skill to know how to use correctly. Also, AI is a very interesting technology, and very impressive, I can't help it, I'm a moth in a campfire.

And it just so happens that its standard to use skills and agent files to model behavior. In many projects there's a file called AGENTS or MODELS or something like that. It fills context. The thing that's most probably going to cause problems when using AI is the lack of context; you say "I want you to make me an outline", and the outline will be everything except useful because it doesn't know what it needs to be. These files fix that, establish protocols and behavior that the AI must follow and make them more useful and less prone to making mistakes.

As a fallback, I'm writing and maintaining a MODELS file that tells the agent the relevant context of the book. It limits it space of action (don't write text meant for the finished book), knows the structure and workflow of the project, and knows how to help. I hope with this I can both make the usage of AI less problematic for the project, make using an AI more useful, and increase the overall quality.

This is not ideal, but its a fallback. I prefer to accommodate for most workflows rather than enforcing a structure that handicaps us. Who knows? Maybe this way leads to people caring more about writing.

Can you actually teach beyond what a tutorial can teach you?

Let's figure it out. This would be so much easier if we weren't LARPing as experts in the industry. ⁷

This is not an exit

My punishment continues to elude me. And I gain no deeper knowledge of myself. No new knowledge can be extracted from my telling. This confession, has meant nothing. (Harron, 2000, 1:37:27)

As stated before, this is a form of productive procrastination. Kinda. I have many more neat entries in my zotero and now I feel more at ease by writing about writing. And also, now I have a broad draft that may become actionable steps. Though I really should thin the amount of steps I have to take until I finally write an article. I know! I'll set up processes to make it straightforward to just write! ⁸

At the end of the day this is just another group project. I've done those. I'm overthinking and I've put that into a blog post. Sorry, I'm addicted to the sound of the voice in my head. Its because I'm excited, this is a cool work to do, but the scope scared me. I'm at ease now. Truthfully, I feel more confident on what are the next steps.

An exit

Its helpful to do free writing and then edit. I've written this some days ago and I'm editing later. Its very useful to edit.

Maybe what I need is a clear separation from the research side, the creative side, and the editing side. I need to give each of these its space to bloom without derailing the whole project.

#thoughts