[mgkimsal]

As with many positions, there's a middle ground. I don't expect people to be able to dive in deep in to the innards of MSSQL and understand all the nuance between types of indexes and how different hardware choices can impact said index types. However, when working with "sr software engineers" who are responsible for SQL, I do expect someone to be able to set up a local test database and create some tables with sample data to demonstrate an idea (in whatever tech they choose).

I would argue that "sys admins" - in the form of dedicated personnel - are not "critical to an product/company". I know plenty of smaller companies who are successfully bringing in profits, making payroll, etc, but do not have any sysadmins employed. At some point, they will need those skills (and probably stronger DB skills) but these aren't always critical to every project/company/org. Perfect is the enemy of the good.

EDIT: middle ground.

[marktangotango]

I've seen one team of devs in particular do a really nice job with their sql database, but more often than not dev teams trash their schema and databases, if they're using sql at all. They create rdbs that are not normalized, don't have foreign key constraints, too many indexes (index on every column to get this dashboard query to perform! I've seen this a sad number of times).

Yeah sure sys admins and dbas aren't critical, but if an organization values what they can do, they can multiply the productivity and effectiveness of the app and product teams.

Specifically, features are faster to implement because the schema is not jacked, the app is responsive and stable because the data is normalizesd and indexed for the access patterns, data is consistent. Customers are happy.

Similar for the network/server side for sys admins.

[mgkimsal]

No doubt there's a potential for abuse, and there's middle grounds to be had. I've also caught hell from a PM for a project being 'late', even though I had 0 control over actually getting DB changes in, because the DBA was a) on vacation, then B) sick, then C) backed up on other work. But apparently, it was my team's fault that the project relying on a SQL database was not launched "on time" (a deadline I had no hand in making, nor did I agree to either).

The policy of "only DBA can make any changes to anything, and all schema changes have to be discussed, reviewed, vetted and approved by DBA" has benefits, in some situations, but also problems.

I had a DBA question why I needed pagination. "No one has ever asked for it before, and never needed it, and I think you're building your application wrong if you need that". After a few weeks of contentious meetings, we got hand-rolled stored procedures for each specific table/query, but they also took days to get to us.

But, hey, you know... at least the tables were normalized and we had "proper" indexes. We just took weeks to get done what should have taken a few hours to prototype (because, during the time we were building the tool, the team we were building it for ended up buying some third party service because we were taking so long).

We've all got war stories of incompetence on all sides (dba, dev, pm, whatever). This is why I advocate "middle ground". I trust a DBA who's actually done a bit of raw coding in their life. I trust a developer who understands the basics of SQL and DB workings (again, 'basics' are fine). I trust the estimates of a PM who is engaged with the team on a regular basis. I trust the views of a business analyst more if they actually show up to meetings and listen to the parties involved.