Who Is on Your Project? Reading a Studio's Team Plan

A typical game development studio team structure for a funded mobile project includes a producer, a lead engineer, one or more engineers, artists, a game designer and QA. The team plan tells you who fills each role, how much of their week you get, and who makes decisions. Read it for names, percentages and seniority, not just headcount.

Why the team plan matters more than the price

Two quotes at the same price can buy very different projects. One might give you a senior lead most of the week. Another might give you a junior team with a senior name attached for a few hours.

Your budget, timeline and board updates all depend on the people doing the work. The team plan is the only part of a proposal that tells you who those people are. Our guide to reading a game development quote covers the money side.

Headcount tells you how many people. Allocation tells you how much of them. Names tell you who.

The roles you should expect

Most mobile game projects need these roles in some form. Small projects combine them. Large ones split them further.

If a role is missing, ask who covers it. A plan with no QA usually means engineers test their own work, which tends to miss things.

Reading allocation percentages

Many plans list each person with a percentage. That number is how much of their working week goes to your project.

• 100 percent means they work only on your game.
• 50 percent means they split time with another project.
• 10 to 20 percent usually means oversight: reviews and key decisions, not daily work.

Low percentages on senior roles are normal for oversight. Low percentages on the people doing daily work can be a concern, because context switching slows everyone down.

A quick sanity check

Add up the percentages and compare them with the timeline. A plan with very little engineering time and a short timeline does not add up. Ask the studio to walk you through how the work fits.

Named people versus roles

A plan that says "Senior Unity Developer" is a role. A plan that says a person's name, with their past projects, is a commitment.

1. Ask which people are named and confirmed for your project.
2. Ask what happens if a named person leaves or is moved.
3. Ask to meet the lead engineer and the producer before signing.
4. Put key names in the contract, with a process for replacing them.

Studios do move people between projects. That is normal. What matters is that you are told, and that a replacement is of similar seniority.

Six questions to ask about the team

These questions bring out the real shape of the team quickly.

• Who makes the final call on technical decisions?
• Who will I speak to each week, and who can I reach in an emergency?
• How many other projects is the lead working on right now?
• Which roles are in-house and which are contractors?
• How do you handle holidays and sick leave on a small team?
• Who on this team has shipped a game like ours before?

The last question matters. A team that has shipped something close to your game will make fewer expensive early mistakes.

How the team should change over time

A good team plan is not flat. It changes as the project moves through phases.

Early phases lean on design and senior engineering to make the big decisions. The middle of the project adds engineers and artists for production. The end shifts weight to QA, polish and store preparation. If the plan shows the same people at the same percentages from start to finish, ask why.

What we would do

We would ask for the team plan as its own page in the proposal, with names, roles, seniority and allocation for each phase. Then we would compare it side by side with the other proposals on your shortlist.

Before signing, we would meet the producer and lead engineer on a call. Twenty minutes with the people doing the work tells you more than any portfolio.

We would also write the lead names into the contract. It protects both sides and makes any change a conversation, not a surprise.

The short version

• A standard mobile team has a producer, lead engineer, engineers, designer, artists and QA.
• Allocation percentages show how much of each person you actually get.
• Low percentages on senior oversight are normal. Low percentages on daily builders are a flag.
• Ask for named people, meet the leads, and put them in the contract.
• Expect the team to shift across phases, with QA growing toward launch.

If you have a team plan in front of you and want a second opinion on what it really buys, send it our way.

Related reading: How to Read a Game Development Quote Like a Pro, How to Compare Game Development Proposals Side by Side, Hiring Your First Game Producer Versus Renting One