[Guest post] Chris Rowe: Co-Dev Without the Culture Clash

Co-Dev Without the Culture Clash: How to Scale AAA with Partners That Feel In-House

By Chris Rowe, Business Development Director at Innovecs Games.

AAA development used to have rough predictability. You staffed up, you shipped, you staffed down, and you kept rolling. It wasn’t always stable, but teams could stay together long enough to build momentum.

That rhythm has been harder to keep. Costs keep climbing, big teams burn cash fast, and the margin for error is thin. You can see it in the workforce: in the 2026 State of the Game Industry research, 28% of respondents said they were laid off in the past two years, rising to 33% in the US, and two-thirds of AAA respondents said their companies had layoffs.

This is where the all-or-nothing feeling comes from.

One massive bet wobbles and the correction is brutal: cancellations, delays, closures, layoffs.

But what worries me more than the headlines is what gets lost in the churn: teams get scattered, people leave, and you lose the shared history that makes teams great.

The best games, in my experience, are made by people who’ve been in it together long enough to know the ups and downs are coming, and still know they’re going to get it done and make a great game.

Building the Core First, Then Scaling the Build

This isn’t a new problem. Even when the industry felt steadier, studios still ran into the same reality: you don’t need every discipline at full capacity for the full life of a game.

Back in the 2008–2018 era, a lot of mid-to-large studios solved that with multiple projects. People rolled off one project and onto the next in a “just-in-time” rhythm. If you had a healthy pipeline, it worked.

What’s different now is how many teams are running all-or-nothing: one game, one big bet. If it hits, you’re fine. If it doesn’t, you’re not. And in that setup, the old internal reshuffle approach doesn’t help much, because there isn’t a second project waiting in the wings to absorb the peaks and valleys.

So if I’m building an AA or AAA game today, I start with a simple rule: keep the core team small and excellent, and treat scale as something you earn by phase, not something you carry the whole time.

Start Smaller Than You Think

Build the smallest core team that still covers the key disciplines: strong technical direction, strong art direction, strong gameplay/design leadership. Not a thin team of juniors. A small group that can make good decisions, set standards, and keep the game coherent.

Then give that group real runway (often 6-12 months) to lock the foundation:

• Define what the game is
• Prove how it plays
• Get the blueprint clear enough that you’re not staffing a moving target

Call it a prototype, a playable demo, a vertical slice, the label doesn’t matter. The point is: figure out the game before you build a giant team around it.

Scale When the Blueprint Is Real

Once the foundation is solid, scaling gets simpler. You can look at the next milestone and say: “What do we actually need to build this?”

And this is where flexibility pays off. Instead of defaulting to full-time hires, I’ve had success bringing people in on a contract basis first, especially when the team is small. You learn fast if they’re strong, if they fit, and if they make the team better.

If it clicks, then you consider making it permanent. Because a full-time hire shouldn’t be treated like a patch. If you hire someone as an employee, you should be building an environment where they can succeed for years, not a few months.

Meanwhile, your core leaders stay focused on direction and quality. The phase-based capacity scales around them without turning every staffing shift into a future layoff problem.

What Stays In House and What Can Flex (The Line Is Not the Task List)

People often want a clean split here, like there is a fixed list of tasks that must stay internal and another list you can safely hand off. I do not think it works that way.

The real line is leadership and coherence.

The Internal Backbone

You want a core leadership group inside the studio. These are the people who live and breathe the game and understand what makes it work. They know the intent behind decisions, they know the tradeoffs, and they can spot drift early. They also need to be close enough to move quickly together, whether that is in the same room or working tightly day to day while remote.

You also want a technical anchor in-house. Someone or a small group who is thinking about how the pieces fit together and how the game is being constructed, so the product stays coherent as it grows.

After That, You Can Flex Almost Anything

Outside of that foundation, a lot is open to external support. Design, art, engineering. The question is not “can this discipline be external?” but rather “is the studio set up to succeed with external development?”

If the setup is there, you can scale without taking on the long-term risk of going from 20 to 100 full-time staff. You bring in capacity for the phase you are in, then dial it back when you do not need it.

The Mindset Shift I Am Seeing

For a long time, plenty of studios resisted external partners because they worried they would lose something by doing it, or because they wanted to keep work in-house to keep everyone employed. I get where that came from. But that mindset also contributed to the situation we are in now. Teams grew, burn rates grew, risk grew.

What I see more now, especially with newer studios forming after the last few years, is a different approach from day one. They stay smaller on purpose. They plan to lean on external support early. Some teams come to us when they only have five or six people because they need one or two key specialists to reach the next stage.

That is a healthier pattern. It treats external development as part of the model, not a last-minute rescue.

Co-Development vs Outsourcing: Matching the Model to the Need

Co-development and outsourcing are used interchangeably, but in practice, they solve different problems. I think about the difference in two buckets.

Co-Development Means Owning Big Pieces of the Game

When I think about co-development, I think about scale and ownership.

A team is building a large game, and the clock is ticking. They know they cannot, or do not want to, scale their internal headcount to match what the project demands. So they bring in a co-development partner that can take on a large part of the product and own it in a way that mirrors internal ownership.

That might be an entire feature area or tentpole, like multiplayer. It is not “help us with a few tasks.” It is “this is a major initiative, we need you to run with it, and we are building this game together.”

That is why co-development engagements tend to be larger and longer. When the game ships, the co-development partner has contributed in a meaningful way, very similarly to how the internal team did.

Outsourcing and Resource Augmentation Are Targeted Support

Traditional outsourcing is still contributing to the game, but usually in smaller, more defined ways.

Maybe the team needs a lot of art and does not have the internal capacity or time. Maybe they need tools to speed up their pipeline. Maybe they need a specialist to solve a specific problem for a month, or for a six to twelve-month push. The scope is narrower, the ownership is tighter, and the goal is to fill a gap or remove a bottleneck.

This is also where resource augmentation can be a great fit. You can bring in a specialist with a very specific skill set, get what you need done, and avoid carrying a permanent headcount you may not need long term.

Most Teams End Up Using Both

Most studios will use a mix. There is no single model that fits everything.

If you want to stay very lean, you lean more into co-development. You keep a small leadership core internally and use a partner to help build major parts of the game, while you direct, guide, and maintain the vision. If you are a larger team with specific gaps or pressure points, more targeted outsourcing makes sense. You call a trusted partner, fix the problem, and keep moving.

Either way, the key is that the internal team needs to be set up for external development. When it is set up well, external support becomes a real force multiplier, not a complication.

The Mechanics of Trust at Scale

If there is one theme I keep hearing from clients, it is this: they do not want external support to feel external. They want it to feel like an extension of their own team. That is not a nice-to-have. For a lot of studios, it is the difference between a partnership that reduces pressure and a partnership that creates more work.

It Has to Feel Like One Team

The basics matter more than people think.

Communication is the first gate. Can the team join meetings when needed? Can you message them in the same tools you use every day? Are they willing to operate inside your workflows instead of forcing you to adapt to theirs?

When a client says, “We want this to feel internal,” what they usually mean is simple. They want to be able to collaborate naturally, not manage a separate vendor relationship as an extra project.

Time Zones Are Not a Detail

Some clients care a lot about time zone overlap. They want the team on the same working hours, in Slack, available for quick back and forth, and present in the cadence of the project. For certain studios, that is a deal breaker.

Other clients are comfortable working across time zones, and it can actually be an advantage. You get a follow-the-sun rhythm where work moves forward while another region is offline, then feedback is ready when the next region starts the day. It becomes a kind of steady 24-hour cycle, which is especially useful when a milestone is coming fast.

The point is not that one approach is better. The point is that a partner has to be able to support both, depending on what the studio needs.

The Non-Negotiables Clients Look For

Assuming the partner can do the work, there are a few things that consistently show up as dealbreakers.

• First, you need proof that you have done it before. Studios are not in the mood to gamble on theory right now.
• Second, you need cultural fit. Teams can tell quickly if someone is going to collaborate well or turn everything into friction.
• Third, you need infrastructure and the willingness to embed. Tools, process, communication habits. If a partner makes the client’s life harder, it is the wrong partner.

The Extra Layer That Matters More Now

One thing I think is becoming more important, especially with newer and smaller studios, is value beyond delivery.

It is not just “make the art” or “build the tool” and tick the box. A good partner can bring pattern recognition from seeing many teams across the industry. What tends to work. What tends to break. Where studios usually underestimate the effort. How to avoid mistakes that are expensive later.

For newer studios, that can be a real advantage. Not because the partner replaces leadership, but because they can help strengthen it with experience and perspective.

And that is where I get excited about the direction this is heading. As the industry resets, the teams that treat external development as a normal, well-run part of how they build games are the ones most likely to stay lean, stay sane, and keep momentum.

Freeing the Core Team to Do Their Best Work

Here is the part people do not talk about enough. The biggest win of external capacity is not just cost.

Do Not Turn Your Best Creators into Managers

When you hire great leaders, you hire them because they are excellent at design, art direction, or technical leadership. They come in excited, they want to build something, and they have the taste and experience to push the game in the right direction.

Then the team grows.

And suddenly that same person is in meetings all day. They are responsible for ten or fifteen people. They are doing reviews, approvals, one-on-ones, performance conversations. They are managing. For some people, that is a great path. For a lot of people, it is not what they signed up for.

The job changes. And when the job changes, you can feel it in the work.

External Capacity Brings the Energy Back

Scaling purely internally can quietly squeeze the fun and creativity out of development. The people you most need to focus on the game end up focused on the organisation around the game. The pressure goes up, the time for real feedback goes down, and the work can start to feel like a chore.

External development can relieve that pressure in a really healthy way.

So, if I’m talking to a decision-maker who is considering a partnership right now and wants fewer surprises this year, I would start with three simple rules.

1. Hire with intention. Every full-time hire should have a clear purpose and ideally be someone who can wear multiple hats. If you need a narrow specialist, that is often a better fit for external support than permanent headcount.
2. Keep the core small and let it earn trust. Start tight, establish the blueprint, set the standards, then grow gradually. Fast spikes from a close group to a large org can cost you culture and clarity.
3. Think external early, not only when things go wrong. When challenges come up, do not default to “we must hire.” Ask how to solve it externally, and build those relationships and processes early, so it is normal, not a rescue.

When a trusted partner takes on an initiative or absorbs a chunk of workload, it does not just help you hit a milestone.

It gives your internal leaders room to breathe when partners like Innovecs Games take pressure off your core team. They can focus on direction, on quality, on making good calls. They can actually review work properly and write clear feedback. The energy comes back because they are doing the part of the job they are best at.

And I will say this very plainly. If you protect that core group and let them stay creative, the game will be better for it.

Ultimately, that is what we are all trying to do together. We want to make the best game possible.