Hey, that subtitle kinda rhymes. 🙂 This week’s topic is a bit of food-for-thought. I picked up a consulting gig on top of my full time job and writing so I’ll have a more practical concrete piece to share in the next issue.

For now, I want to talk about something I've noticed across every analytics environment I've worked in. Data Scientists, BI Analysts, Data Engineers, Data Architects and everyone in between. In my opinion it's what separates the professional driving real impact and growing their career from the one just waiting for the next project to land.

There's a kind of tech work that looks completely fine from the outside. Requests come in, work goes out. Queries are clean and processes well documented. Plus no one is complaining! But there's a ceiling that comes with that pattern, and most professionals don't notice it until they've been bumping into it for a while.

I want to take a quick sec to thank everyone who supports PlotStack. We recently became 300+ strong shortly after the last issue dropped. Which if you missed you can read here.

The Difference Between a Good Analyst and a Great One Isn't the Skills

The pattern is the problem. Tech work has a natural gravity to it. A request comes in and generally we scope it, build it, and then ship it. Then feedback loops reward clean execution so we continue on and keep executing cleanly. Nobody flags this as a problem because the work is good and keeps business going. And technically this isn’t bad.

A perfectly built report that gets downloaded, reformatted in Excel, and pasted into a deck before anyone looks at it, that's clean execution applied to the wrong problem.

But the issue is that executing well on the wrong thing is still… the wrong thing.

This is one of the major gaps that actually separates career levels in tech. Not years of experience or how fast you can come up with a SQL query. It's whether you take a request at face value or whether you sit with the objective long enough to understand what's really being asked. One professional produces a deliverable, the other produces a solution.

The most tangible way to make this shift: before touching any request from a team you don't work with closely, ask if you can sit in on a meeting first that’s related to their problem. Just watch how they work or simply have a brainstorming sesh with the do-ers, the ones actually doing the work. Where the real friction lives almost never matches what was in the original ask.

Try this. You don't need someone to tell you first. On the next request that comes in, spend five minutes asking what's behind the ask before you open anything. Better yet, ask to sit in on one meeting first. Most people skip this because it doesn't feel like real work. That's exactly why the ones who do end up standing out.

Which company originally developed JavaScript?

A. Microsoft
B. Sun Microsystems
C. Netscape
D. Apple

Answer at the bottom of this issue

How To Move From "Order Taker" To "Strategic Partner" by Brain Wads
Makes the honest point that staying in order-taker mode has its own appeal, you're doing exactly what you're told and the risk is low. But that positioning yourself as a strategic partner is actually a deeper form of service: helping people get what they need, not just what they asked for. Read more →

What I Am Doing to Stay Relevant as a Senior Analytics Consultant in 2026 by Rashi Desai
Written by a practicing senior analytics consultant, this piece argues that the real shift in data careers isn't technical but rather a mindset change. Data professionals are no longer valued solely for writing queries or building models, but for knowing how to close the gap between insight and action. Read more →

How to Gather Requirements Effectively as a Data Engineer by Erfan Hesami
Covers how successful data professionals zoom out to see the big picture, asking what stakeholders actually want to do with the data rather than just what they're requesting, and how that links analysis back to real business decisions. Read more →

Power BI Project Requirements Guide (Notion Template) #project-management #productivity
From yours truly. I used this template early on in my BI career to help structure the requests my team would get. It’s a great starting point for digging deeper and providing better solutions.

Power BI Theme Generator #productivity #data-visualization
A newer generator on the market with a live preview, light/dark mode support, accessibility-friendly color palettes, and the ability to generate palettes from an uploaded image. A solid pick for those who want their reports to look as good as they function.

No video this week, this one's more of a sit-with-it topic than a watch-and-learn one.

But, if you want a good recco, youtube.com/@KenJee_ds has some great videos. His content regularly touches on career mindset, what separates analysts who grow from those who plateau, and the non-technical side of data work.

Which company originally developed JavaScript?

A. Microsoft
B. Sun Microsystems
C. Netscape ✅
D. Apple

JavaScript was created by Brendan Eich while working at Netscape in 1995 and he built the first version in just 10 days. Originally named Mocha, then LiveScript, it was rebranded to JavaScript as a marketing move to ride the wave of Java's popularity at the time, despite the two languages having almost nothing in common.
📖 Read more → Wikipedia: JavaScript

Newsletter publishing is hard work and it’s just me running the show here. If you ever feel like extending a thanks, idea, or insult you can do that here.
Or email me directly at → [email protected].

If you’re feeling generous, I also keep an Amazon Wishlist of books and tools I’m interested in.