Is your data team an enabling team or a product team? Or Both?
I continue to go down a rabbit hole of treating your “data as a product” and managing your data teams accordingly. The type, scope, and mission of your team should be coupled to the type of team(s) you manage or create.
John Cutler did it again, and I am referencing his work. This week, he compares and contrasts Product Teams and Enabling teams and the friction that results from the WAY in which they work and the TYPE of things they are accountable for. In my experience, companies scope your data team to be BOTH a product team and an enabling team. However, I believe that by treating it as both, you are creating friction that will produce inefficiencies and inconsistencies in your organization. He says
Not that I am a huge fan of "move fast and break things", but there ARE situations when a product may rightfully choose to leave a lot of things unfinished and loose to reduce risk quickly. Because enabling teams never get to go back and fix things, this seems irresponsible and disrespectful (to them and customers).
For those of us who have work on and for many data and analytics teams, this may sum up the friction between product, IT teams and those data teams really digging deep an looking for the value they provide.
Hey Lucas, you idiot, it is clear that there are distinctions, but we have to be BOTH, we can’t possibly be one or the other. I have wrestled with these same thoughts time and again. And while true that we get pulled in many directions, as leader you need to have these hard conversations and structure your team/efforts in ways that get closer to those you serve, not farther away.
As an internal data team, you need to have a focus on your business partners (and ultimately customer’s needs), but the way in which you work will determine the traction you are able to gain or not gain by accepting your reality and improving it.
Product Analytics Teams should proceed with caution in event design
For anyone new to product analytics, don’t skip this section!
Anyone who I have talked to recently know that I recommend Timo DeChau for event based analytics tool/infrastructure training and content. Join his education site for free! In the last week or so, he posted a really thoughtful article about how many events you should have for our products to be efficient at analytics.
Let’s first define a web event. It is a thing that happens to an entity (user, invoice, etc.). It is easy to say that every click is a unique event. We then begin to bake context into each individual event (maybe a property of a button, a location of that button, etc.) Before we know it, we have 100s of events to choose from. This slows analysts and business people trying to analyze down.
His post talks about the nuances of what really matters to make these events coherent, flexible, easy to use etc. Check out his post from the last week on why you should have no more than 30 events to choose from.
Here was a video he produced early on talking about topic.
Data Scientists are Becoming Data Engineers
The data science role - yes the role that really isn’t defined and every company considers something different - has become the place where people look. It promises riches, fame, and an early retirement?
Over the last few years, the term “recovering data scientist” has come in vogue. Data Scientists, who sought the ‘promised land,’ only to end up writing data pipelines, managing infrastructure, and chasing fires on a daily basis really wanted to make a difference for their company. Articles are being written as we speak, about how to make this transition. That’s how big of a problem it is. But they spent very little time on actually writing your ML/Predictive Models that can change the way the company operates.
They realized that in order to do ML/AI/Predictive Modeling/…next thing we call it…well, they must fix the data first. In 2018 HBR wrote an article “If Your Data is Bad, Your Machine Learning Tools Are Useless” Except, here is the problem, all Data Science bootcamps, curriculum etc. are focused on Machine Learning Tools, and yet most companies are still trying to figure out how to observe their data in ways that help them know their data is “good” or making sure their data is “good.”
This means that Data Scientist can chase the “new” title, that has been there all along - the data engineer. They are now rebranding themselves to do the thing they have already been doing. It will be interesting to see if we see a boomerang back to data scientists FROM data engineers as more companies clean up their data.
Please know that all opinions expressed here are mine, and not representative of my family, friends, employer etc. I would love get feedback on what is useful and what is not. Shoot me a message on LinkedIn. Last year, I posted more consistently on LinkedIn and had many people reach out giving me a pat on the back for helping them see something differently or learn. These keep me going!