The Non-Agreement Agreement: A Better Model For Building Roblox Teams?

[berezaa]

If you’re a developer looking to start up a team to make a Roblox game, most of the time you’re faced with one of two options: you either fund the project yourself and retain the majority of ownership/revenue rights, or you find people who believe in what you’re doing and cut up most of the game’s revenue among the teammates in lieu of payment.

Having gone down both of these routes, I believe that both of them have terrible, game-killing flaws.

I am not a lawyer and this is not legal advice.

The Problem

In the first case, the founder takes on massive risk by investing their personal savings into the project, and the commitment of the other developers is lowered because they are not directly invested. It messes up incentives and can get really messy if things start going wrong and the prospect of losing savings starts coming up on the horizon.

In the latter scenario, “locking in” percents frequently leads to a tragedy of the commons-like conundrum whereby one team member starts slacking, which then lowers the motivation of the other team members. After all, why should they work harder than the slacker if percents are already determined and their additional hard work won’t be rewarded?

Both of these models are flawed in that they make assumptions based on data that is not yet available, namely: how will each person actually contribute to the project? It also forces the lead/project manager to assume a “whip” position to make sure everyone is doing what they should be, and we all know how great negative reinforcement is for making games \s.

You might think that a clever way to sidestep all of this nastiness is to tie percents to a list of deliverables, but this model is still not resilient to developers losing motivation, and you can easily end up with a team member that does the absolute minimum required to reach their deliverables, and that is not the recipe for a fun game. So what can you do?

Well… what if the best agreement for building a team is no agreement?

Introducing the Non-Agreement Agreement

In lieu of an agreement, the “standard agreement” according to the law is that each team member has full intellectual property ownership over the content they contribute to the game. This allows you to defer negotiations until a later stage in the game development process when you might actually have a good idea of the game’s success trajectory, while giving each team member real legal leverage over the outcome.

The non-agreement agreement is a brief legal document that simply states there is no agreement over the terms of the project, and that it can only be superseded by a written and signed agreement.

Rather than determining roles, percent cuts, salary, etc. before the project has even been started, let’s explore what it might look like if a team of talented superstar developers decided to make a project with each other using a non-agreement agreement.

Example

Billy, Sally & Roe have decided to make a simple simulator game using a non-agreement agreement. They’re realists, and understand that the chance of such a venture being successful is very low, so they are primarily doing this project to improve their skills and add something cool to their portfolios, and because they’ve always wanted to make a game together.

The gang spends two weeks making their simulator game. Billy is the front-end scripter, implementing most of the audio and visual effects from the catalog and coding the UI. Sally is the back-end scripter, dealing with data and other systems. Roe is the artist who makes both the UI designs and the 3D models used in the game.

After two weeks, the team realizes that the game they’ve created is actually quite good, and it’s almost ready to be released! Now’s the time for negotiations.

Billy & Sally, both being scripters, have a pretty good idea of how much effort each of them has put in and how important their work will be to the project. So they come to an agreement with each other and propose the following split to Roe: 40% for Billy, 40% for Sally, and 20% for Roe.

Roe is outraged when she hears this, because she feels that the game’s unique aesthetic defines its character and that the project would be unrecognizable without her. She also knows that she will have to make assets for the project for a long time if it is successful.

Roe informs Billy & Sally that she disagrees, and that with her legal IP ownership she will file a DMCA takedown if they use any of her assets in the project. In this situation, Billy & Sally can either

1. Negotiate the percents to something that is agreeable to everyone
2. Offer to buy out Roe’s rights for a reasonable lump sum payment
3. Remove all of Roe’s contributions and start a new project with their code

Option 3 is really the nuclear option, and people in this situation will naturally do everything they can to avoid it if everyone is acting in good faith. No one wants to unnecessarily tarnish their reputation. But things happen and this setup ensures the best possible overall outcomes for everyone involved. Billy & Sally get to continue working together in any of these scenarios, and Roe gets to make sure that she is fairly compensated for her work if it is used. The worst case scenario for any party in this situation is that they spent time working on a project that doesn’t lead to a return, but isn’t that already the default outcome for most new games anyway?

Conclusion

What this setup does is help minimize harm to any party, making it hard to end up worse off after you leave the project than when you started on it, which cannot be said for either of the two examples from before. Rather than relying on a single person to be the “whip” (a situation which often leads to burnout and resentment), there is instead a strong social pressure present throughout the project to do your best and contribute your highest-quality work.

But what if a bad actor takes advantage and tries to unrightfully seize ownership of the game without the other teammates? Well, with a proper non-agreement agreement in place, the redress options available to you are the same as the options that would be available to you if that person violated the terms of a standard agreement. You can DMCA, you can sue (you’re just as likely to settle/win), and you can expose them on twitter.

Roblox games are best when they are made fast, by talented creators who are aligned and motivated to give their all to the project. Negotiations and legal paperwork can stop a potential breakout game dead in its tracks. So next time you make a Roblox game, consider using a non-agreement agreement for your team.

---

Thanks for reading my post! I’m interested to hear what you think, especially if you’ve noticed a potential issue or point that I haven’t addressed. Happy to have a conversation in the replies. Cheers!

[Wsly]

Reading through this, I’m positively surprised as you’ve essentially described the process I’ve gone through in all of my larger development adventures; work with a team you can trust and be mature about the finances when they become relevant.

Just like you I’ve gone down the alternative routes with contracts and demotivating legal stuff, but I’ve also come to learn that they are sometimes essential, greatly depending on your team composition. I can afford investing months of my life into a game with other developers on the same level as me, as I know they will all be mature about it and have the same intention to release it with a fair revenue split. But many of the newer, younger developers on the platform are much more focussed on the financial gains than we likely are. I don’t need to worry about the financials from the start as a failing 4-month project won’t cause me to have financial trouble (because of sustained income from prior games), but this is a great advantagious situation that takes time to reach.

I think that is why this is great to put into words, as a possible model for others to follow. There are many advantages to this “Non-Agreement Agreement”, but they take a strong foundation to work. Perhaps upcoming developers can keep these in mind while they are experiencing the less fun, more formal routes first. Building a profesional mindset and reputation will pay off in the end, whether that is from a financial perspective or by allowing you to work on games much more relaxed .

[boatbomber]

This model is nice and probably pretty effective, and I’m happy you wrote it out for us.

Everything works nicely in theory, but no plan survives first contact with the enemy. Do you know of any real-world examples of this non-agreement situation being used effectively? I’d love to hear what bumps and gotchas came up along the way.

I think it’s also worth noting that this model only really works for developers who are already pretty successful, because it operates on two big assumptions:

• Money is not a main concern.
• Everyone trusts each other (to a decent degree, at least).

Your post does imply this throughout but I think it’s better stated more explicitly.

[SteadyOn]

This is a really good insight, and I think adding onto this ‘non-agreement agreement’ something that can save you a lot of grief down the line is this: Make your projects with people who are like you.

I don’t mean the “hire in your image” stuff that leads to discrimination and a team that has massive weaknesses because they all have the same skillsets, I mean find a team that has the same ability level as you in whatever it is they do. Make sure that they are capable of contributing the same amount as everyone else is, without working any harder.

The logic behind hiring a team you’re paying upfront is often to find people who are still learning, and you can help them grow but also pay them a smaller salary. The logic behind percentages is usually that you’re trying to tell each team member how much they should contribute to the project by assigning them a percentage of the revenue, but often you’re expecting different team members to put in different amounts of effort to achieve that contribution because they’re at different skill levels, and that leads to issues.

It’s not a rule and it’s not always going to go badly if your team varies in ability, but often it will lead to individuals feeling that others are not contributing as much to the project as they are. The issue is very difficult to solve without someone feeling this way. For example to try and solve a less experienced team member feeling that they’re putting in more to the project than others as they’re working longer, you might say that everyone should work the same hours. However this causes another problem; the more experienced team member will likely now feel that they are unfairly contributing more to the project than others because they are more experienced and are working more efficiently.

If you’re not going to do a percentage split, or pay salaries upfront, everyone should put in the same work and the same effort, and the only way to do that is to find a team that

1. matches your ability
2. matches your motivation level