If You’re New to Data, Read This Before You Build Anything
Plus 7 Articles I Think Everyone in Data Should Read
Hi, fellow future and current Data Leaders; Ben here 👋
Today, we’re going to discuss how you can improve communication with the business to gain buy-in for a project or deliver better results and insights.
Before doing that, I wanted to let you know that in July, I’ll be hosting several webinars and discussions with data leaders about problems that extend beyond just technology (although we’ll likely touch on some infrastructure topics). So, if you’re interested in growing as a data leader, you can sign up here.
Now, let’s jump into the article!
When you’re just getting started in data, everything feels exciting, and everything sounds like a good idea.
"Oh, this process takes ten minutes? I’ll automate it with VBA!"
Fast-forward four weeks, and you’re trying to meet the finance team's expectations, reconciling numbers, and banging your head against a table, wondering why you ever volunteered.
New paradigms show up with shiny names and polished diagrams. They sound smart. You’ve got nothing to compare them to, so you try them. After all, everyone else seems to be.
That’s what this article is about: the things I wish I understood earlier in my data career. It started because there were so many buzzwords and new products popping up in the past few weeks, it might not be clear what’s actually going on if you’re new to the data space.
Whether you’re early in your data career or just want a sanity check, here’s a breakdown of the stuff that actually matters (and the fluff that doesn’t).
Let’s dive in.
1) Avoid Being The Only Engineer On A Team Early On In Your Career
My very first role out of college was working for a finance team as their tech person. That work ranged from creating Tableau reports and building ETLs in SSIS to taking over a C# MVC site, one no one mentioned until about two months in.
I learned a lot in that role, but not much about how to actually develop. Sure, I built dashboards and picked up the quirks of SSIS. But being the only developer early in your career isn’t just isolating, it limits your growth.
You miss out on design reviews. You don’t get to hear other people’s experiences or perspectives. You’re stuck with what you already know.
If you can, look for roles where you’ll work alongside other engineers, especially ones with more experience. They’ll share why they made certain decisions, review your code, and offer feedback that helps you level up.
That will grow you far more than a job that hands you shiny tech or gives you free reign with no guidance.
Seek out a strong engineering culture.
2) Hype Won’t Fix Your Business Problems
There’s always been a lot of fluff in tech, but over the past few years, it’s gotten louder. Vendors have started leaning hard into new design patterns, terms, and products, all packaged as “solutions.”
How many combinations of “Lake,” “House,” “Ware,” “Compute,” and a dozen other buzzwords can we toss into a blender and call it innovation?
Honestly, many of these terms have started to lose meaning. The problem is, if you’re just getting started, it’s easy to get hooked. You’ve got no baseline for what came before, and early in your career, you’re probably focused more on solving technical problems than business ones. So, the jargon sounds legit.
It sounds like it solves something. And vendors work hard to make sure it does. They script their pitches to speak directly to engineers’ pain points, while conveniently ignoring others.
They’ve got polished diagrams and their reasoning can sound solid. Pretty soon, we’re all parroting these new terms and patterns, often for ideas that have been around for years.
It’s just Vendor-Driven Design.
3) Solving Business Problems Is Hard
Most of us tech folks spend a lot of time learning the tech and not much time understanding the business. In some ways, that makes sense. The technical problems we’re solving are hard, and it’s not always easy to hit pause and zoom out.
But the risk is real: you can end up in an ivory tower of wayward data wizards, building cool stuff that doesn’t actually solve anything. Or maybe you build something that kind of works. Well even the best models or flashiest AI won’t matter if they don’t translate into the real world.
Just ask Zillow.
Business is hard. Don’t believe me? Quit your job and try starting… anything. There’s no such thing as an easy business. And just because you have data doesn’t mean you’ll magically uncover insights no one else has found.
4) Don’t Skip The Fundamentals
I talk about this a lot because it’s still true: the fundamentals matter.
It’s why I’ve been writing so many articles that talk about going back to the basics. We can be so focused on building something new that we don’t check if the foundation is solid.
Even the most advanced infrastructure will fail if it’s built on sand.
Sure, AI can automate some things and help code. But I’m still working on projects where the basics are absolutely required. People still want to pull data from an SFTP and load it into a warehouse. You still need to deal with IAM issues (still a pain). You still need to understand data modeling and of course people still are struggling to answer key questions about their business. None of that has changed.
The ability to apply foundational skills to more complex problems—at scale or across systems with tons of integrations—still matters.
So, build a solid base. Don’t rush. There’s plenty of time to become a senior engineer.
5) Don’t Be Above Putting in the Work
Some people get truly lucky, their family knows someone, they roll a nat 20 on charisma, or life just lines up. Most people aren’t that lucky.
If you’re like most of us, you’ll need to earn your stripes by taking on work that:
Feels repetitive or less exciting than your school projects
Doesn’t show up on highlight reels but keeps systems running
Builds the foundation for deeper, more complex skills later on
We now live in a world where AI can take a lot of grunt work off our plates. Migrating SQL Server to Snowflake? Way easier than it used to be. I remember sinking way too much time into converting Oracle to SQL Server. Sure, there were tools that helped, but they never got it all the way there.
Whatever the grunt work looks like:
Don’t act like you’re above it
Use it as a chance to learn how things really work
And if you think the process is broken? Improve it
6) Ask Why - But Don’t Always Expect A Great Answer
We can be so focused early on in our careers on growing technically that we forget to ask an important question. Why are we even doing the work? Does it actually add value to the business?
I’m not naive enough to think it’s always that simple. If you ask why you’ll be bestowed years upon years of wisdom and business acumen.
Sometimes, your manager is asking you to do something because their boss’s boss told them to, and they’re just trying to keep their job.
That doesn’t mean you shouldn’t ask. You might learn something about the business. Or, at the very least, gain some empathy for the pressure your boss is under.
So yes, ask why. Just don’t expect it to end the conversation, or magically lead to a dynamic shift in the types of requests you’re going to get.
7) Learn to Communicate with Non-Data People
A lot of advice around communication is vague at best. “Just get better at communicating!”
But what does that even mean?
In my experience, there are a few key areas where most of us can improve:
Know your audience: A huge part of communication is understanding who you’re talking to. The best leaders and engineers I’ve worked with are constantly asking, “Who is this message for?” That’s not an exaggeration. I once invited a data leader to join a live session I was hosting, thinking we’d just have a casual chat. Instead, we spent a good hour prepping, discussing the audience, what they needed to hear, and what takeaways mattered most.
Lead with the point: When we deliver analysis (or really any information), many of us, myself included, tend to talk through our entire process first. We want to prove how smart we are. But stakeholders don’t need the play-by-play; they need the takeaway. Say the conclusion up front, then explain how you got there if needed.
Pre-wire key conversations: If you're about to share something controversial, surprising, or high-stakes, don’t wait for the meeting. Send a preview. Talk to one or two key stakeholders ahead of time. You’ll smooth over objections and get more useful feedback.
If you’d like to dig deeper, check out this past article:
4 Strategies To Elevate Your Communication Style From Engineer To Leader
One of the challenges many of us technophiles face is… well, being technophiles. We love the tools, the architecture, the solutions. We obsess over systems, stacks, and edge cases.
That’s all fine—until we try to talk to our business stakeholders as if they’re just as obsessed...
Final Thoughts
Whether you're new to data or have been in the space for years, you’ll always be learning. You’ll get better at communicating your message. You’ll keep reassessing tooling, asking whether something actually improves how you work or if it’s just more marketing fluff.
And that’s the point: you don’t need to have it all figured out straight out of the gate. Even knowing something doesn’t mean it's easy to apply. As one data leader recently told me, “You can know it, but having the discipline to put it into practice is a whole different story.”
Before signing off, I wanted to share a few articles worth reading if you’re just getting started. They’ll help you make sense of how the tech world has evolved—and what hasn’t changed at all.
7 Articles I Think Everyone in Data Should Read
Functional Data Engineering — a modern paradigm for batch data processing
Big Ball of Mud - Architectural Devolution
Video Of The Week - Data Engineers Vs Data Analysts - How Data Engineers Write SQL Vs Analysts
Join My Data Engineering And Data Science Discord
If you’re looking to talk more about data engineering, data science, breaking into your first job, and finding other like minded data specialists. Then you should join the Seattle Data Guy discord!
We are now over 8000 members!
Join My Technical Consultants Community
If you’re a data consultant or considering becoming one then you should join the Technical Freelancer Community! We have over 1700 members!
You’ll find plenty of free resources you can access to expedite your journey as a technical consultant as well as be able to talk to other consultants about questions you may have!
Articles Worth Reading
There are thousands of new articles posted daily all over the web! I have spent a lot of time sifting through some of these articles as well as TechCrunch and companies tech blog and wanted to share some of my favorites!
Model Once, Represent Everywhere: UDA (Unified Data Architecture) at Netflix
As Netflix’s offerings grow — across films, series, games, live events, and ads — so does the complexity of the systems that support it. Core business concepts like ‘actor’ or ‘movie’ are modeled in many places: in our Enterprise GraphQL Gateway powering internal apps, in our asset management platform storing media assets, in our media computing platform that powers encoding pipelines, to name a few. Each system models these concepts differently and in isolation, with little coordination or shared understanding. While they often operate on the same concepts, these systems remain largely unaware of that fact, and of each other.
Why Your Data Stack Won't Last - And How To Build Data Infrastructure That Will
As a consultant, I have been called in to review and, in many cases, replace dozens of half-finished, abandoned, and sometimes forgotten data infrastructure projects.
The data infrastructure in a few cases may just need a little tweaking to operate effectively, but other times the project is either so incomplete or so lacking in a central design that the best thing to do is replace the old system.
Trust me, I’d love it if I could come into a project and simply change a few lines of code, and then everything would just work. However, so many projects are filled with unclear design decisions or resume-driven development that were never rooted in good planning.
End Of Day 184
Thanks for checking out our community. We put out 4-5 Newsletters a month discussing data, tech, and start-ups.
If you enjoyed it, consider liking, sharing and helping this newsletter grow!