I’ve made several lucrative pivots in my career: business analyst, product owner, data analyst, data engineer, and most recently data product manager.
Each one afforded me more opportunities, more autonomy and more money.
Here’s what I’ve learned:
⬇️ (View Tweet)
Max Levchin knows a thing or two about data. He built one of the best anti-fraud systems in the world at PayPal in 2001, way before the advent of big data and machine learning.
But he had to do it while the company was bleeding millions each month to fraudulent activity.👇 (View Tweet)
I’ve been helping a friend with setting up a data warehouse for his Shopify store. Even the simplest business today uses multiple SaaS tools.
This one has paid Google and FB ads, GA for website tracking, Shopify ofc, an email newsletter and a supplier tool. (View Tweet)
I wish more companies shared their data practices. That way practitioners can learn from actual implementations vs just from books. Kimball’s book is good but it’s also almost a decade old.
I only know about these two examples: (View Tweet)
In order to understand data reshaping with SQL (or any other tool) you only need to learn two fundamental concepts:
Pivoting
Granularity manipulation
It’s simple but not easy. (View Tweet)
I’m slowly arriving at basically the same realization many have arrived before me.
For data warehouse modeling:
Raw Data => ER/Relational model (3NF, Kimball, DV 2.0, Anchor, Activity Schema) => OBT view or materialized into a table)
Why? (View Tweet)
In 1994 Peter Drucker wrote that every business must have a theory.
A theory of the business has three parts:
First, there are assumptions about the environment of the organization: society and its structure, the market, the customer, and technology.
Second, there are assumptions about the specific mission of the organization.
Third, there are assumptions about the core competencies needed to accomplish the organization’s mission.
Surprisingly these are still valid today, almost 3 decades later! (View Tweet)
I’ve gotten this question twice now from data leaders:
How do I change things when my data team is treading water answering questions and building dashboards, they can’t just give me carte blanche to build metric trees can they?
Let me tell you a story:
Years ago I was involved in a project to replace a homegrown CRM with Salesforce.
The project was risky because it meant swapping out an aging tried and true CRM with something brand new. It had to have all the same features and be easy to use.
The project went through roughly 5 phases that I believe are exactly the same when doing
Phase 1: Get buy-in from executive team
Phase 2: Freeze / slow down development on old CRM
Phase 3: Peel off a “tiger team” to build the new CRM
Phase 4: Develop the new CRM
Phase 5: Slowly transition teams onto it
Getting buy-in is the hardest but also the most important phase.
Use your persuasive powers and get the CEO/President on board if you can, or someone close to them.
Without buy-in you won’t be able to complete Phase 2 decreasing (or stopping) the inflow of requests to your data team.
If that’s not possible you can always ask for more budget to hire an external team. Negotiate wisely.
Next you start building. You must show progress and success early and often to keep the flood of requests at bay.
Finally start transitioning teams onto the new tools slowly. With enough luck, jealousy (over better tools) will create enough interest for you to keep going. (View Tweet)
