Not Everyone Always Agrees
Working with people from different tech backgrounds means you’re going to have disagreements. That’s usually fine — different perspectives are what make teams function well. The trouble is when those disagreements stop being about the problem and start being about who’s right.
I recently had a conversation with a developer colleague that didn’t go the way I expected. Another DBA and I noticed a query behaving unusually in our monitoring tool. When we brought it up, the explanation we got was dismissive — the developer brushed off concerns about security and performance, pivoting instead to “we’re focused on source control right now.” The attitude bordered on condescension.
In all my years in IT, I’d never felt so dismissed for raising a legitimate performance concern. And that’s the thing — the concern was legitimate. Source control and query performance are not in competition. You can care about both.
What’s Actually Going On
The DBA/developer tension isn’t new, and it’s rarely personal. Developers are under pressure to ship features; DBAs are focused on stability and performance. Both are valid. The problem is when either side treats the other’s domain as irrelevant.
Developers may not be SQL performance experts, and DBAs may not be front-end wizards — that’s fine, that’s why teams exist. But dismissing a performance concern because the person raising it is “just the DBA” isn’t a source control conversation. It’s a respect problem.
How to Handle It Without Making It Worse
A few things that actually help:
- Frame concerns in business terms — “this query pattern will cause blocking under load, which affects uptime” lands better than “this is bad SQL.”
- Pick the right moment — raising a performance concern mid-sprint in a group call puts people on the defensive. Bring it up one-on-one first.
- Acknowledge what they’re doing right — if someone is using source control, that’s genuinely good. Start there before getting to the concern.
- Know when to escalate — if a pattern is genuinely going to cause a production incident and the developer isn’t engaging, that’s a conversation for a team lead, not a longer argument.
The goal is software that ships and doesn’t blow up at 2am. That requires developers and DBAs to actually talk to each other.
Key Takeaways
- Dev/DBA friction is almost always about communication and framing, not technical incompatibility.
- Dismissing a performance concern because it came from a DBA is a collaboration failure, not a technical one.
- Building good relationships makes late-night incidents more bearable, speeds up resolution, and reduces the resentment that drives turnover.
- Frame concerns in terms of business impact — uptime, user experience, on-call risk — not just technical correctness.