August 9, 2017 at 7:25 am
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?
August 9, 2017 at 8:34 am
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
August 9, 2017 at 8:55 am
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.
-- Itzik Ben-Gan 2001
August 9, 2017 at 12:15 pm
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.
August 9, 2017 at 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).
August 9, 2017 at 2:22 pm
gwellbrock - Wednesday, August 9, 2017 2:05 PMThanks 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.
August 10, 2017 at 5:44 am
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
Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning
August 10, 2017 at 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.
August 10, 2017 at 7:23 am
ZZartin - Wednesday, August 9, 2017 2:22 PMI 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.
August 10, 2017 at 7:28 am
xsevensinzx - Thursday, August 10, 2017 6:48 AMIt 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 9 (of 9 total)
You must be logged in to reply to this topic. Login to reply