Click here to monitor SSC
SQLServerCentral is supported by Red Gate Software Ltd.
 
Log in  ::  Register  ::  Not logged in
 
 
 
        
Home       Members    Calendar    Who's On


Add to briefcase

AGILE GONE WILD Expand / Collapse
Author
Message
Posted Thursday, November 14, 2013 1:29 AM
Grasshopper

GrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopper

Group: General Forum Members
Last Login: Monday, September 8, 2014 5:29 PM
Points: 13, Visits: 196
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.



Post #1514165
Posted Friday, November 15, 2013 12:23 PM


Ten Centuries

Ten CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen Centuries

Group: General Forum Members
Last Login: Today @ 9:45 AM
Points: 1,222, Visits: 2,546
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
Post #1514817
« Prev Topic | Next Topic »

Add to briefcase

Permissions Expand / Collapse