Who Really Owns Code Quality — PM or Tech Lead?
🚨 Stop Shipping Band-Aids
Why your team keeps fixing symptoms instead of solving problems—and how to stop it before your game collapses under its own code.
🎯 The Real Problem Nobody Wants to Admit
Let’s be blunt.
Bad code doesn’t happen because developers are lazy.
Band-aid fixes don’t happen because teams are incompetent.
They happen because:
No one clearly owns code quality—and everyone assumes someone else does.
This creates a dangerous triangle:
- 🧠 Project Manager (PM) → pushing deadlines
- 🛠️ Tech Lead (Frontend/Backend) → juggling architecture + delivery
- 👨💻 Developers → stuck firefighting
And somewhere in between?
👉 Code quality quietly dies.
⚔️ PM vs Tech Lead: The Ownership War
🧩 The Common Misconception
Many teams think:
- “PM handles delivery”
- “Tech Lead handles code”
Sounds clean… but in reality?
❌ This separation is exactly what causes band-aid culture.
🧠 The Truth: Code Quality Is a Shared Responsibility (But Not Equal)
Let’s draw a clear line.
👑 Tech Lead Owns:
- Code architecture
- Coding standards
- Code review enforcement
- Technical debt decisions
👉 If the codebase becomes messy, unstable, or unscalable
the Tech Lead is accountable.
🎯 Project Manager Owns:
- Timeline pressure
- Scope decisions
- Prioritization (features vs quality)
- Risk visibility
👉 If the team is rushing and skipping proper solutions
the PM is responsible.
💣 The Real Killer: Timeline Pressure → Band-Aid Fixing
Here’s what actually happens in most teams:
- Bug appears
- Deadline is close
- PM asks: “Can we fix it quickly?”
- Developer patches it
- Nobody revisits it
🎉 Bug solved… temporarily.
💀 Technical debt increases permanently.
🔁 Repeat this 20 times and you get:
- Fragile systems
- Slow development
- Endless regressions
- Burned-out developers
🔍 Why Developers Default to Band-Aids
Let’s be honest—developers are rational.
They choose band-aids because:
- ⏱️ They’re faster
- 📉 They reduce immediate pressure
- 🙈 Nobody tracks long-term damage
- 🧑⚖️ No one penalizes bad fixes
👉 In short:
The system rewards quick fixes, not good solutions.
🧠 The PM’s Hidden Power (That Most Don’t Use)
A good PM doesn’t just manage tasks.
👉 They shape team behavior.
If your team keeps shipping band-aids, it’s usually because:
- There’s no space for proper fixes
- There’s no visibility of technical debt
- There’s no consequence for poor quality
🔥 How PMs Can Prevent Bad Coding (Without Micromanaging)
Here’s where things get interesting.
You don’t need to read code to improve code quality.
✅ 1. Change the Question
Instead of:
“Can we fix this quickly?”
Ask:
“Is this a temporary fix or a proper solution?”
This alone changes developer behavior instantly.
✅ 2. Force Visibility of Technical Debt
Create a rule:
- Every band-aid fix must log a technical debt ticket
Now:
- Nothing disappears
- Debt becomes measurable
- Trade-offs become visible
✅ 3. Introduce “No Silent Hacks” Policy
Band-aid fixes are allowed… but only if:
- They are documented
- They are tracked
- They have a follow-up plan
👉 No more invisible problems.
✅ 4. Protect Refactoring Time
If everything is “urgent,” nothing is important.
Allocate:
-
10–20% sprint capacity for:
- Refactoring
- Cleanup
- System improvements
👉 This is where long-term quality is built.
✅ 5. Ask Tech Leads the Right Questions
Instead of:
- “When will this be done?”
Ask:
- “Will this scale?”
- “What’s the long-term impact?”
- “Are we creating debt here?”
👉 You don’t need to know the answer—just force the thinking.
🛠️ What Tech Leads Must Stop Doing
Let’s flip the table.
Tech Leads are not innocent here.
❌ Mistake #1: Accepting Unrealistic Timelines
If you say “yes” to everything:
👉 You are choosing bad code.
❌ Mistake #2: Silent Compromise
Many Tech Leads think:
“We’ll fix it later.”
Reality:
👉 You won’t.
❌ Mistake #3: Weak Code Review Culture
If PR reviews are rushed or superficial:
💥 Bad patterns multiply fast.
🤝 The Ideal PM + Tech Lead Partnership
This is what high-performing teams do differently:
💬 Constant Alignment
PM:
“We need this feature fast.”
Tech Lead:
“We can do it fast—but here’s the cost.”
👉 Decision is shared, not assumed.
⚖️ Explicit Trade-Offs
Every shortcut is:
- Known
- Documented
- Scheduled for revisit
🔁 Continuous Feedback Loop
- Bugs → Root cause analysis
- Fix → Prevention strategy
👉 Not just “fixing issues,” but eliminating them
🧨 A Dangerous Pattern You Should Watch For
If your team says this often:
- “We’ll clean it up later”
- “This is just temporary”
- “It works, don’t touch it”
🚨 You are already in band-aid territory.
🧠 A Better Mental Model
Think of your codebase like a city:
- Band-aid fixes = quick road patches
- Good engineering = proper infrastructure
👉 Too many patches, and the whole system collapses.
🚀 Actionable Framework: The “No Band-Aid System”
If you want something practical, implement this:
🧩 Rule #1: Every shortcut is tracked
🧩 Rule #2: Every bug has a root cause
🧩 Rule #3: Every sprint includes cleanup
🧩 Rule #4: Every trade-off is visible
🎮 Why This Matters More in Game Development
Game dev is especially vulnerable because:
- Deadlines are brutal (launch dates, events)
- Systems are interconnected (small bugs ripple hard)
- Teams are often cross-functional
👉 One bad system can destroy:
- Performance
- Player experience
- Live ops stability
🔥 Final Take: Who Owns Code Quality?
Let’s settle it.
👉 Tech Lead owns the “how”
👉 PM owns the “pressure”
And together:
They define whether the team builds a system… or just keeps patching one.
💡 Closing Thought
Bad code is rarely a technical problem.
It’s a communication problem disguised as a technical one.
Fix the communication—and you fix the code.
🔥 Want More Like This?
If you’re serious about leveling up your game production skills, check out:
Comments