What Department should Data teams fall under?

  • I run a data team that consists of DBA, Database Developers and Data scientists.  For the last 7 years my team has fallen under the infrastructure team department.  Generally at group lead meetings people don't really care anything about what I am saying as they are talking about SAN, VMWare, etc... We have recently created a DEVops team and I think it makes sense for the data team to fall under that rather than RD side of things or IT.  Any thoughts and I'm curious where these teams fall in different organizations?

  • Our database team is in the Development department. Other database teams of other divisions in my company also belong to the development departments.

    Igor Micev,
    My blog: www.igormicev.com

  • This will differ from company to company based on the size of the company, it's governance and size. Often I've seen the database people (e.g. DBA, SQL/BI Developers/Data Scientists) as part of the groups called IM&A (Information Management and Analytics) or ARG (Analytics and Reporting Group). Generally these groups rollup to the Information Technology group lead by a CTO or VP of IT. 

    I have also seen similar situations like yours where the data people are simply part of I.T. which is not good governance IMHO considering how important data is today for any business.

    "I cant stress enough the importance of switching from a sequential files mindset to set-based thinking. After you make the switch, you can spend your time tuning and optimizing your queries instead of maintaining lengthy, poor-performing code."

    -- Itzik Ben-Gan 2001

  • I'd think that Database Developers would be required to be in a separate group from DBAs, especially if you're in a public company, as a separation of duties thing.  I don't think I've worked in a company where developers and DBAs where in the same group.

  • Thanks for the replies - we are a software company and fairly small(500 people).  We all somewhat share each others duties as well at this point - 6 person team and we support MySQL,Postgres,Mongo,Db2 and mssql(due to aquisitions not a plan to have that many platforms).

  • gwellbrock - Wednesday, August 9, 2017 2:05 PM

    Thanks for the replies - we are a software company and fairly small(500 people).  We all somewhat share each others duties as well at this point - 6 person team and we support MySQL,Postgres,Mongo,Db2 and mssql(due to aquisitions not a plan to have that many platforms).

    I would think that for a software company you would also need to differentiate who is working on developing your product vs who is supporting your internal processes.

  • Yes.

    Oh, I see what you mean. From a management stand point, it can be really tough. Databases straddle the line so much between a pure development role and a pure IT management role that it can be difficult. Most places I've seen tend to put them onto the IT side of things for management & reporting. However, successful companies do this while also placing the data people into well-entrenched positions within development. Basically, DevOps. If you have a separate DevOps structure within the organization, then yeah, that's where they'd go. However, I've seen it all over the map, so I'm not sure there is a one-size fits all answer to this.

    ----------------------------------------------------
    The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood...
    Theodore Roosevelt

    The Scary DBA
    Author of: SQL Server 2017 Query Performance Tuning, 5th Edition and SQL Server Execution Plans, 3rd Edition
    Product Evangelist for Red Gate Software

  • It makes more sense to group positions based on projects rather than job titles. Teams should be built to work together, not work in silos who can sometimes help each other because they share the same job title or function.

  • ZZartin - Wednesday, August 9, 2017 2:22 PM

    I would think that for a software company you would also need to differentiate who is working on developing your product vs who is supporting your internal processes.

    Totally agree, the software company and software as a service companies that I've worked for did separate internal from product development.

  • xsevensinzx - Thursday, August 10, 2017 6:48 AM

    It makes more sense to group positions based on projects rather than job titles. Teams should be built to work together, not work in silos who can sometimes help each other because they share the same job title or function.

    It may depend on the projects at that company.  If it's a company where projects are short term, come and go, it may make more sense then to have the job title based organization, even though the people wouldn't be doing work for that org manager, they'd be doing work for the individual project manager they were currently assigned to, and the org manager would essentially be managing a pool of resources to assign to different projects.
    If the projects are very long term, or permanent, then it would be simpler and easier to have the org manager and project manager be the same person.

Viewing 10 posts - 1 through 10 (of 10 total)

You must be logged in to reply to this topic. Login to reply