Michael Dwan

𝐂𝐓𝐎 𝐚𝐧𝐝 𝐓𝐞𝐜𝐡 𝐃𝐢𝐫𝐞𝐜𝐭𝐨𝐫 𝐚𝐫𝐞 𝐭𝐫𝐚𝐧𝐬𝐥𝐚𝐭𝐨𝐫𝐬 (post 1 of 2) In the games industry, a Technical Director’s most important tool isn't a compiler: it’s translation. If your non-technical peers (Designers, Producers, and Executives) don’t understand why you’re making a technical decision, it’s not because they aren't "technical enough." It’s because you haven't translated the Technical Reality into Business Value. Here is the blueprint for technical communication that builds trust, reduces friction, and keeps the engine running through the chaos of game dev. ------------------------------------------------- 𝟏. 𝐒𝐭𝐨𝐩 𝐓𝐚𝐥𝐤𝐢𝐧𝐠 𝐀𝐛𝐨𝐮𝐭 𝐂𝐨𝐝𝐞; 𝐒𝐭𝐚𝐫𝐭 𝐓𝐚𝐥𝐤𝐢𝐧𝐠 𝐀𝐛𝐨𝐮𝐭 "𝐕𝐞𝐥𝐨𝐜𝐢𝐭𝐲" Your CEO or Producer doesn't need to know about a race condition in your multithreading logic. They need to know how it affects the Player Experience or the Development Timeline. • Don't say: "We need to refactor the entity component system because the cache misses are spiking." • Do say: "The current system is slowing down our iteration speed. If we spend 3 days optimizing it now, we will save the design team 2 hours of waiting for builds every single day for the rest of the project." 𝟐. 𝐂𝐨𝐦𝐦𝐮𝐧𝐢𝐜𝐚𝐭𝐢𝐧𝐠 𝐓𝐞𝐜𝐡𝐧𝐢𝐜𝐚𝐥 𝐃𝐞𝐛𝐭 𝐚𝐬 "𝐇𝐢𝐠𝐡-𝐈𝐧𝐭𝐞𝐫𝐞𝐬𝐭 𝐋𝐨𝐚𝐧𝐬" Technical debt is an abstract concept to non-coders. Use the financial metaphor. Explain that taking a "shortcut" to hit a milestone is a loan. You get the feature now, but you pay "interest" every week in the form of bugs and slower feature development. Eventually, the interest becomes so high that you can no longer afford to build new features at all. 𝟑. 𝐓𝐡𝐞 "𝐃𝐞𝐬𝐢𝐠𝐧 𝐏𝐢𝐯𝐨𝐭" 𝐚𝐧𝐝 𝐀𝐫𝐜𝐡𝐢𝐭𝐞𝐜𝐭𝐮𝐫𝐚𝐥 𝐇𝐲𝐠𝐢𝐞𝐧𝐞 The most difficult communication happens when the Product Design changes. Suddenly, your "Interior Design" (the internal architecture) no longer fits the "Floor Plan" (the game design). • Be Transparent about the Ripple Effect: When a designer says, "Let’s make it multiplayer instead of single-player," they see a UI change. You see a foundation change. • The Analogy: "Changing this core mechanic is like deciding to add a basement to a house after the roof is already on. We can do it, but we have to lift the whole house up first." • The Strategy: Use Ed Catmull’s "Braintrust" model. Bring the designers into a high-candor session where you explain the why of the refactor. Show them that "cleaning up" isn't a luxury—it’s the only way to ensure the game doesn't crash on launch day. (cont...) #CTO #TechnicalDirector #TechnicalDebt #CommunicationSkills #ProductStrategy

3