Code Wizards 发布外部开发合作的五条黄金法则

We created Code Wizards 24 years ago, and as an external development partner, we work with a mix of small and large companies on backend engineering, live operations, IT and more. Over the years we've learnt from our mistakes, and CEOs of new studios and service providers often ask me how they can best work together for success. Here, I'll share the top five simple rules that you can incorporate into your own playbook to help minimise the stress and maximise the fun of working together.

Golden Rule #1: We're in the business of trust

All games are a piece of art created in a digital form. Trusting somebody to enrich another artist's work is difficult.

Trust is typically built up over the course of years, but working with a new partner requires trust from day one – and that needs an investment.

Any engagement needs to start with an assumption of trust, but we can improve that by continually showing each party is trustworthy. This isn't onerous or difficult, but it does require transparency, planning, and a way of measuring and demonstrating progress. It goes both ways, too: the client is putting their trust in a co-developer or service provider, but the latter also has to trust the client.

The more you build up trust with the client, the more it's likely that any feedback given to them will be listened to

Often the early stages of a game production cycle have largely invisible elements – it's like building a new house, and the foundation takes time, but it is hard to visualise the real effort and work involved. No timesheets will ever be able to demonstrate what's being realised behind the scenes. Find a way of explaining what's going on and ensuring it maps against the agreed plan. Most of all, if you say you'll do something, then do it.

The more you build up trust with the client, the more it's likely that any feedback given to them will be listened to. It's important that all discussion is considered to be valued and well intentioned, and ultimately it will help to make a better game.

Often a prospective new client will message a contact who has worked with us before to find out their opinion of us. A few years ago, I remember taking a call with a potential client who seemed positive but reticent. We closed the discussion on a "maybe." Fifteen minutes later they called back after having spoken to a contact we'd worked with, saying: "They said you're amazing, let's get a contract together." That's the power of reputation and trust.

At all times remember that our industry is a small one – trust is hard to earn and easy to lose. Reputation doubly so. Trust isn't just earned when things are going great, but also when things go wrong. Own your mistakes and fix them. When others make mistakes, jump on and help them get back on track.

TLDR? Treat your reputation like XP – getting to S-Rank is super important.

Golden Rule #2: Flexibility is key

Imagine you're working on a game that everyone is really excited about. Everything is headed in the right direction when all of a sudden, it doesn't feel good enough. What if you encouraged everyone to take a beat and rethink things?

Being able to move things around and change the order that we build them is incredibly important. The key mechanics and functionalities touch every aspect of the game. If it feels like something is off, sharing that feedback immediately is crucial. Strong collaboration and that established trust means that feedback matters and is listened to on all levels.

Games evolve over time, and everybody on the team needs to be willing to bend and flex with them

We're lucky enough to work with a bunch of studios, and there was a great example of the above a decade ago. A renowned studio had a great game, but the wall running just didn't feel right. To get that mechanic working, they needed all of their internal teams pulling together. The pause to fix the issue was two weeks long, which seriously impacted our teams and deliverables – but the game was massively better as a result of the fix (as proved by the Metacritic score). Yes, it caused us a rescheduling nightmare and we had to work harder, but not one member of either team regretted the change.

Games are a form of art and they should be fun, beautiful, and engaging to succeed. One simple detail that feels off can break the experience. That means games evolve over time, and everybody on the team, including service providers, needs to be willing to bend and flex with them, understand how to communicate those changes, and negotiate something that works for all.

Golden Rule #3: Communication is critical

Games teams are a broad church of different kinds of people, from the overtly artistic to those heavily into engineering. They speak slightly different languages, and that needs to be catered to.

In addition communication isn't only written and verbal, it also translates into culture: how the teams fit together and the way they work. Different clients have different ways of operation, and you have to tune into the communication style that works best for them.

The trick is to overcommunicate. You can't assume that everyone knows the project goals, and by overcommunicating, you ensure that everyone involved is part of the same conversation.

Communication style will change as the game goes on

This is best illustrated in two different examples with two very different communication strategies. For the first team (which is making an epic driving game with a new publisher), we've adopted a "project health" fortnightly reporting cadence. Not only on the deliverables, milestones, and efficacy, but also covering inter-team collaboration, morale boosters and blockers, and ways to improve. The other is a team we've worked with for many years; here, we concentrate our communication on exceptions – reporting on where we see risk, change, or dependencies that could affect the project, with everything else expected to work correctly unless it's flagged.

Communication style will also change as the game goes on. In the early stages, the goals are still being defined, so communication might feel more free and artistic. But the discipline starts increasing as the project accelerates. At that point, it's important to get more formal in how you talk about your goals and how you're delivering against them.

Golden Rule #4: Know your weaknesses

We all know that every team has strengths and weaknesses. As an ex-dev, you were hired largely based on your strengths, but before you start collaborating, you need to communicate and share where you are best and worst utilised. The bottom line is those strengths and weaknesses need to be called out so that you can collaboratively build the best plan for success.

Unless you declare what you don't know, those gaps will cause problems down the line. That perspective has to start from the top of the organisation, too. For example, I can say that I wouldn't be good at delivering UI or 3D modeling for a game, as those are not my strengths.

It's crucial to understand those specifics across the team dynamic to ensure we can work around them. If everyone understands the challenges, you can work better together.

You need to communicate where you are best and worst utilised

At Code Wizards, we know our strengths: we often work on games with very high numbers of concurrent players, so when a new studio recently asked us to profile and load test their game, it was all in a day's work. But we're also aware of our weaknesses. A client we've worked with extensively before wanted us to help out with game client optimisation, and although the temptation was to say "we can do that" and try to learn as we went along, that would only have made their job harder and imperilled the game's quality. So we pulled back and found another partner to lean in and help them instead.

Think of the old saying: Jack of all trades and master of none. We all bring different things to the table – that's what makes it fun and why we are stronger together.

Golden Rule #5: Look after your people

Games are a people business. Creating a strong company culture that keeps those people happy is a true artform.

When your team works on a project, you need them to all be of a similar mindset and share a similar motivation to achieve the project goals. Otherwise, chaos ensues.

I've learned that a positive culture starts with being heard, but in both directions. Team members want the opportunity to say their piece, even if it's different or unexpected. But leadership still has to be in place. We call ourselves a "benevolent dictatorship," because we maintain a hierarchy for command and control while treating people as people – not as "resources." People want to be heard, but they also need a level of direction.

If you keep your team happy, it's a simple truth that they'll make better games

There's always a conductor of an orchestra, that's the way it works. Be careful with how you lead though, because nobody wants to go the extra mile under a full-blown dictatorship. The bottom line is everyone should feel like they're part of the team and that everyone is building toward the same goals. With that culture in place, generally people will be happy with their daily work.

A few years ago, one of our team members sadly lost a parent. It was fast, unexpected, and the parent lived abroad. Without being asked, their project team picked up their work, added it to their task lists, and made it clear they could drop everything and the team wouldn't be affected. That kind of respect and love can't be taught or manufactured, that's the consequence of good people wanting the best for other people and leaning in to help.

More recently, we had to have a tough conversation about a person being the right peg for the wrong hole. They are amazing and super clever, but really badly suited for what the role had evolved into. It's uncomfortable to have the discussion that this person isn't in the right place, but it's essential. We collectively agreed that they would go back to their engineering role. A few months on we re-reviewed things – they were happy, content, loving their job, and making a massive impact. Did I enjoy that discussion and causing disappointment to somebody? No. But sometimes the tricky conversation is the best thing for everybody.

If you keep your team happy, it's a simple truth that they'll make better games, and those games are more likely to be successful.

In summary, the key points are:

• Trust: The commodity of real value – learn how it takes work to build and retain.
• Flexibility: Games are art, not IT – ensure you collaboratively build the best game together.
• Weaknesses: Own your strengths and weaknesses and ensure you cover your least strong areas.
• Communication: Teams, sometimes huge, make amazing games, but only when they communicate well.
• People: Games are built by people, not tools – happy people make better games!