SQL Clone
SQLServerCentral is supported by Redgate
 
Log in  ::  Register  ::  Not logged in
 
 
 


AGILE GONE WILD


AGILE GONE WILD

Author
Message
steve.ledridge
steve.ledridge
Valued Member
Valued Member (67 reputation)Valued Member (67 reputation)Valued Member (67 reputation)Valued Member (67 reputation)Valued Member (67 reputation)Valued Member (67 reputation)Valued Member (67 reputation)Valued Member (67 reputation)

Group: General Forum Members
Points: 67 Visits: 331
Anybody have advice on conversions from "Technical Silos" to "Functional Groups". We are going through a re-org and what might make sense for some skill sets, does not seem to make sense for the operations DBA team. What is wrong with teams that focus on improving specific skills and systems instead of trying to absorb other technologies in order to provide substandard on call support participation.

We are only 3 DBA's that manage over 200 SQL Servers and the only reason we have kept things manageable, is the standardization we have made across all servers and I fear that if we are split into separate teams we will lose our common focus. A major portion of our duties are generic care and feeding of sql servers, performance troubleshooting, reliable DB deployment, and maintenance of updated lower environments.

If we are not working together it will be impossible for improvements made by one DBA to be known and used by the others. And the idea of one of the new team members from what used to be storage, networking, or platforms troubleshooting performance problems in a 1200 line stored procedure is as scary as letting me play with firewall rules or AD settings.
wolfkillj
wolfkillj
SSCrazy
SSCrazy (2.7K reputation)SSCrazy (2.7K reputation)SSCrazy (2.7K reputation)SSCrazy (2.7K reputation)SSCrazy (2.7K reputation)SSCrazy (2.7K reputation)SSCrazy (2.7K reputation)SSCrazy (2.7K reputation)

Group: General Forum Members
Points: 2724 Visits: 2582
steve.ledridge (11/14/2013)
Anybody have advice on conversions from "Technical Silos" to "Functional Groups". We are going through a re-org and what might make sense for some skill sets, does not seem to make sense for the operations DBA team. What is wrong with teams that focus on improving specific skills and systems instead of trying to absorb other technologies in order to provide substandard on call support participation.

We are only 3 DBA's that manage over 200 SQL Servers and the only reason we have kept things manageable, is the standardization we have made across all servers and I fear that if we are split into separate teams we will lose our common focus. A major portion of our duties are generic care and feeding of sql servers, performance troubleshooting, reliable DB deployment, and maintenance of updated lower environments.

If we are not working together it will be impossible for improvements made by one DBA to be known and used by the others. And the idea of one of the new team members from what used to be storage, networking, or platforms troubleshooting performance problems in a 1200 line stored procedure is as scary as letting me play with firewall rules or AD settings.





OK, what you described in the part of your post that I put in bold type seems silly. "Functional groups" should mean "a group of people with various skill sets (possibly from various organizations within the company) who work cooperatively to achieve a common goal", not "a team where everyone tries to do the work that falls in everyone else's areas of expertise." It's an absolute waste to have a storage systems engineer troubleshooting database performance issues or a DBA debugging .NET code. It that's what your employer is planning, I would start looking for a new job ASAP.

My employer has separate development groups for each product line that include application developers, web designers, database developers, etc. and a separate DBA group that manages the SQL Server infrastructure. Each DBA primarily supports a particular development group or groups (although any of the DBAs can assist any development group as needed) and thus gets to know the people and business of "his" development group(s) but is directly responsible to the DBA manager for things like standardization, availability, security, maintenance, disaster recovery, etc. When both sides work to develop good communication and working relationships, conflicts between the needs and goals of the development groups and the needs and goals of the DBA group become much easier to resolve and everyone becomes more productive.

Jason Wolfkill
Blog: SQLSouth
Twitter: @SQLSouth
Go


Permissions

You can't post new topics.
You can't post topic replies.
You can't post new polls.
You can't post replies to polls.
You can't edit your own topics.
You can't delete your own topics.
You can't edit other topics.
You can't delete other topics.
You can't edit your own posts.
You can't edit other posts.
You can't delete your own posts.
You can't delete other posts.
You can't post events.
You can't edit your own events.
You can't edit other events.
You can't delete your own events.
You can't delete other events.
You can't send private messages.
You can't send emails.
You can read topics.
You can't vote in polls.
You can't upload attachments.
You can download attachments.
You can't post HTML code.
You can't edit HTML code.
You can't post IFCode.
You can't post JavaScript.
You can post emoticons.
You can't post or upload images.

Select a forum

































































































































































SQLServerCentral


Search