About the author

Kikkan is a game designer and longtime Otomad fan. He has been active in organizing various projects related to Otomad in the past few years.

• X/Twitter
• Niconico

Originally published in Japanese. Authorized translation by Brando.

Collab Delays Are All the Failure of the Host - KochiYoko

Before anyone misunderstands – I am writing this simply as a response to the above article. I view things quite differently than the writer of that article.

That said, I can understand the intention and circumstances behind the article, and there are many points I agree with.

The worst thing to do in situations like this is view things in a black-or-white way. I’d rather present my opinions as “I agree with this part, but disagree with that part!” (In fact, I’d say the black-or-white discussion about the original article is my biggest problem here…)

I hope that this article will not be instantly swallowed up by twitter, but rather lead to constructive discussion, and will give people a chance to reconsider what it means to organize a collab. I don’t know if what I’m writing will garner support, but that would still be enough for me. It’s not like there’s a single right answer to this discussion.

Article summary in three points:

1. I agree blaming only the participants is silly.
2. That said, excessive management can destroy friendships and people themselves
3. Hosts should think about how to get their participants to do their best on their own

I will now elaborate on each point
Also, I’m ignoring the original author’s background for my arguments. Saying stuff like “This isn’t convincing coming from someone like you…” doesn’t help constructive discussions. Let’s put that aside.

Foreword: Lack of Vision

As an Otomad fan, this is the part I object to the most.

For starters, I think it’s very effective for the Hosts and collab managers to have a strong vision for the project. Sharing the vision with the participants and working towards it allows for a true “collaborative work.”

I will now refute the following section:

There is no Hierarchy in Collaborations

…Far too many Otomad collabs are produced with the childish desire for people to casually work together, like in a school festival.

Meaningless collabs are a sin.

In the original article, the writer seems to be equating “collabs where participants are late” to “collabs where the host is being reckless and doesn’t do their job.” I understand these words are not criticism of the contents of the collabs themselves, but rather aimed at the hosts themselves.

Even so, I cannot overlook the way it dismisses the existence of casual collabs. As I have written in a previous article, each project has a different level of seriousness to it, and that should be communicated to the participants as well.

There has been an increase in collabs with excellent concepts and overall consistency. As someone who loves concepts, I find this wonderful. However this shouldn’t mean we, as a community, need to establish strict rules and regulations about what a collaboration “needs” to be like.

Just as participants aren’t always fully committed to a project, there’s bound to be projects and collabs that hosts want to tackle in a more easygoing way. I believe that is perfectly fine – as long as everyone is on the same wavelength.

In short, I believe there is no hierarchy between collaborations. What’s far more important is that the participants understand the required direction and level of commitment. Depending on what you want to do there might not even be a need for a “vision” in some cases.

Basically, even an in-joke collab or a loose one holds meaning to its participants as long as it’s achieved its purpose. There are plenty of Otomads that can be described as “lacking context” or “meaningless” and still be acceptable. On the other hand, it would be hard to explain the meaning behind a collab, no matter its quality, to someone with no relation to it.

What I’m trying to say is: It’s nonsensical for a third party to label a collab as meaningless or a “sin”.

Chapter 1: Dysfunction Caused by the Host’s Negligence

I, Kikkan, will now provide my counterarguments as someone whose work involves planning and executing projects.
Think of it as someone in the video editing industry talking about videos.

Many hosts simply assign parts, set deadlines, and then sit back and wait for submissions, essentially abandoning the collaboration

Have you ever noticed the distress signal the participants are sending when they say “I’m busy?”

I fully agree with these statements. Just setting deadlines might as well be delegating the process entirely to someone else, and there’s a good chance “I’m busy” means more than just that alone.

Also, as mentioned in Chapter 2:

An incompetent host will panic and try to respond after tardiness occurs. A competent host will take actions to preemptively eliminate a risk of such issues arising in the first place.

I believe taking preventative measures before a problem occurs is a good thing.

However.

I have several points I disagree with in regards to the measures suggested in the article.

Psychological Safety

Participants are afraid to voice such issues because the host has failed to foster a psychologically safe environment where such issues can be announced early enough.

First, let’s talk about the term itself that is being used here. “Psychological safety” refers to a feeling of security within a group, where people may speak up and take action without fearing repercussions. The term has been popular in the business world as well lately.

If you announce a delay, you might seem unmotivated. If you ask for advice, you might seem incompetent. This sort of fear keeps the participant silent until the very last moment.

That certainly sounds like a psychologically unsafe environment. A fairly plausible scenario.

When the concept of psychological safety is brought up, the focus is often how to foster a psychologically safe environment. The article in question, however, does not bring up any such methods.

Reading deeper into the article, it seems the author is not arguing to improve an environment where “the participants keep silent until the very last moment” but rather to compensate for something like that with extensive progress checks and micromanagement (as described in Chapter 2).

Let’s think about this from the viewpoint of a participant. Imagine a collab atmosphere where you find it difficult to speak up to the organizers. Nothing changes, and you keep getting hit by one progress check after another. Would you want to participate in a collab like this? Let’s assume you felt uncomfortable – would you feel secure enough to say “Please let me leave this project”?

If it were me, I wouldn’t want to participate in it from the start.

The article then goes on to state:

In many cases, “being busy” is an excuse to hide their true feelings. Things such as “I’m struggling to come up with an idea,” “I’m having trouble getting the part to look like I want,” or “I’m lacking in motivation.”

Even if true, the host has arbitrarily created a chain of events here: It’s hard to speak honestly in this environment > The participant said they were busy > Since it’s hard to speak honestly they’re lying and hiding something. In such an environment, of course the participants won’t feel psychologically safe – there is no merit to speaking honestly.

Reducing Obstacles

Earlier, when explaining the concept of psychological safety, I mentioned repercussions – those are interpersonal ones. Things like being hated, reprimanded, having your skills doubted, being treated as a weirdo…and so on. Even in jobs where you’re supposed to have no interaction with colleagues outside of work hours, psychological safety still has a significant impact.

In that case, that is doubly true for a hobbies-based, collaborative group work that requires social interaction. I believe many people feel something like “I don’t want people who share my hobbies to hate me!” Or, even if they’re fine with that, they at least think “I don’t want people who share my hobbies to think I’m a bad person!” I believe in some cases these interpersonal risks might be even greater than ones experienced at work.

It’s tough, but if we want participants to freely express their opinions and to make it easier to report mistakes and other risks to the collab, we must address the issue of psychological safety. The participants will be able to tell where we do or don’t.

So how do we approach this? There are several methods, but for Otomad collabs becoming friends – or at least getting to know the other participants seems to be the easiest. When you have an important announcement to make, there’s a significant difference in difficulty between doing so with someone you’ve only ever exchanged work-related messages with and someone you have had regular conversations with before.

Since 2022, I’ve been increasingly invited to help with the operation of various Otomad projects, and I’ve always made a conscious effort to behave in a way that makes me appear approachable, assuming that there are people who don’t know me.

In recent years, Otomad collabs have become more and more advanced, so it’s not uncommon to invite people who specialize in fields they have no knowledge about whom they do not know. Try to get to know each other, it doesn’t matter how you go about it.

This is a common suggestion, but try to keep the casual chat channel on the collab server moving. This will not only help participants remember the collab exists, but also help them understand what kind of person they’re working with. It might even make it easier for participants to offer their advice when required.

Again, when you get no responses or just “I’m busy!”, don’t give up. First consider what is happening and what circumstances would allow the participants to proactively speak up. Since collabs are inherently a group effort, you could argue a project where the host has to do everything is inherently flawed. As a last resort, acting as described in the original article might be fine.

Chapter 2: Aggressive Micromanagement

Caption: If you have ever looked the word up, you have probably seen these. Was the original sure this is the right way to handle things? Maybe it was, since they even added the words “aggressive”

Personally, I think micromanagement is the complete opposite of trust. It’s a sign you lack trust in the participants, as you’re essentially instructing them and managing every detail of their work.

The general ideas presented in this chapter are rather reasonable:

1. If they’re stuck idea-wise, provide references. If they’re stuck technically, find someone who can provide support
2. Draft a rough comprehensive schedule and conduct frequent follow-up meetings
3. Praise participants when they do well

Huh? These don’t sound very micromanagement-ish… Maybe point 2 applies. Or point 1 if taken to an extreme measure. What counts as micromanagement isn’t a black-or-white issue. It’s heavily influenced by your mindset and individual approach.

Micromanagement is a management style in which the project manager becomes heavily involved in the work of those under them and controls even the smallest details. In creative collabs, the host must exercise meticulously calculated micromanagement in order to maximize participants’ creativity and ensure the project’s success.

This way, they turned micromanagement into a responsibility. I believe the 3 points above are all good, but not with this mindset.

Constantly being asked by an overeager host for progress might even decrease motivation rather than increase it. These excessive reports convey a feeling of mistrust and can make it harder for the participants to respond. This applies to providing additional resources for ideas and technical issues.

Also, this may be a chicken and egg thing, but the participant may think that because the host will come to check on their progress, they won’t have to do anything unless prompted.

Make it Personal

A bit earlier in this article, I wrote “Become friendly with the participants to get them to speak up!”, but I’m sure there are people among those who don’t respond who you are on friendly enough terms with. In cases like this, it might be that the collab itself has become irrelevant for the participant.

“Wait a minute,” you might say. “They accepted the invitation and joined the server, so what do you mean it’s irrelevant?” Yes, that’s correct. But what’s actually happening? I’m sure some have participated in a collab without much enthusiasm, feeling something like “I don’t feel like I can refuse…” It varies from participant to participant, but the host should consider what they can do to make each participant feel involved in the collab, regardless of their circumstances.

Essentially, we’re talking about motivation management.

We’ve ignored this until now, but Chapter 2 also discusses the role of a project manager.

A host’s true role should be that of a project manager who can guide a collaboration from its beginning to the very end and ensure its success.

What does a “project manager” do?

At my job, we have several directors and producers, so the project manager is only responsible for deadlines and managing progress and tasks.

The scope of a project manager’s work varies between workplaces, but the role can be defined as someone who ensures the project proceeds smoothly.

However, it is not the project manager who completes the project. Each individual worker or participant is responsible for that. Because of this structure, part of the project manager’s job is maintaining the project members’ motivation.

Chapter 2 mentions that “providing specific praise when participants submit is essential”, but there is a trap laid in this advice – Motivation management isn’t only about providing praise about progress, as that won’t help someone who hasn’t submitted anything.

The first step here – being able to elicit initial progress from participants, depends on whether or not we have managed to make the project matter to them. The original article suggests a system that organizes the participants into a “lacking ideas” group and a “lacking skills” group. That in itself seems effective. (Of course, we need to consider the proper distance between us and the participant, as well as the frequency of communication).

That said, sometimes the problem does not lie in one of those two groups, but rather in a third one, “lacking motivation.” In a typical job this would be solved with a pay raise, but this idea doesn’t work in an Otomad collab.

One solution is constant activity in the casual chat channel. In this case – conversations related to the collaboration. For example, for a game-based collab you could talk about the game itself.

Honestly, this is a tough task. I’ve struggled with similar cases in the past myself. I feel like if it were easy to do this, we’d be able to solve all kinds of problems. Or maybe cause new ones. Cults seem to be an expert on this sort of thing.

Jokes aside, another option is to exercise caution when sending invites to a collab. We tend to focus on people with ideas and technical skills, but you should probably also consider how enthusiastic they would be about the project.

The original article mentions “foster[ing] a healthy sense of competition and solidarity” between participants by making progress visible to everyone. Whether it’s competition, solidarity, or something else, seeing progress from other participants is definitely motivating. In that case, if the host has a part, they perhaps should try to submit it first. These days some hosts don’t make progress entirely visible to avoid leaks, so this is a very complicated issue.

Anyway, I thought that original article in question completely underestimated the importance of motivation. In the end, this is a hobby, but the ideas it suggests don’t seem very fun.

Chapter 3: Project Structure That Prevents Failure

This was a very promising chapter title. Yes! Let’s prevent problems before they happen!

But are we really preventing them?

A lack of response to meetings or activity on the server are clear signs or triggers of collab delay. The problem is no longer a personal issue, but rather a risk to the entire project.

The host should monitor the participant’s activity on social media as well as activity in other unrelated communities in order to have a clear picture of how active they are. This somewhat stalker-like behavior is the type of determination to succeed a host needs.

Lack of response, decreased activity and sometimes even complete disappearance are common occurrences in Otomad collabs. In some cases checking their activity on social media might help us. However, I think the lack of consideration as to why the person stopped responding is a problem in itself. While sometimes there is no other choice but to try and “track down” a participant, failing to consider that the participant simply does not want to be involved with the server or host anymore is a major oversight.

That’s right. In my opinion, when a participant disappears or becomes unreachable, it’s because:

1. They didn’t feel any connection to the collab in the first place
2. The host failed to maintain or increase that person’s motivation, or
3. The environment wasn’t psychologically safe, so even if they had other reasons they were not communicated

One of those three factors might be the cause of the incident. Stalking them on social media or replacing them with additional people might solve the immediate issue, but the problem might repeat itself in the future.

The foreword to the original article states that “collaborations consume a precious resource: an Otomad creator’s time.” This statement, taken within the context of the article itself, can be interpreted as saying that an individual’s resources should only be spent on meaningful collaborations, but I find that hard to agree with. Furthermore, if one of the reasons for this so-called waste of the creators’ resources is how hosts have habitually dealt with their disappearance of participants by treating the symptoms and not the cause, the situation would be beyond help, wouldn’t it?

In fact, I think there’s quite a history in Otomad communities of people who disappeared in the middle of collabs because they couldn’t communicate. If this isn’t a loss to the entire community caused by a lack of reflection on an environment of poor psychological safety, what is it? I would call it a tragedy.

But well, what’s done is done. Sometimes we do need a quick response, be it inviting additional personnel or trying to make contact in any way possible. Quite a few collabs operate under the so-called “three week rule”, where progress checks are done regularly every 3 weeks. By agreeing to the rule in advance, we mitigate a feeling of participants feeling personally punished, which eliminates the need to stalk or be stalked.

Conclusion and Additional Thoughts

Those who have read the article up to this point will understand that I share the belief that hosts bear some of the responsibility for tardiness and other shortcomings on behalf of the participants in collabs. However, I believe the following parts of the original article are problematic:

Is preventing lateness all that matters?

While strictly enforcing the rules written by the original writer will reduce late submissions, the process will feel like a crappy unpaid job. We must never forget that this work is done solely on trust. Haranguing someone over and over and forcing them to complete their work is the complete opposite of trust.

表題については、確かに遅刻の原因は主催にもあるかもしれませんが、趣味のグループワークでモチベーション無視のPMみたいなロールに徹しても"仕事の下位互換"になるだけではないかと感じました。
メンバーが皆ロボットなのだったら参考にすべきだと思います。https://t.co/8nEBMTpCM7

— きっかん (@ktzkn_) December 9, 2025

As I said when I originally posted about the article – If participants were robots we could just hand them parts and manage them as we wish – but that is not how things work in real life. I hope that in the future fewer collab hosts will prioritize quality and perfection over a human element to the work.

If we could do it alone, there wouldn’t be issues in the first place

The demands the original article makes of collab hosts are far too much. I guess you can gather additional managing staff, but always remember a collab involves many participants, all working together to make one work.

On a similar point, I felt the article was lacking consideration of how to get others to agree with their ideas:

Sadly, even the habitual latecomers will eventually submit their (often high quality) work. This doesn’t mean they lacked an ability to meet the deadline in the first place, but rather that they deemed it not worth meeting in the first place.

It would be far better to think how to make deadlines seem worth meeting, rather than how to meet the deadline at all costs. One way is making people feel personally invested. If you invite the right people and get them to share your vision, they can act proactively. If something gets stuck in the process like that, everyone can think together about how to solve it.

Lateness cannot be completely eradicated

Lateness is inevitable. I’ve been a working adult for about 8 years now, and I’ve seen people of all levels and positions fail to deliver on time and fail to announce that on time. If this applies to salaried work, it would surely apply even more to unpaid hobby work.

The focus, in that case, should be on preventing failure even if people are late. Having an environment where people can communicate if they believe they’re about to be late is another benefit of psychological safety.

The article’s title

Of course, this is paraphrased from the original article’s title. While they wrote “Collab Delays Are All the Failure of the Host”, I called mine “Collab Successes Require Hosts to Take Lead”.

Let’s look at the purpose of the article in question.

This article is intended as a protest against the commonly-held opinion that a collab’s tardiness is the fault of its participants, and to express in no certain terms the responsibility all collab hosts must bear.

You are the one who organized the collab, so you must bear the responsibility for it.

Otomad on Paper

Otomad on Paper (紙の音MAD) is a fanzine series about Otomad organized by BaNChou.

Certainly, delays in collabs aren’t 100% the participant’s fault, and often some blame lies in the hands of the host themselves. It goes without saying that your responsibility towards the project starts the moment you start to organize it. You must be prepared. I touched upon this in my article Before Organizing a Collab in Otomad on Paper Vol. 1.

But before you start rushing, covering for others, seeking additional personnel or stalking participants, it’s important to share your vision with the participants – What the collab aims to achieve and how happy they would be if they create something good for it. I believe you need the resolve to make sure all the participants understand this. But that’s difficult. People with these kinds of skills often end up becoming directors or managers themselves.

I still have a long way to go myself. Yes, it’s fine to be inexperienced. In the end, being able to help each other in times of crisis is one of the many aspects of collabs, and I want to work hard so that people may see my project as one worth helping.