diff --git a/apps/website/public/images/when-speed-hurts.png b/apps/website/public/images/when-speed-hurts.png
new file mode 100644
index 00000000..8850b499
Binary files /dev/null and b/apps/website/public/images/when-speed-hurts.png differ
diff --git a/apps/website/src/content/posts/when-speed-hurts.md b/apps/website/src/content/posts/when-speed-hurts.md
new file mode 100644
index 00000000..4edd8887
--- /dev/null
+++ b/apps/website/src/content/posts/when-speed-hurts.md
@@ -0,0 +1,54 @@
+---
+title: "When Speed Hurts"
+description: "Some developers ship fast and test well—but leave teams cleaning up behind them. This post explores how to lead with empathy, model good habits, and create space for growth without sacrificing quality or team trust."
+createdAt: 1749117509543
+updatedAt: 1749117509543
+authors: ["david"]
+category: "DEVELOPER EXPERIENCE"
+editors: ["velimir"]
+abstract: "High-velocity developers can be both impressive and disruptive. While their code moves fast and comes with plenty of tests, it often reveals deeper issues: unnecessary complexity, bugs that escape into production, and resistance to feedback. This post unpacks the hidden cost of unchecked speed and what it means for team health and trust. It advocates for pair programming as a tool for modeling thoughtful engineering—not micromanagement—and shares guidance on when to coach, when to scope work differently, and when to escalate. By anchoring accountability in empathy and clarity, teams can maintain high standards without creating fear or resentment. Ultimately, great engineering isn’t just about speed—it’s about how well we build together."
+image: "/images/when-speed-hurts.png"
+draft: false
+---
+
+There’s a pattern I’ve seen pop up in teams more than once: a developer who writes code fast, impressively fast, with a bunch of unit tests to match. But when you dig into the details, things start to fall apart.
+
+The code is complex in ways it doesn’t need to be. It’s inefficient. And despite all those tests, real-world bugs slip through. Fixing or rewriting their work often means producing something simpler, clearer, and faster, sometimes dramatically so.
+
+This gets tricky when the developer doesn’t see a problem. They push back on feedback, confident that their approach is solid. This situation is not just about code, it’s about team dynamics, trust, and shared expectations.
+
+## Model, don't Micromanage
+
+I suggest starting with pair programming. It’s one of the best tools we have for modeling the kind of clarity and care we want in code. It lets you demonstrate real-time how decisions are made, how edge cases are considered, and how simplicity often wins.
+
+But it’s not just about writing better code side-by-side. It’s also a subtle way of aligning on standards without making it feel like a confrontation. Done well, it becomes a shared learning process, not a performance review.
+
+This kind of modeling helps build a foundation: here’s how we write code, here’s how we test, and here’s what quality looks like. Not as dogma, but as culture.
+
+## Scoping Feels Like a Cage
+
+Sometimes, when things don’t improve, the conversation shifts to scoping a teammate’s work more tightly, limiting the kind of tasks they take on, or the complexity they’re allowed to handle. That can be necessary, but we have to be careful.
+
+Too much restriction too early can backfire. For a teammate who’s trying to find their footing, especially a new hire, it can feel like punishment. Worse, it can damage their confidence and poison the relationship before it has a chance to grow.
+
+Alternatively, you can start by assigning lower-risk tasks where mistakes are easier to correct and learning curves are less steep. You still get signal on how they work, but the team doesn’t have to absorb as much risk.
+
+If things still don’t change, then yeah, escalation is on the table. Especially if their code regularly creates overhead for others. One person’s unchecked habits shouldn’t drag down the whole team, especially not when the rest of the team is putting in the effort to deliver quality work.
+
+## Not All Potential Is Productive
+
+It’s worth acknowledging that sometimes these developers have interesting ideas. They might have a good sense of architecture, or spot clever optimizations. But insight isn’t the same as execution. If those insights can’t be translated into outcome, then they’re not delivering value to the user.
+
+That doesn’t mean we throw them out. It does mean we stay honest. If the team is constantly rewriting or debugging one person’s output, that’s not sustainable. Whether the root issue is experience, attitude, or environment, pairing can help surface it. But pairing is not a silver bullet.
+
+At the end of the day, accountability matters. You can’t let one person’s patterns chip away at team velocity and morale.
+
+## Conclusion
+
+Healthy engineering culture isn't just about how fast someone can ship code. It's about how well we work together, how clearly we communicate in code and conversation, and how reliably we deliver value, together.
+
+When someone on the team moves fast but leaves others cleaning up behind them, it’s not just a technical problem. It’s a team health issue. The best path forward usually starts with empathy and shared effort, pair programming, modeling good habits, and offering a fair runway for improvement. But outcomes matter more than intentions.
+
+If a teammate can’t, or won’t, align with the team’s standards, it’s okay to name that. 
+
+Accountability isn’t harshness; it’s clarity. And clarity is one of the most generous things you can offer a teammate who’s struggling to keep up, not just for their sake, but for the sake of the team.