Now that I’ve been in this field for a while (“Business Intelligence” - 1.5 years and analytics in general for another few years prior to that), and seen various segments of business, worked with many different teams of stakeholders, been laid off, and seen others get laid off, I’ve started to think more meta about the field. In this post I’ll specifically talk about analytics team organizational structuring that I’ve experienced, and, surprise–I have problems with all of them! (Not to worry, the pros are always worth considering as well)
I have had the chance to be an analyst at various sized companies from semi-early startup to fully mature large company. A low down of my various org structures (by the way, I’m hoping to not specifically burn any org/person. Any cons I point out I believe are somewhat universal problems for the specified structure):
Decentralized analyst
I reported directly into product, which channeled most of my focus towards product manager needs (product did direct me to help other teams as needed).
The Good I was a jack of all trades here, grabbing data on my own, nagging engineers to give me data, building dashboards, and attending meetings. Learning R and docker helped me do anything needed, and I was given the freedom to do whatever I needed. I was the best provider of data for my product group because I had the most context. I learned agile, I learned about engineering, I knew my product 100%.
The Less Good I was the only provider of this kind of data, because I had no one to share knowledge with. It was hard to get my work checked. The hardest thing to deal with was I didn’t know what my upwards trajectory was, because everyone around me was a product manager. I actually eventually completed nearly every data project, and was starting to be moved into a more engineering feeling role before leaving.
Analyst on larger centralized data team
Reported into a data or operations org.
The Good I was able to work on projects for various stakeholders from finance to product to marketing, which was a nice way to test things out. I had a team to chat with about analyses. Being in the same team as data engineers allowed me to make more impact on data engineering decisions. My focus was only on a few things: ensuring data quality, building dashboards, and ‘creating insights’, the latter of which was difficult due to “cons” below, but I did have a chance here to really improve my ability to use SQL and focus just on dashboards and visualizations for various levels of data-adept stakeholders. There was a clearer way “up”.
The Less Good Being organizationally distant from the stakeholders teams, I found it hard to get the full context I needed to create impactful insights or even clean data properly. There were also more politics at play due to me not technically being part of my stakeholders' teams. Despite being on a ‘centralized’ team, many of the analysts were specialized in a few areas anyway – knowledge transfer only occured if I switched gears to yet another stakeholder. It didn’t feel any less “ad-hoc” than my role reporting directly to my stakeholder, which is what I told would be the case.
Tiny analyst team reporting into leadership
The Good Similar to my above description of the centralized team, I did work on many different projects and changed gears often which kept things pretty fresh. This experience was more positive because of the org structure and people, perhaps because I reported into someone who really trusted the data and was in charge of things. This helped get buy in and cooperation from others. Since the team was still very very small I was not as focussed on just reporting and had to utilize a more “jack of all trades” style of working (conditionally, either a pro or con)
The Less Good Ultimately since we reported into the leader, we sort of felt the pains when the leader we reported into changed. The structure was not scalable, and eventually I think it’d either look like one of the above situations. Similar to the above centralized team case, I felt a bit removed from what was most important, perhaps because I did not have my eyes on what ended up being most important KPIs. Again, my path “upwards” seemed odd.
OK, so what should I do if I want to start an analytics team?
I really think that all of the solutions I’ve seen thus far are wrong answers only. I’ve read pros and cons of different teams as mentioned by McKinsey or Fivetran or elsewhere, and this post was mainly meant to agree with experiences that seem to be common, not specifically call out my employers, managers, or stakeholders. Actually, I really appreciate everything I’ve learned thus far and all of my experiences in this fast-changing field. These articles seem to hint that there is another way that meshes all of these ideas together to some ‘ideal’ structure, perhaps that is the way and I just haven’t seen it.
I like to believe that some of the cons I mention are be way outweighed by the pros. The balance depends on the org culture and the managers I interact with. Would business stakeholders be open to having a third party “consultant” type of analyst swing by and try and answer their questions? Would they prefer to have someone that they can count on 8 hours a day, every working day, to know the ins-and-outs of the data & business?
Of course I think another huge consideration is business maturity and size. Maybe decentralized teams make more sense at large companies. Maybe having a centralized team early in startup development allows for the most agility and flexibility with only a single hire (in this case, I’d suggest hiring a literal rock star unicorn). Or maybe it’s the other way around! It’s hard for me to say, as I’m still rather young.
Would love any feedback on this, to anyone who has feedback.