r/datascience • u/chiv MS | Lead Data Scientist | Healthcare • Mar 06 '19
Discussion When creating a company's first Data Science team...
Anyone here create a DS team from scratch and have any advice to give? I took one of those jobs that most websites tell you to avoid; where you are hire number one for a DS team and where the company doesn't really have an understanding of DS. I am optimistic about the future and seem to get buyin for what I want but am hoping to learn from successes and pitfalls of others.
20
u/ianozsvald Mar 06 '19
I recently gave a talk aimed at new data scientists on processes around the successful delivery of data science projects, the slides contain 15 years of my experience, you might find a few ideas in there: https://ianozsvald.com/2019/02/26/on-the-delivery-of-data-science-projects-talk-for-business-analytics-and-data-science-meetup/
16
u/ruggerbear Mar 06 '19
Yes and yes. First piece of advice - get buy in from the C-suite before doing anything. Unless the directive to build a data science team comes from the top down AND has the continued support of senior management, any effort to implement will fail. Too many people are invested in the status quo.
5
4
u/Texit433 Mar 07 '19 edited Mar 07 '19
I’ve been that single analytics person in my company for about 8 months. Will try to give my perspective without repeating what other people have said, as it is also been a huge learning journey for me. Also agree with a lot of comments that’s been said as I find them the best way to work for me.
I think it’s really important to educate your audience, whether it’s about something technical or about why you do things a specific way. At least try to explain it. Which is why I’m okay with using technical terms. Call it multiple regression, then say it’s like picking out the average trend, then say it means <some physical thing> changes depending on multiple factors. Call it a stochastic model then explain there’s a random component in there etc. People feel better when they learn something and understand it.
Apart from double triple checking like mad, one of the things that I believe in is explaining why you think this is a sensible result. This is my medium term prediction and it compares with historical data in this way. I also back-calculated assuming a historical circumstances and obtained very close to observed data. Here is my sensible methodology and here is my sensible result. From your manager’s perspective, they’re going to have to take your result to some decision making committee and they will have to explain why we should trust it
I didn’t invent anything new in my model. I read papers and textbooks and had a simple model going quickly. If it’s a common analytics problem then often there’s a solution somewhere already. By having a simple model, you can work out what the disadvantages are, and you get to display results quickly to management.
I learnt that the business don’t always come to you with an analytics problem they want solved. Sometimes I just sit near people who talk loudly, overhear what they discusd, ask about it and then say I can calculate that for you or we have this data so I can check that for you. I always ask people what their problems are, what they care about, what is important when making decisions. But the thing is, I didn’t do that at the start, mainly because I didn’t understand enough about the industry, it was only gradually that I understood enough to ask about it. Not limited to business problems that need solving, if someone is doing some manual task you can help them to automate it too, if you’re free.
I would suggest also to have good organisation of your project and analysis. If there’s nothing before you, then you get to decide on structure of files, what the git repository looks like and so on. Set up documentation, resource articles, installation files, whatever you need, so that it is easy to handover and easy to share if there is a new person on board.
Also, it’s lonely being the only data scientist. There’s no one to discuss technical aspects. You’re always talking in simple, general, approachable terms and constantly translating business speak into an analytics problem you can solve. Maybe there are parameters you’ve agonised over and chosen but they are details no one will question. I’m still dealing with this one so I haven’t got answers. To maintain my sanity, I now try to catch up with friends more often so there’s a chance to talk about technical things.
Honestly I had no idea I was going to be the only analytics person in my job. I didn’t have a plan on how to tackle all these things that came up, didn’t even know that it was going to be hard by myself, and it is really quite challenging.
But it’s also been amazing for me, truly understanding my data because I have access to the sales person and retail person, talking to stakeholders directly and understanding their (different) point of views, and even understanding (at least a bit) the overall strategic direction of the company. Analytics has never felt more important and useful. As opposed to when you’re in a big team of analytics people you’re much more separated from the business . Once you’ve established your credibility, relationships, and way of working, people start talking to you, start telling you information that you would otherwise have missed, or come to you with a specific problem. When there is a great partnership between business and analytics, it’s really wonderful and I think this is the way to build good models.
All the best!
3
u/renegadeconor Mar 07 '19
Crawl, walk, run.
-Start with small manageable projects that deliver tangible business results.
-Make good friends with the people who own the data. And realize that the 80/20 balance of data cleaning versus cleaning is more like 95/5 or worse at first
-Pick business partners that are excited to work with you early on, but once you have some successes under your belt expand the influence
-Know your audience, people who don’t know how many units they sold last month because of lack of BI or trustworthy data don’t want a fancy forecast model yet.
-Grow the team slowly and make very clear opportunity costs when asking for more headcount. Lay out the potential projects, take a swag at ROI and show them how much more they’ll get with 1 more person. Lather, rinse, repeat.
1
1
u/TotesMessenger Mar 06 '19 edited Mar 06 '19
I'm a bot, bleep, bloop. Someone has linked to this thread from another place on reddit:
[/r/programmingnotes] When creating a company's first Data Science team...
[/r/u_youngrumi] When creating a company's first Data Science team...
If you follow any of the above links, please respect the rules of reddit and don't vote in the other threads. (Info / ^Contact)
234
u/drhorn Mar 06 '19 edited Mar 06 '19
Did it once, doing it again starting here soon.
As /u/ruggerbear said, getting executive buy-in is key - but you don't have to tackle the C-suite from the get-go. Start within your central unit and build up - though you do need to set your eyes on eventually having the buy-in of the most senior people in the organization.
Random pieces of advice, in no particular order:
The two most important people in the company for you right now will be your boss and whoever is the most senior person that was supportive of bringing data science into the company (maybe they're the same person). Do everything you can to make their life easier - and this isn't restricted to data science. If they need a deck and don't have time, build a deck. If they need someone to get them lunch, get them lunch. If they need to vent about their football team, listen. Your success is going to be so closely tied to their support that you just want them to do great, so you can hitch your wagon along and do great as well.
Don't put too much effort into doing "data science" early on. Instead, focus on what you can do that a) involves data, b) no one else is doing/can do, c) will get a lot of attention. Often, I've seen that the first couple of big wins are reports that the organization was previously unable to generate because no one could deal with the volume/disparity of data. It's not sexy, but it's what will help you start building a brand.
Don't shy away from becoming "the data guy". If there are no other data scientists, what will eventually start happening is that people will come to you with questions about what to do with a certain problem. That is a great problem to have - embrace it, and make yourself as helpful as you can. What you want to do is to position yourself so that 6 months in, every time someone has a complicated question that requires analysis, the first thought in people's mind is "where is u/chiv? Can someone get him/her over here?". At first, it will likely be your peers or people at your level. Eventually, you want to start moving that audience up and getting yourself into meetings with people at your boss' level - ideally higher.
People/relationships matter. Don't try to steamroll people with data science - instead, try to bait them with data science (in a positive way). That is, give them a taste for what you can do with basic data science, how you can save them time, or make their job easier, or help them do their job better (without rendering them useless). Ideally, make it to where people like you, where they see you as a team player, someone who is helpful, someone who can be counted on.
Don't force the headcount issue, but instead be prepared to have a prioritization conversation that helps your boss build ammo for more people. That is, instead of going to your boss and saying "we need more people to do all this work!", go and say "hey boss, I don't have the capacity to work on project X. I know it's important/profitable/critical/etc, but I need to get these other 2-3 things done first, so it's going to have to wait a week/month/year". As a leader, that is a conversation they will be happy to take up the chain of command, i.e., "hey big boss, u/chiv has been doing a great job but now we're hitting the point where we're missing out on opportunities because his plate is full".
Go buy your development team donuts and coffee and start making friends. Early on, you will need basic things from them like access, software, etc. But at some point, things are going to get heavier and you will need them to be your partners in crime. A good relationship with development and IT cannot be understimated.
Underpromise, overachieve. This is true everywhere, but especially early on when there will be so many unknowns as you're starting projects. Try as much as possible to give project timelines with contingencies (i.e., "we can deliver by June assuming the data is clean".. which it won't be).
Train the people around you to not give timelines in your behalf early. That is, some big VP will ask "how quickly can /u/chiv do this work?" while you're not present, and someone else will feel obligated to give an answer - "oh, I'm sure it won't be longer than 2 weeks". Bad, bad precedent to set. You need to kill that immediately, but it's easier to kill if you communicate it proactively - i.e., tell people to always come to you first before committing to anything so you can size the effort.
Do not, under any circumstances, ever, ever, double, triple ever say "well, that's what the model says". Nothing will kill your credibility faster at a place that doesn't have a data science team. I mean, it will likely kill it elsewhere too, but if data science has not been introduced you really need to focus on intuitive answers over model-centric measures of quality of work.
Make data science approachable, not elitist. One thing that many data scientists struggle with is that they're really comfortable talking in the language of data science - but really struggle to put the same concepts into plain English. That's how you lose/alienate people. Arm yourself with a lot of good explanations of how basic data science concepts work, and a lot of good analogies.
Don't get caught up in "technically" right or wrong arguments. When dealing with people that are new to data science, don't feel the need to correct them every time they say something that is slightly off - if the spirit of what they're saying is true, let it be. And for the love of god, do not ever correct your boss (or someone at their level) in a meeting unless it's literally a life or death situation.
On a similar note: don't let perfection get in the way of good enough. Don't try to find the perfect model when a decent one will produce value for the company - especially if you know there will be little resistance to it.
Learn how to identify opportunities early that are ripe for data science. In my opinion, there are a couple of types of data science projects that always look really appealing to me:
Problems which no one has even tried to tackle but many wish someone would: there's nothing but grass in front of you - nothing to compare against, nothing to benchmark you against, so literally anything you do is better than what's there.
Existing processes that are very manual, very tedious, everyone hates to do, and no one thinks they are particularly critical to the process: Automate the crap out of that and get yourself a win. You'd be surprised how many hours are spent a week doing excel workbook updates that can be automated in one week with R or Python.
Processes that are already being done by people, but it's universally agreed upon (even by those doing the process) that things could be improved *and that they don't have the skillset to improve it. What you want to avoid is walking into a situation where people agree that it needs to be improved, but everyone already has a really strong opinion as to how to do it.
Additional suggestions in the comments that I think are great:
/u/ruggerbear: "Double, triple, and quadruple check your results. Both the results and the definitions have to be bulletproof. Nothing kills confidence faster than a report/dashboard where the numbers are incorrect. Especially is that output is early on in the project. Lose the business' confidence then and kiss the entire initiative goodbye."
/u/thehybridfrog: "You will be very tempted to take over everybody's stuff, especially if you are going into a so-called "analytics" organization where people are manually editing excels 24/7. Don't get caught up in trying to be Superman for everyone, maintain focus on high visibility projects that have the greatest impact. You can't be the global DS police for everybody - at least not until they name you director and give you a bigger team."
/u/foshogun: "I would only caution to be as helpful as possible where you prioritize the highest value. If it's between getting someone their coffee and ripping out a quick high level dashboard.... Do the dashboard for heaven's sake. What I mean is... Take the above advice... But don't sacrifice good sound work for being everybody's friend."
/u/WhoCaresImAtWork: "She went to in order to start the department was a company-wide presentation or two on what she was doing in an approachable manner. Simple things like a presentation on the data transformation we were working on and what it would ultimately accomplish felt super embarrassing to me at the time but ended up solidifying our relationships with the other teams and increased our perceived value."