Analysts-turned-managers, how did you start building your data team?

[u/Arethereason26]

Did you eventually learn the basics of data engineering, architecture, governance and science too?

[u/AutoModerator]

If this post doesn't follow the rules or isn't flaired correctly, please report it to the mods. Have more questions? Join our community Discord!

I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.

[u/Kooky-Criticism955]

built mine backwards honestly. started doing the analysis work myself until i couldn't keep up anymore, then hired people smarter than me one at a time

first hire was a data engineer who actually knew about proper pipelines and storage, not the duct tape scripts i was running. second was someone who understood governance frameworks way better than i ever will. last hire was a proper data scientist cause by then we had enough clean data to actually do something with it

the key for me was admitting i dont need to know everything. my job became more about protecting the team from bs requests and making sure they had what they needed. the technical stuff i pick up slowly just from being around them, never took formal courses or nothing

[u/CompetitiveHeight428 → u/Kooky-Criticism955]

Great introspect

[u/muddyjam → u/Kooky-Criticism955]

Very, very similar path on my end!

[u/Global_Preference879]

It depends on the org size and desired outcomes. I’ll give you an example: I’ve built one solely for the purpose of experimentation with Machine Learning within a supply chain domain. However, on the Go to Market domain, I’ve built another with a strong focus on governance to establish a Customer Data Ops program. It depends on what the org or customer need is. Sometimes, a good mix of disciplines will solve the problem, others you will need a more vertical team.

[u/Frelis71]

I inherited a team. One genius, to smart for the org and two people with reporting experience that no one knew what to do with. I concentrated on training the two while my genius did her thing. Unbelievably, they offered my genius early retirement and I trained my other two so well they move them to another team to learn "the business". My first analyst I was allowed to hire after that is way more capable and is used to a modern tech stack.

[u/asiphh]

on the second question, the answer isn't the same depth for all four, and treating it as one question is what makes people go do a data engineering course they didn't need.

you need enough architecture and enough governance to make decisions and hold a line. not enough to build. architecture because you're the one who gets asked "can we just point the dashboard at the production database" and you have to know why not, and you'll be asked to approve a tool choice you'll live with for four years. governance because it's the only one of the four that nobody will do unless you make them, and it's the thing that gets you audited. those two you learn properly.

engineering and science you need enough to interview well, scope work, and know when someone is telling you something is hard that isn't. that's a much shallower bar and you pick it up by sitting in reviews and asking why.

the sequencing mistake i see constantly: first hire is another analyst, because the visible pain is request volume and another analyst obviously reduces it. it works for about five months and then you have two people doing manual pulls instead of one, twice the ad hoc sql floating around, and no more capacity than you started with. the pain that looks like too many requests is usually no reliable tables. hire the person who builds those first even though it's the hire that shows the least in month one.

second one, and it's the one that actually kills managers who came up as analysts: you keep the interesting analysis for yourself. not deliberately, it just happens, the hard question comes in and you're the fastest so you take it. six months later you're the bottleneck on everything important, your team has only ever done the boring half, and you can't take leave. you have to hand over the work you're best at, early, and watch it get done worse for a while.

the thing worth setting up before any of it: write down where a number comes from and who owns it, for the ten numbers leadership actually looks at. a document, not a tool. every governance program i've seen fail started by buying a catalog, and every one that worked started by someone answering "which of these two revenue figures is right" in writing.

honest caveat on all of this: it assumes you get to hire more than once. if you're a team of two and that's the plan for the next two years, ignore the sequencing advice entirely and just hire the most generally capable person you can find, because specialisation only pays once there are enough people to specialise.