The big problem with decision making
A few years ago, I thought that values and principles were invented by life coaches to make a quick buck on people who didn't know what to do with their lives.
Luckily, I am wiser now than I was a few years ago.
Today, I know that having strong principles makes you a better leader and decision-maker.
I will be honest with you: I used to be a pretty bad decision-maker, in life and in business.
My main problems were:
- I lacked confidence. What will be the consequences of my decisions? How will other people think of me if I get it wrong? What will happen if I'm making the wrong choice?
- My decision-making was inefficient. Driven by my lack of confidence and my tendency to be overly analytical, it took me forever to make important decisions.
- I went back and forth on decisions. I used to switch from "yes" back to "no" multiple times and nothing seemed to feel right.
My problem with decision-making affected my career and my personal life.
The turning point
Then, in 2017, I was at a point where I needed to make a lot of high-impact decisions. It was during that period that I realized I needed some kind of compass to guide my decision-making.
My starting point in finding this compass was the book "Principles" by Ray Dalio.
For those of you who don't know who Ray Dalio is: He is a billionaire investor, and founder of Bridgewater Associates, one of the world's largest and most successful hedge funds.
Ray Dalio attributes a large share of his success to the principles he crafted over the years.
In his book, he describes how every decision you make can be grouped in such a way that every new decision is "just another one of those".
Principles tell you how to decide when "another one of those" comes up. Today, I want to share with you a few of my principles and how I use them to automate and systemize decision-making as a data leader.
This will be just a small selection (I mean, Ray Dalio wrote a book with 600 pages about it, so please don't expect a full list in this small episode).
Principle 1: Run your data team like an entrepreneur and not like a technician
A technician is someone good at their craft.
- A data engineer who is good at building infrastructure
- An analytics engineer who is good at building data models
- An analyst who is good at performing ad-hoc analyses
- A baker who is good at baking pies
- A mechanic who is good at repairing cars
The technician leader starts with a picture of the solution that he/she wants to create
- evaluates vendors
- creates concepts
- integrates data sources
- designs data models
- builds dashboards
The entrepreneur leader starts with the user for whom the solution is created
The entrepreneur leader knows that the product of the data team is not WHAT it delivers but HOW it delivers.
I used to start data initiatives by thinking about data infrastructure first.
Today, I start every data initiative by meeting the users and deeply understanding who they are and how they work.
Principle 2: Never build a data team in a pre-product market fit startup
I won't go too deep into discussing what exactly product-market-fit is. That could be a book in it's own right.
Let's define it as the stage in a company's lifecycle where the company's product satisfies strong market demand, demonstrated by high customer adoption, retention, and enthusiasm.
Every time I saw a company build a data team or data infrastructure before product-market-fit this led to a waste of money, waste of resources, and people getting fired.
The reason is simple: as long as a company doesn't have product-market-fit, it will iterate and pivot too quickly.
No data team or data infrastructure can keep up with that pace.
Principle 3: Use data modeling best practices - but don’t follow them dogmatically
I am a HUGE fan of data modeling and I have seen many data teams struggle because they ignored data modeling best practices completely.
On the other hand, sticking to data modeling best practices dogmatically and strictly applying every rule in the book also won't cut it in fast-growing companies.
Principle 4: Always validate if you can use a simple heuristic before building a machine learning model
When I was Head of Analytics at Rocket Internet, the largest venture builder in the world back in 2012, we wasted hundreds of hours to build a recommendation engine based on machine learning.
The challenge was that it is relatively easy for a machine to recommend alternative products (e.g. a Samsung Galaxy to someone who didn't buy an iPhone) but it is relatively hard for a machine to recommend complementary products (e.g. a matching phone case for your Samsung Galaxy).
In the end we realized that 50% of all revenue was generated by only ca. 1,000 products.
So we let an intern pick complementary products for these 1,000 topsellers manually.
Problem solved.
This hack generated a whopping 12% increase in Revenue per Visitor.
Principle 5: The best first data hire in a company is an analytics engineer with a keen interest in the company’s business model
This principle has two components:
- Analytics Engineer
- Keen interest in the company's business model
I often help scale-ups recruit their first data person.
These two criteria are my most important decision making guidelines.
Typically, I see companies hiring either people who are too technical (Data Engineers) or too little technical (Business Analysts).
Both approaches rarely work.
So, when I see candidates who are not analytics engineers or who can't demonstrate sufficient interest in the company's business model, it's an easy decision to reject them.
It's better for the hiring company AND for them!
Principle 6: Never build business logic in a dashboarding tool
I use a standardized approach that defines exactly what happens in each step of a data pipeline and where which type of business logic is implemented.
You can find this approach in the article I already linked in Principle 3.
The huge problem with building business logic in a dashboarding tool is that the logic cannot be maintained in a central place and will always start to fork.
This leads to the dreaded situation where a CEO looks at three dashboards and sees three different revenue numbers.
Business logic must be created as far upstream in a data pipeline as possible so that it is not repeated and doesn't fork.
Principle 7: A data project that doesn’t enable business decision makers to self-serve is doomed to fail
I have seen dozens of fully centralized data teams and none of them created any significant business impact.
They might be out there, but they are rare.
When an executive calls me up to run a due diligence or an audit on the data team to figure out why the team is not adding value, those teams are almost always too centralized.
Even if a data team has analysts who are specialists for certain business domains, they often lack the deep domain knowledge of business decision makers in the business domain.
Worse yet: They ALWAYS lack the skin in the game that business decision makers (marketing managers, product managers etc) have.
Therefore, I will always look for a way to enable at least one business decision maker to self-serve in every data project.
My favorite way is to let business decision makers access a well-modeled datamart in BigQuery with a direct Google Sheets connection to BigQuery.
Bottom Line
Ray Dalio refined his principles over decades.
I'm still at the beginning of my journey to document and fine-tune mine.
But it has already been a tremendous help in making my decisions:
- more confident,
- more accurate, and
- more efficient.
Now it's time to craft and document your own principles!
Start today!
