Mike's Manifesto

We're drowning in noise. I’ve run data teams long enough to know how easily the signal gets lost.
‍
Panelists who've never shipped code pontificate about "the modern data stack." Gartner analysts who've never been paged at 3 a.m. sell quadrants to executives. LinkedIn influencers with "10 hot takes" rack up engagement while having never migrated a petabyte of production data. elon musk, confidently wrong about relational databases on a platform he owns.
‍
Meanwhile, the people who actually build the systems — the data engineers, architects, and analysts wiring civilization together — sit in the shadows. Their pipelines power everything. Their stories stay buried.

We understand the cost. We're practitioners who've earned scars from brittle systems and failed migrations. We're learners trying to master dbt, Snowflake, Databricks, Airflow in an ecosystem that churns every 18 months. We're philosophical tinkerers fascinated by how data shapes power, frustrated by hype cycles that ignore engineering reality.

And we're silent.

Not from laziness. From rational self-protection.

NDAs make it dangerous to talk about what we actually built. Tool churn means what we mastered three years ago is already deprecated — why expose ourselves? Impostor syndrome whispers that someone smarter will eviscerate us in the comments. Organizational invisibility means we fix broken pipelines at 2 a.m. while data scientists get promoted for the dashboard we made possible.

So we stay quiet. We share war stories in private Slack channels. We post memes about Airflow DAG failures because humor is the only safe way to say "I see you."

The silence is self-protection. But it has a cost.

If engineers don't own the story, we lose more than recognition. We lose:

‍Institutional memory. The lessons from your failed Kafka migration die in your team's Slack archive while someone else makes the same mistake next quarter.

‍Craft transmission. Junior engineers learn from people who've never done the work, inheriting confidence without competence.

‍Reality checks on hype. When builders don't speak, every new tool sounds revolutionary because there's no one with credibility saying "we tried this in 2018 and here's why it didn't stick."

‍Leverage in organizations. When executives only hear from vendors and consultants, they don't know what's actually hard. Your midnight heroics stay invisible and unrewarded.

Here's what I think: if we've built something real, we have a duty to document it.

Not the polished version. Not the version that makes us look smart. The real version — with the false starts, the mistakes, the trade-offs, the context that actually mattered.

We have a duty because the next person is going to face the same problem we faced. And they deserve better than learning from someone who's never done it.

We have a duty because the executives making decisions need to hear from someone who has to live with the consequences. Someone who gets paged. Someone who can say "here's what that actually costs."

We have a duty because the field we work in is too important to be defined by people who don't understand it.

Data infrastructure shapes everything now. It shapes what questions organizations can ask. What decisions they can make. What they can know about themselves. We're not back-office support. We're not IT maintenance. We're building epistemology. We're building the capacity to know.

That work deserves a record that isn't written by marketers.

Data Talks on the Rocks is my attempt to create that record.

Not "content." Documentation. An oral history of the modern data stack — told by the people who actually built it.

Each episode: someone who's shipped production systems talks about what they built, what broke, and what they learned. The migrations that took three attempts. The architectural decisions that seemed brilliant until they weren't. The 2 a.m. pages that taught them something no documentation ever mentioned.

‍The format:
‍Not this: "Let me give you my five-step framework for data excellence."
But this: "Here's the specific moment I realized our slowly changing dimensions were the problem, and here's the ugly path I took to fix it."

Not this: "Follow your passion and the career will follow."
But this: "I learned dbt right before it blew up. Here's how I knew it mattered, and here's what I'd learn next if I had to start over today.

"Not this: "Our cutting-edge ML platform revolutionized the business."
But this: "We spent six months building a feature store nobody used because we never asked the data scientists what they needed."

I'm Mike Driscoll. [Mike's story here - your background, credibility, why you have access, what scars you carry, what gives you the trust to hold these conversations]

I started this because [personal trigger moment - what made you angry enough to start recording].

I have a privileged position: [explain what access/platform/credibility you have that lets you do this].

And I think it's worth using that position to build something permanent. Not for my brand. For the archive. So when someone 10 years from now asks "how did they actually build this stuff?" there's a record that doesn't come from a vendor's marketing team.

If you've built something real — something that shipped, broke, taught you, or changed how you think — I want to record your story. Not the polished case study version. The real one, with all the false starts and midnight debugging sessions and moments where you weren't sure it would work.

You won't have to violate your NDA. You won't have to pretend you have it all figured out. You just have to be willing to talk honestly about the work.

In exchange, your story becomes part of the permanent record. The next generation of builders will learn from what you actually did.

The silence of good engineers has let others write our history for too long.

Let's fix that.

SIGNATURE OF MICHAEL DRISCOLL