<?xml version="1.0" encoding="utf-8"?><feed xmlns="http://www.w3.org/2005/Atom" ><generator uri="https://jekyllrb.com/" version="4.4.1">Jekyll</generator><link href="https://productionmatters.co/feed.xml" rel="self" type="application/atom+xml" /><link href="https://productionmatters.co/" rel="alternate" type="text/html" /><updated>2026-04-30T01:36:17+00:00</updated><id>https://productionmatters.co/feed.xml</id><title type="html">Production Matters</title><subtitle>Production Matters explores the intersection of process, people, and the business of games. Designed for producers who prioritize results over rituals, we provide deep-dive insights into optimizing game development cycles.</subtitle><author><name>Robbie Edwards</name></author><entry><title type="html">Great Days Make Great Output</title><link href="https://productionmatters.co/production/leadership/2026/04/29/great-days-make-great-output.html" rel="alternate" type="text/html" title="Great Days Make Great Output" /><published>2026-04-29T05:00:00+00:00</published><updated>2026-04-29T05:00:00+00:00</updated><id>https://productionmatters.co/production/leadership/2026/04/29/great-days-make-great-output</id><content type="html" xml:base="https://productionmatters.co/production/leadership/2026/04/29/great-days-make-great-output.html"><![CDATA[<p>I want to talk about great days, and why I think they’re a simple guide for doing a producer’s job.</p>

<p>Take a second and picture your best day at work. Everything you tried just <em>worked</em>. Blockers cleared. You finished what you set out to finish, you got real feedback on it, and you walked away feeling capable, energized, and a little bit proud. That day wasn’t just good for you — it was almost certainly a high-value day for the company too.</p>

<p>Now hold that picture, because it leads to a hypothesis that’s almost embarrassingly simple:</p>

<p><strong>A team’s output is a function of how many great days the team has.</strong> If we want to maximize the value a team creates, our job as producers is to make great days as common as possible. Which mostly means removing the things that get in the way of them.</p>

<p>So let’s flip the question. What gets in the way of a great day?</p>

<h2 id="1-confusion-and-chaos">1. Confusion and chaos</h2>

<p>The first thing that kills a great day is confusion — not knowing what’s most important, not knowing where to look for an answer, getting blindsided by something nobody told you about. If every time you have a question you can find the right answer quickly, and without disrupting someone else, that’s a multiplier on every hour of the day.</p>

<p>So what does that look like in practice? Well-organized, consistent documentation. A search experience — or an AI assistant — that actually returns the right answer. And critically, an <em>expectation</em> on the team that searching is going to work. Because here’s what happens if it doesn’t: people search and fail, search and fail, search and fail — and then they stop searching. They start asking people instead.</p>

<p>Asking people sounds fine, but it injects new chaos. You’ve played the telephone game. Information doesn’t transfer cleanly between humans; even when the same person answers the same question twice, it comes out a little differently and lands differently. Documentation, by contrast, is delivered the same way every time. With practice and standards, you can even improve how it’s <em>received</em>. Save time finding information, align how people interpret it — that’s a recipe for more great days.</p>

<h2 id="2-missing-or-inadequate-tools">2. Missing or inadequate tools</h2>

<p>Another thing that wrecks a great day is not having the equipment or software you need to actually do your job.</p>

<p>When SSDs first came out, they were expensive — a few hundred dollars for a small one, more for the big ones. But if you’re cutting an engineer’s compile time from 30 minutes to 5, and they’re compiling six, eight, twelve times a day, the math gets obvious fast. Same idea, lower stakes: imagine asking someone to manage tables in Notepad instead of Excel. You can feel the friction in your bones.</p>

<p>Do everything you can to make sure your team has the right tools — <em>and</em> knows how to use them. A best-in-class tool no one can drive is just shelfware.</p>

<h2 id="3-culture">3. Culture</h2>

<p>Mindset and culture get in the way of great days too. There’s a particular kind of low-grade, ambient negativity — the constant venting that fills the air without ever turning into action — that’s surprisingly contagious. It’s hard for those feelings to <em>not</em> infect everyone within earshot.</p>

<p>A workplace, as much as we can manage it, should be a place of joy and positive, productive energy. That’s not the same as ignoring problems. There’s a real difference between “we have this problem, everything sucks, woe is me” and “yeah, we have this problem; problems exist; this isn’t easy — let’s figure out how to fix it.” The expectation that there <em>won’t</em> be problems is unrealistic. The expectation that we’ll face them with positivity is not.</p>

<h2 id="4-not-knowing-what-success-looks-like">4. Not knowing what success looks like</h2>

<p>The last one — and maybe the sneakiest — is not knowing when you’re done.</p>

<p>If I tell you to drive to Kansas City, that’s pretty clear. You arrive in a car, you’re there. But if I tell you to “get yourself to a Midwestern city,” there’s a lot more vagary. Maybe that’s fine; maybe any Midwestern city works. But if I had Kansas City in my head and didn’t say so, you can do good work and still miss the target. You’re moving, but you don’t know how to judge whether you’re succeeding.</p>

<p>For people to have great days, they need to know what success looks like. That’s bigger than agile acceptance criteria, though acceptance criteria are one mechanism. It runs all the way up into <em>how we set goals</em> in the first place — which is a whole separate post, and one I owe you.</p>

<h2 id="the-job-in-one-sentence">The job, in one sentence</h2>

<p>Documentation, tools, culture, success criteria — those are the four big rocks I keep coming back to. There are more, of course. But if you want a high-performing, motivated, energetic team, the question to ask is almost always the same one:</p>

<p><strong>What’s getting in the way of my team having a great day today, and what can I remove?</strong></p>

<p>If you’re wrestling with that question on your own team, I’d love to hear what you’ve found. Drop a comment, or share this with the producer in your life who’s doing the work of clearing the path. The more examples we collect of barriers worth removing, the better the playbook gets for everyone.</p>]]></content><author><name>Robbie Edwards</name></author><category term="production" /><category term="leadership" /><summary type="html"><![CDATA[I want to talk about great days, and why I think they’re a simple guide for doing a producer’s job.]]></summary></entry><entry><title type="html">What is Production?</title><link href="https://productionmatters.co/jekyll/update/2026/01/06/what-is-production.html" rel="alternate" type="text/html" title="What is Production?" /><published>2026-01-06T23:28:33+00:00</published><updated>2026-01-06T23:28:33+00:00</updated><id>https://productionmatters.co/jekyll/update/2026/01/06/what-is-production</id><content type="html" xml:base="https://productionmatters.co/jekyll/update/2026/01/06/what-is-production.html"><![CDATA[<p>Depending on who you ask or where you work, the question “What does production do?” can elicit answers that cover the complete spectrum of skills relevant to development or project completion. I find this variety interesting as it allows for various skill profiles to find success in the job, but certainly, there has to be a key responsibility of the role.</p>

<p>I believe the job of production is to help the team be “greater than the sum of their parts”. I often describe production as a force multiplier, “a factor that gives [a team] the ability to accomplish greater feats than without it”. Consider a team of 10 developers without production and that they create value in the project at a rate of 1 units per work period, for a total of 10. Simplistically, adding an 11 dev would increase the teams value creation to a rate of 11. Thus, for a producer to be a better choice than an 11th dev, they will need to improve the teams value creation overall by at least 10% to reach the value creation rate of 11 from the baseline 11 dev team. So how do we gain this 10%?</p>

<p>Engine efficiency of thermal engines is the relationship between the total energy contained in the fuel, and the amount of energy used to perform useful work.
<img src="https://en.wikipedia.org/wiki/Engine_efficiency" alt="alt text" title="Engine Efficiency" /></p>

<p>A team is like an engine. There is a finite amount of effort the team can give (total energy in fuel) and the overall quality of the project is directly related to how much of that effort can be realized as user value (useful work) in the project. Internal combustion engines are generally between 20-40% efficient, losing the other energy through friction and heat. Our teams are losing efficiency through unclear vision and objectives, context switching, waiting for approvals, over scoping, defects and all the common wastes of software development. Quite simply, any dealignment or confusion in the team is draining your team of it’s precious energy and not producing useful work. Further, given the passionate nature of our industry and that our engine is made of people, not metal, a good bit of energy is lost in the emotions of development and the wear and tear of long crunch periods.</p>

<p>With this in mind, improving 10% seems much more reasonable now. All we must do is remove entropy from the project. Reduce chaos and wrangle the agents that introduce it. Implement clear and consistent process. Manufacture clarity through culture and process.</p>

<p>So, what is production? Well, we are the mechanics on racing car engines, doing everything we can to extract the maximum amount of useful work while ensuring the engine can complete the race. And like any good mechanic, we will depend heavily on our tools. I hope future articles of this blog can help you add tools to your kit.</p>]]></content><author><name>Robbie Edwards</name></author><category term="jekyll" /><category term="update" /><summary type="html"><![CDATA[Depending on who you ask or where you work, the question “What does production do?” can elicit answers that cover the complete spectrum of skills relevant to development or project completion. I find this variety interesting as it allows for various skill profiles to find success in the job, but certainly, there has to be a key responsibility of the role.]]></summary></entry></feed>