The Journey

Turning your data from a liability to an asset is a challenge.

A bit of advice for the journey:

You won’t get there fast.

Changing the culture around data, building new data systems, and seeing those results trickle into the business takes time. Measure the timeline in months and years.

You won’t get there alone.

Your skills alone can’t get you there. Hire the right team members. Collaborate with the right experts in the industry.

You won’t get there without enjoying the journey.

Celebrating small wins along the way makes the journey smoother. Look for evidence of how data is shaping the business. Take joy in reducing the data friction of the teams

I’m here with you on the journey,

Sawyer

Aging

The largest cost of data is moving it and querying/processing/transforming it.

As data volume increases, so does the cost.

Conversely, as data ages, it becomes less valuable.

Inventory data from last week is far more valuable than data from 10 years ago.

Most dataset hits a tipping point when the cost outweighs its value.

Most dashboard crosses over from being an asset to a liability.

Most data becomes dead weight.

Only the courageous are brave enough to archive and purge. Data is not a collection contest.

Data serves business goals, which means the bottom line comes first.

It was good to see you today,

Sawyer

Summer Camp

The other week I had a conversation with my good friend Jim who runs the IT operations for a summer camp. As you might guess, most of the year the camp’s website gets a fairly predictable amount of traffic. Nothing special is required.

Except for the day summer camp registration opens.

At 8:00 am a massive spike happens. Hundreds of summer camp spots are filled in less than 10 minutes. The most popular camp weeks are filled in 3 minutes with a waitlist of dozens quickly forming. By the end of the day half the camp weeks are full, and by the end of the week registration is pretty much at capacity (with long wait lists).

How does Jim manage this kind of spike in traffic? The design that covered 99% of the year will fail him at the most crucial moment for the organization.

This is one of the simplest arguments for moving to the cloud.

Because a few days before registration day, my friend Jim goes into Azure and scales up the web servers to 7 times their normal size.

In many situations a 99% solution is great. But without understanding the business properly, a 99% solution could be catastrophic.

I’m here,

Sawyer

What’s your problem?

If you want to be good at solving problems in your work (which is a good idea), pay attention to the types of problems out there.

Organizations create and experience at least four types of problems.

Urgent:

These are problems no one can deny and it's all hands on deck to fix them. The system goes down. Data breach. A publicized failure of your company to deliver your core competency.

Time-bomb:

Most people acknowledge this is coming in a few months or even 1-2 years. The system or process can’t scale and will break as volume or usage increases. A team is understaffed and overworked, facing inevitable burnout.

Annoying:

This is friction in a process or framework that the team regularly rubs against. Some people build up callouses and accept it as part of the job. Others (usually new people) are frustrated daily by the additional steps or error-prone processes.

Unknown:

Often only visible to an outsider, these are the dangerous problems that blindside teams or companies. These are also the hardest to solve because it requires convincing people that a problem exists right before their eyes.

Each of these types of problems requires different skill sets to solve, a unique approach to selling, and potentially different business models altogether.

Identifying what problem type of problem you solve can narrow your focus, refine your sales process, and enhance your company or team identity.

What kind of problem do you solve?

I’m here,

Sawyer

Date Night

For the first decade of my wife and I’s marriage going on a date was ….eh…inconsistent.

Neither of us was opposed to a regular date night. We enjoyed going out together, trying a new restaurant or brewery and just talking. Yet we have three young boys which made the task feel extra complicated.

Two or three (or four) months would go by without an evening out without the kids. My wife would look at me and say “We need a date night”.

So we’d start to think about who we could ask to babysit, when were they available, and how much it would cost.

It wasn’t in the monthly budget, we didn’t have a regular babysitter, and it wasn’t on our calendar so a date night just felt like a huge task to pull off. Consequentially, I’d tend to put it off until my wife said “We need a date night”.

Many companies approach data the same way.

Everything is rolling along with the status quo until an executive says “We need data analytics”. But it’s hard work because there’s no regular budget for this work and no infrastructure or thoughtful designs for building repeatable analytics solutions. The team makes huge efforts to produce a few reports (above and beyond their normal workloads), but then everything goes back to normal.

Until another company leader says “We need data analytics!”

What if instead, you approached data like my wife and I started doing with our date night? For the last 9 months date night is every other Monday night. The babysitter is booked far in advance, and the cost is known and in the budget. The difficult logistics of our date nights have nearly evaporated.

Now we just get to enjoy the results.

And my wife hasn’t once turned to me and said “We need a date night” since.

I’m on your team,

Sawyer

p.s. I help customers turn the dream of “we need data analytics” into a reality. My architecture design and roadmap service is often the first step. Reply to this email to get started.

Who’s the business?

I’ve mentioned “business teams” regularly in these emails.

A few obvious things I’m referring to:

• Marketing department

• Sales teams

• Accounting teams

• Warehouse managers

But it also means

…Admission team at a university

…Committee Members on a city council

…Operations Manager at a non-profit

…Base Leadership at a military base

…Coaching staff for a sports franchise

…Sr. Medical staff at a hospital

…Program Administrators at a government agency

…Mortgage Lenders at a credit union

etc.

These people are responsible for executing on the organization’s goals and they rely on data to do it.

See you on Monday,

Sawyer

p.s. Hit reply and tell me about the business team you work in or work with.

Yes…it’s about ChatGPT

I’ll be a bit bold today.

The emergence of Cloud Computing and SaaS solutions are key trends from the past couple of decades that closed the gap between data teams and business teams.

The next undeniable piece of the puzzle is happening now (and in the coming decade). Generative AI, Large Language Models (LLM), and ChatGPT are reshaping data and business skills.

(Side note: If you ignore the hype and the fear cycle there are tremendous real-life working use cases for how these tools are changing our work).

What does this have to do with our conversation this week?

Just like the previous trends of cloud and SaaS increased the speed and ease while decreasing the technical skill required to build data solutions - generative AI is doing the same thing.

Less and less time will be spent solving writing thorny SQL queries or optimizing streaming Spark jobs. AI will automate many parts of that work.

This opens up huge space for data teams to collaborate and integrate closer with business teams.

Close the gap in your career. Close the gap for the teams around.

I’m here,

Sawyer

p.s. So are data people out of a job? Yes, if you planned to differentiate yourself in the market by writing code for the next couple of decades. Rather than learning or optimizing around technical skills, optimize for technical and design thinking. Learn to think like a data professional (that’s what this email list is here for).

Let’s get Saasy

The three most common ways to eat dinner are

…Cook at home

…Order takeout

…Dine at a restaurant.

The level of skill, supplies, and physical space required varies with each option.

Cooking at home requires I have a kitchen, ingredients, and time. Grabbing takeout on the way home from work only requires a table and silverware from me. Dining in at a restaurant only demands I bring a wallet and appetite.

The dominance of cloud platforms in recent decades has introduced three main flavors of cloud services. Iaas (infrastructure as a service), Paas (platform as a service), or Saas (software as a service). Each requires different amounts of skill, expense, and maintenance.

Iaas is cooking at home

Paas is ordering takeout.

Saas is dining out.

As technology improves, the cost decreases and quality increase dramatically for these cloud services. As a result, Saas solutions dominate the market.

It’s a rare person who prefers eating at home if the cost and quality were better at a restaurant.

The dramatic shift from Iaas to Saas is another key trend closing the gap between Data teams and Business teams. With Saas solutions, data teams spend far less time grocery shopping and chopping vegetables.

Instead, they can focus on crafting a great menu and plating beautiful dishes for their business teams.

Doing that well requires knowing exactly what the business team is craving to eat for dinner.

It was great to see you today,

Sawyer

p.s I love helping teams build their data and business skills. I work with customers to build workshops to equip your team to excel in these areas. Check out The Data (Work)shop to learn more. Reply if you want to book a workshop for your team.

Closing the Gap

The gap is closing between data teams and business teams.

Why’s that gap closing?

Arguably the most meaningful technological trend of the 50 years is the rise of cloud computing systems. Amazon Web Services (AWS), Oracle, Azure (Microsoft), and Google Cloud Platform (GCP) have been the key drivers of cloud computing touching nearly every company and industry.

A main casualty? Server rooms.

Simply put, instead of a company running their applications, websites, and software solutions on their own computers (i.e. servers) you can remotely rent them from a cloud provider.

The server room is no longer in your office basement, it’s at Azure’s (or AWS or GCP) massive dataset center.

Instead of buying, installing, configuring, patching, and updating servers in an on-premises server room, you let the cloud manage all that.

The Cloud is like renting a car. You don’t change the oil, put air in the tires, or even wash it. You rent, you drive, you return. Everything is taken care of.

How does this close the gap between data teams and business teams?

The cost, complexity, and technical skill required to bring new software, databases, or analytical applications online drops dramatically. I don’t need IT to order, install and configure a new server when my team needs a new database solution. With a few clicks, I can configure and deploy new servers designed specifically for my use case.

IT and data teams are still required. But many tasks are abstracted away allowing closer collaboration and integration between groups.

Which creates new opportunities to thrive at the beautiful intersection of data and business.

I’m here,

Sawyer

p.s. Cloud computing changed the nature of hardware (renting instead of buying servers), but it’s also issued significant software trends. More on that tomorrow.

The Great Divide

I remember the first time I wandered into a server room.

I was 24 and just starting my first full-time job as an operations agent managing corporate travel. The office manager was helping me get set up with the equipment I needed at my desk, and so we entered the server room looking for a keyboard, mouse, and (if lucky) an extra monitor. In addition to being a room filled with large, black towers of humming servers, it was also the IT graveyard where former employees discarded their old equipment.

The server room was a foreign planet to me. I’d never done anything remotely technical in my life and the cords, buttons, and lights intimidated me. I found my keyboard, and mouse (no monitor) and got out of there fast.

For decades this has been the divide. IT teams and database administrators rule the dark arts of the basement server rooms. Managing their domain using opaque lingo and the ever-scary terminal window.

The business teams stayed in the daylight above ground, venturing to talk with IT only when necessary. As long as an analyst’s or accountant’s reporting tools worked correctly, there was never a need to bridge the divide.

But the gap between data teams and business has closed significantly in the last decades. There are key reasons why that's happened. And even more important implications for you and your career on either side of the business/data divide.

That's what we are going to spend this week exploring.

I’m on your team,

Sawyer

p.s. If you’ve enjoyed this or other emails so far, share it with your network on Linkedin.

Waterways

Moving stuff around is never easy.

It takes 12x as much energy to move things on land (with asphalt or concrete roads) instead of water. Before the 20th century, the best roads were gravel or dirt which required closer to 100x more energy than water.

So for thousands of years, humans built settlements and cities along key water features—Ocean ports, rivers, peninsulas, etc. When you needed to move food, building supplies, livestock, or armies the people who lived along waterways had significant advantages over those who were landlocked.

A data team moves around a lot of data for the business teams.

What can you do to build your data products and analytical solutions along efficient waterways?

The easier data flows around to key places in your company, the greater the advantage you have over competitors.

Have a great weekend, friends.

Sawyer

p.s. I guess we call the data “pipelines” for a reason.

p.p.s. We are two weeks into The Data Daily. How yall doing? Anything you want to see more of/less of?

Is Frank angry?

I joined the video meeting nervously. With sweaty palms turned my camera on.

Watched as the other attendees popped onto the screen. Smile. Look normal. It will be ok.

It was our first sprint demo with my customer. Most importantly, “Frank”, the Director of the department was there and he was the main reason for the sweaty palms.

Frank wasn't an IT or tech leader. He oversaw all areas of the operations, logistics, and technology of a key state government agency and he was a tough one to woo over. His dry humor and rough edges meant that after he spoke we often paused and exchanged glances within our team - “Was that a joke or is he angry?”

We jumped into our demo and presented the data modeling framework we had built. It was the result of a few weeks of onsite workshops with the business team followed by long brainstorming sessions between me and my teammate.

I got to the end of presenting the data model, demonstrating how it would unlock new analytical insights for their team, and then paused for questions.

Frank came off mute.

“Listen,” he said. “It’s clear to me you understand us. You talk like us. The way you describe our business, workflow, and what's important to us was surprisingly accurate for a team who’s only been working with us for a few weeks”.

I let out a big sigh.

Regardless of the technical challenges ahead, we had crossed the biggest hurdle. We understood the business language and process.

Ever since that meeting I’ve entered every new project with this same framework - Understand the business first.

The technology and data come much easier after that.

I’m here,

Sawyer

Valuable Metrics

Measuring impact is harder than amassing followers.

Measuring value delivered is harder than clocking billed hours.

Measuring customer satisfaction is harder than tracking sales closed.

Measuring happiness is harder than counting dollars in a bank account.

Measure what's valuable, not what’s easy.

Success metrics are broken because we choose to measure what's easy rather than what's valuable.

Two questions:

What are you measuring and what value does it offer?

What would it look like for you to measure a more valuable area of your work?

I’m on your team,

Sawyer

p.s. The Data Chat is one way I help my readers. If you want to talk through an idea from these emails more or need help with a data challenge at your company, then book some time for us to talk.

Who cares?

Data isn't really important.

Business results are important. Revenue. Profit. Customer Satisfaction. Growth. Data matters only so much that it supports some business goal.

Data people (like me!) get wrapped around the axle thinking about cool data tools, big data processes, and clean code patterns. None of that matters really. No business team has a goal about data.

Talk with your business teams.

• What are their goals for the next quarter?

• What are the key challenges they face in hitting those goals?

• How can data support or enhance their efforts toward the business goals?

• How can the data team build quickly to deploy value ASAP?

Data is only important as long as it supports a business objective.

Otherwise, who cares?

I’m on your team,

Sawyer

The balance sheet

Welcome to week 2.

I’m scared of big garages.

Not sure if there is a clinical diagnosis for this phobia. And maybe it’s not a phobia per se, but just a strong aversion.

Nearly every big garage I’ve seen in the wild (I’m talking 2, 3, or 4-car garages) has this irresistible pull toward filling up every spare inch of floor space, wall space, shelf space, and creatively-hung-shelving-from-the-ceiling space.

Use your imagination (or peek in your own garage if you dare). We (Americans) use our garages to store almost everything. Cleaning out the garage is an Everest-sized task that we put off every spring because we can’t bare to give up a month of Saturdays to finish the job.

So the garage sits. Collecting stuff.

Many companies approach data this way. Collect as much data as you can. Store it in every nook and cranny you can find.

Data is assumed to be an asset.

So of course collect as much as you can.

But there’s a problem.

By default, data is a liability, not an asset.

• Storage cost.

• Movement cost.

• Security cost.

• Management cost.

• Opportunity cost.

Terabytes of unused data ought to show up as red on the balance sheet.

I’m here,

Sawyer

A better experience

The North Star for data teams is to build better data experiences.

So, what is a data experience?

Let's think about it from different perspectives within an organization.

Ask the CEO…

if the executive reports are refreshed as often as they would like. Does she have to wait one hour or 30 days to see key trends and KPIs?

Ask your Data Analyst or Business Analyst…

how many different source systems do they export data from to build the reports leadership asks of them.

Ask the marketing team…

what information about their customer base would make their job easier. Sit in any leadership meeting long enough and you will hear "We don't know that information" or "We don't have that data".

Ask the CFO…

if their financial forecasts are based on hourly, daily, weekly, or monthly trends. Aggregated data is powerful, but only aggregated data is crippling.

Ask the Operations Manager…

if his team managing inventory has access to all the data they need to order and stock effectively.

Ask your Application Dev Manager…

if the databases used by the applications are a performance bottleneck or if they create a great user experience.

Data experiences are (at least) about:

• Delayed data

• Disparate data

• Absent data

• Aggregated data

• Accessible data

• Responsive data

Keep going down the list in your company. Talk with anyone in any org. They all have data experiences. Some great. Some terrible. Many are exceedingly average because few people care to ask.

I'm glad you're here,

Sawyer

Friction

Two things I will probably talk about a lot here.

1) The value of a Data Platform for nearly any company (the last couple days).

And 2) That the North Star for any data team should be to create better data experiences.

What’s a data experience?

It starts with removing friction.

Rough surfaces create friction and a negative experience in several ways. Imagine driving your car on rough gravel vs fresh interstate highway. The gravel road is slower, the bumps are jarring for the riders, and the rough ride puts excessive wear and tear on the vehicle.

“Highway miles” on an odometer are much different than “dirt road” miles.

Removing friction - even the smallest amount - improves speed, comfort, and longevity. Building a better data experience means a commitment to removing friction for business users.

A focus on removing friction requires collaboration between data and business teams. It also builds trust between them.

Collaboration and trust are two things you should be a big fan of.

Peace,

Sawyer

p.s. If you like these emails, please share them with a friend or co-worker.

Cart before horse

The analyst I described yesterday is a real-life scenario that I lived. It’s filled with invigorating highs (”They liked my analysis”), frustrating lows (” They want me to rebuild the analysis with changes”), and lots of murky waters in between (…trying to cobble together analysis from scratch each day).

There is another way.

Build a scalable, repeatable, maintainable, and automated data platform.

Scalable: The solution can serve all users who need it. All the relevant data is available (not just what fits in your pandas data frame).

Repeatable: The process exists as code and is persisted in a repository and can be repeated identically without fail. The computer repeats the process, not an analyst trying to remember the steps they wrote down.

Maintainable: When bugs happen there is a central place where the error can be fixed. The data, logic, and rules live in a central environment (central for your team, or maybe the whole company). It doesn't live on someone's laptop, private SharePoint, or in an email somewhere.

Automated: It's scheduled to run without manual intervention. No one needs to sign on at 9 pm on Friday night to deliver a report the CEO wants.

These are the building blocks for your data platform. Any successful analytics program takes each of them seriously.

Those with a software engineering background will laugh at the simplicity of the above list because software engineering is a far more mature discipline than the scrappy world of data, data analytics, and data engineering.

Analytics without a data platform is running on a hamster wheel.

Analytics without a data platform is putting the cart before the horse.

It was good to see you today,

Sawyer

Two Ways

Good morning!

It's Day 2.

Let's ride.

Every company I talk with wants analytics and insights. They want meaningful dashboards, compelling metrics, and accessible data to answer their questions.

There are two ways to do this:

First, assign your business or data analysts the job of building these reports for your team. They'll export data from various systems. Then in Excel (or Python if you're lucky) they will clean the data, remove duplicates and resolve inevitable inconsistencies. The business logic is next and applied in calculations, filters, or formulas - perhaps in a shared workspace, but most often on the analyst’s own laptop. Likely exhausted from the process, the analyst tosses a few visualizations onto a business intelligence tool.

After several hours (or days) of work, the analyst presents their findings. It's great! Everyone loves it. Maybe too much. They ask for weekly updates on this report, with a few additions, and business logic changes to a particular metric.

Excited, and a bit overwhelmed, the analyst returns to their desk and shares with a colleague about what happened. After a few minutes of back and forth, it comes out that the other analyst has built similar reporting 6 months early, but using (yet more) business logic, mapped to similar different data sources.

Whose report is right? Which business rules are correct? Which data is supposed to be leveraged to answer these questions?

No one knows. But as long as a weekly presentation happens that shares (maybe correct?) insights with pretty visuals the cycle will continue.

Exhausted, the analyst returns to their desk, tries to remember how they built their report, and blocks out 6 hours on their calendar for the next week to try and reproduce it again.

Is there a better way? Of course. Let's talk about that tomorrow.

Sawyer

from  The Data Shop 

Day 1

Welcome to The Data Daily

Thank you for allowing me into your inbox. It's a privilege to invade these pixels on your screen and share a thought with you each day.

What is this newsletter all about?

Helping data people with business and business people with data.

I have this crazy idea that data people are better when they understand business. And business people are better when they understand data.

I also had this crazy idea to write about it every day.

Data and business are a beautiful intersection. An awesome playground of ideas to explore.

Together, hopefully we can

Build better data teams

Build better business teams

and knit them closer together.

What's next? Starting tomorrow:

A Short email

Every Mon-Fri with a story, technical concept explained, advice on a common problem, or perspective on how the world works. All focused on the intersection of business and data.

100% Real

It's just me trying this email and sending into your inbox. Typos are free of charge. Nuance will occasionally be lacking. And half-baked ideas are part of the process (maybe they will get fully baked in subsequent days).

Conversation

This email is 1-on-1 communication with you. Your replies go straight to me. I'd love to hear from you, meet you and explore your ideas and questions. I promise to reply. Especially for you mom (hi mom!)

Change

The Data Daily is brand new. It's going to evolve a lot in the coming weeks and months - hopefully always for the better. But expect little bits of change along the way as I figure out what the heck I'm doing.

Leave anytime

If daily emails ever become too much or the content isn't what you are looking for, you are welcome to leave at anytime. The unsubscribe button will always be at the bottom of the email.

​See y'all tomorrow,

Sawyer