The surest sign that a company has no idea how to work with Data Science is requesting Insights™ as its primary output. You can tell just from the word--it's vague and sort of mystical, which is not exactly how you want to describe your quantitative teams
Yes, data analysis is about convincing someone (perhaps yourself) that something is or isn't true, but it takes a special kind of talent to do it consistently. It's easier to remember your analyses that changed someone's mind because it's easier to remember unusual events
That's definitely been the case for me, at least. I've done a lot of analysis over the course of my career, and I can only think of a handful that meaningfully changed the conversation around a subject
I've been mulling over what I think the alternative to Insights™ should be and while I have yet to come up with a satisfying conclusion, I do think one of the biggest flaws of the DS-As-Insights-Generators model is that it's a narrow strategy
If your job is to ensure data is a part of the decision making process at your company, you probably won't achieve it with artisanal Insights handcrafted by a data scientist. Maybe if you work for a magical company where the DS-stakeholder ratio is 1-to-1, and if you do--hey hmu
One of our unique strengths as DSes is getting data into a shape where the signal is differentiable from the noise, so maybe we should direct our energy towards creating environments where data is widely accessible and hard to use wrong
That's the promise of self-serve analytics, I suppose. But IMO such initiatives focus too much on making it possible for everyone to be a data scientist, when in actuality they should make data scientists unnecessary in as many situations as possible
And don't get me wrong, data scientists still have tremendous influence in a world like that. You make what you measure, so designing the datasets, metrics, procedures, dashboards, etc. that other teams use gives a DS tremendous influence over where the company puts its focus
Stepping up as owner of these things, really taking responsibility for their quality, reliability and improvement over time--it gives you way more leverage than a dropping few Insights every quarter, even if the Insights are Actionable®

• • •

Missing some Tweet in this thread? You can try to force a refresh
 

Keep Current with Katie Bauer

Katie Bauer Profile picture

Stay in touch and get notified when new unrolls are available from this author!

Read all threads

This Thread may be Removed Anytime!

PDF

Twitter may remove this content at anytime! Save it as PDF for later use!

Try unrolling a thread yourself!

how to unroll video
  1. Follow @ThreadReaderApp to mention us!

  2. From a Twitter thread mention us with a keyword "unroll"
@threadreaderapp unroll

Practice here first or read more on our help page!

More from @imightbemary

28 Jul 20
I remember the first time I made an important decision at work. It was defining a metric a sales team would be using, and I didn't even realize I'd done it until it had already happened.
It was bizarre. I'd always thought people should be listening to what I thought and taking my advice, but this felt very abrupt. They were just going to take my word for it? Wasn't someone going to check my work? What if I was wrong?
This was the first time that I felt like there might be real consequences to me being wrong, and it intimidated me. The fact that people WOULD just take my word for it meant I had responsibility to not say things lightly.
Read 5 tweets
5 Jul 20
What is the difference between an engineering manager and a data science manager? It's a question I find myself ruminating over almost constantly. There's tons of good thinking and writing about eng management out there, but I don't find that it always translates to the DS world.
Granted, "Data Science" is still a broad cover term, so depending on your flavor of data science, the leap is shorter. One way of segmenting the DS world that relate to is the type A vs. type B DS, where A is for "analysis" and B is for "building"). medium.com/@rchang/my-two…
My suspicion is that most eng management advice can apply to Type B DS management pretty readily. Their work is more purely engineering. But what does that mean for Type A DS management? What makes it different and thus hard to apply the same advice to? I have some thoughts.
Read 15 tweets

Did Thread Reader help you today?

Support us! We are indie developers!


This site is made by just two indie developers on a laptop doing marketing, support and development! Read more about the story.

Become a Premium Member ($3/month or $30/year) and get exclusive features!

Become Premium

Too expensive? Make a small donation by buying us coffee ($5) or help with server cost ($10)

Donate via Paypal Become our Patreon

Thank you for your support!

Follow Us on Twitter!