Should You Hold Developers to Estimates?

Let’s cut right to. No, you shouldn’t. You should track velocity and capacity, but your production will be more accurate and predictable if you do not hold your developers to their estimates. From a cultural team perspective, we aspire for much, much, more. Trust.

In the world of game development, where creativity meets technology, one question is ever- present: "How long will it take?". Why consider my opinion? As an Executive Producer, VP of Product, Game Director, and CEO, I’ve navigated the intricate paths of this industry since 1994. I also Co-Authored the Game Development Framework at EA during my second tour of duty. I’ve lead teams that have brought to life legendary franchises such as Battlefield, Dead Space, Sim City and The Sims. I have managed the full spectrum of platforms and strategies from AAA shrink-wrap to live games as a service with micro transactions and data-science informed design. I've also done social, console, mobile, and PC/Steam development. In my journey, I've come to a crucial realization: Don’t hold your developers to their estimates.

“From a cultural team perspective, we aspire for much, much, more. Trust.”

Before we get into it, lets establish an essential team culture baseline: Assume noble intent. This is essential for all Producers at every level. We all work hard, have good intent, and want to bring the best individual contribution we can.

Any Initial Estimate is a Guess

When I began my career in 1994, Agile was just a blip on the horizon, and game development often felt like charting unknown territories without a map. Teams were smaller. We worked in a small office. Communication was often constant. Estimates changed on the hour, which made it work. Today, with remote work, larger teams, and bigger budgets, the discipline around project planning and estimates is more critical than ever. You cannot avoid the fact…

Estimates, at their core, are educated guesses. They are useful for setting initial expectations but are not gospel. "No plan survives first contact with the enemy."[1] In our case, the "enemy" is the ever-changing nature of a game’s development - new ideas, unforeseen technical hurdles, and shifting market demands. The earlier you are in development; the more unknowns lie ahead. The game, the concept, and the color of the health bar and whether it is segmented into HAS (Health, Armor, Shields) or not will change. This will change your estimates. Developers can’t predict every unknown, so let them guess!

In a real-world exchange at my day job coaching another team, a great producer said, “My developers won’t give estimates because they say they won’t be 60% accurate”. A 60% accurate estimate is 60% more accurate than no estimate. Your preliminary plan will benefit and take shape faster if your developers are encouraged to guess and trust they will not be held to these guesses. You will need to support and coach less experienced developers, but senior developers should possess the skill to throw out an educated guess if you provide the correct, supportive environment. In fact, an experienced developer can often be 80% accurate with a 10 second estimate and be only marginally more accurate taking 2 weeks to develop a full spec, technical design document, and game design document.

“An experienced developer can often be 80% accurate with a 10 second estimate and be only marginally more accurate taking 2 weeks to develop a full spec”.

In a healthy game development team environment, a designer can pitch a feature, a programmer can ask a few questions, and a producer can get an estimate all in the same meeting.

What about a Production Framework?

Not holding developers to estimates does not mean there is no production discipline. This is more true once you are in Production. Early on, create a culture of experimentation and brainstorming so your team can find the fun, and establish the games core loop. In your Production Framework, this phase is called Concept Development, and it’s a lot of fun. ?

For team sizes over 20, a production framework is required. Without one, chaos and inefficiency will ensue, and this will lead to dissatisfaction and often, project implosion. As part of this framework, early guestimates are part of it. If you do not build a culture of trust, clearly stating teams will not be held to estimates, you will not get these estimates early in the project. A primary goal of your production framework is to have a plausible plan as early as possible. This requires guestimates.

You can use points, hours, t-shirt sizes, or bronze platinum gold, but it all comes down to – when will it be done? You constantly estimate, and your accuracy increases over time as the product is defined and the team gels. By the time you go through Concept, Pre-Production, and First Production, your estimates and your plan will have a high degree of confidence. It is essential you give each phase its full cycle, and not move forward until you have met phase requirements fully. To do so is planning to fail.

“For team sizes over 20, a production framework is required. Without one, chaos and inefficiency will ensue, and this will lead to dissatisfaction and often, project implosion”.

When managing up, I always report project status with a confidence rating. For example, I might say we are on target with 80% confidence. As a Producer, if you say, “Everything is great!”, you erode confidence. You are missing something. Games are hard to manage, and some kind of mitigation is always happening. Communicate this openly with the team and especially with your managers. Sharing a quote from a conversation with Alan Levi, Executive Film and Television Producer, very early in my career, “Films are impossible to make, and it’s a miracle any ever get done”. He’s been successful finishing many projects.

Don’t Guarantee Dates Beyond 12 Months.

In the beginning, you know the plan will change. Embrace it.

External factors beyond the teams control will alter the course of game development to a more accurate date. The game industry shifts more frequently than the development cycle of a typical AAA game. Those shifts impact dates. Without exception, every game I’ve worked on with a dev cycle over 18 months changed its date due to circumstances outside the game teams’ control (since 1994). Studios might double down and expand the scope of your project or split the project into multiple games or undergo acquisitions or focus on your game engine as a platform or… These variables are beyond the control of the development team, yet they significantly impact timelines. The only constant is change.

“Without exception, every game I’ve worked on with a dev cycle over 18 months changed its date due to circumstances outside the game teams’ control (since 1994).

In addition, any successful game will likely look very different on its ship date than it did during its concept greenlight. The core is there, but the games design, economy, even core loop may have significantly changed. In the beginning of my career, I rendered 3D furniture for Will Wright on his “Dollhouse” project and we discussed the intent of the game, “It’s a software toy”, he said. What shipped as The Sims was not tangible in the early days of development. ??

Ever-changing requirements has proven Gantt project plans fragile. A plan is a list of things that can go wrong. Keep it short. Instead of holding developers to rigid estimates, embrace flexibility and inform them, “you will not be held to your estimates”. ?Ask for new estimates frequently and iterate on your plan. This approach allows for innovation and adaptation, ensuring that your team can respond dynamically to changes, focusing on quality rather than being shackled by outdated projections.

“A plan is a list of things that can go wrong. Keep it short”.

Allow, embrace, and support change within any Production Framework. Don’t just account for it, facilitate it. Milestones should have “Updated Plans”.

The Real Pitfalls of Performance Metrics

“You will not be held to your estimates.”

Scary? As a producer, I understand why that can be uncomfortable. But consider this – to succeed in this Market you are lucky, or you work with talented, hardworking people. This article is not for the lucky. Talented professionals work hard, with noble intent. Trust in them.

One of the most detrimental practices I’ve seen is using estimates versus actuals as a performance metric for job security and career growth. This approach breeds a culture of fear. It provides motivation that is counter to project success, leading to sub-par results and sacrificed quality. When developers are judged based on their ability to meet estimates, they tend to inflate them to safeguard against a bad performance review - "sandbagging." You cannot blame them in this environment. They need to put steaks on the table for their family. In a team of over 30 people, this can lead to bloated estimates that strain the project's financial constraints. On a AAA title with a budget of $150MM that can easily lead to a cost difference of $40MM, and quite possibly over-extend the budget.

Focus on fostering an environment where communication, creativity, and collaboration thrive. Make it clear estimates are not a performance metric and align career growth with product goals.

Productions role is to guide and support our teams, not to hold them to arbitrary deadlines. By prioritizing the quality of the product and the well-being of the team over rigid adherence to estimates, we create a positive atmosphere that encourages excellence and innovation.

Building a Culture of Trust

Managing teams ranging from 10 to 150 people with budgets exceeding $160 million, the true key to success lies in trust and open communication. An open approach to estimates means acknowledging their limitations and treating them as a starting point rather than an endpoint.

If you are in a production leadership position, explain your production practices openly and clearly, while providing your reasoning especially if it is a culture shift. Be prepared for team members to be unsettled if they have been thriving in an estimates vs actuals environment. There will be a transition.

Encourage your developers to share their insights and challenges openly. When team members feel heard and valued, they are more likely to contribute their best work. By building a culture of trust, we empower our teams to navigate the complexities of game development with confidence and creativity.

Encourage your developers to share their insights and challenges openly. When team members feel heard and valued, they are more likely to contribute their best work.

Indexing toward iteration and quality will also allow the team to create a great product.

Conclusion

Holding developers to estimates is not only impractical but counterproductive. It also “shows your hand” as someone who has not yet learned some very hard lessons. Estimates vs. Actuals environments cause bloated estimates and a focus on speed rather than quality. Longer term, you can expect an atmosphere of distrust and general negative team culture.

To avoid this, explain the purpose and use of estimates clearly to the team. Tell them they are a guideline, not a rule, and focus on building a culture of trust and support. Accept the unknowns from the start. This will allow your developers to focus on quality and innovation, not deadlines.

Oh, and pad everything by at least 30%.

Michael Murguia

[1] In 1871 Helmuth von Moltke wrote an essay about military strategy that included a lengthy statement that was essentially equivalent to the concise adage. “No plan of operations extends with any certainty beyond the first encounter with the main enemy forces.?Only the layman believes that in the course of a campaign he sees the consistent implementation of an original thought that has been considered in advance in every detail and retained to the end.”