Data Gibberish

About Data Gibberish

Data Gibberish helps experienced data engineers and data leads handle stakeholder requests, scope pressure, and decision-making with scripts, checklists, and playbooks you can use immediately. www.datagibberish.com (https://www.datagibberish.com?utm_medium=podcast)

Publisher

Yordan Ivanov

Category

education · technology

Language

en

Explicit

No

First episode

20 Jan 2026

Latest episode

3 Jul 2026

Latest episodes

11 episodes in the feed.

1. 

   3 Jul 2026

   👷 You're Not Stuck Because You're Not Good Enough

   You are stuck because you are optimizing for the wrong thing. Most data professionals I talk to work incredibly hard at their craft. They go deep on Python, on dbt, on Spark, on whatever the stack is. They take courses, they build side projects, they read documentation on weekends. And then they watch someone else get promoted. Someone who, honestly, is probably less technically sharp than them. Introducing David Langer Dave Langer has been in technology for almost 30 years. He started on the help desk, wrote COBOL on a mainframe at an insurance company, moved into software engineering, and lived through the dot-com crash in the early 2000s. The last 15 of those years have been in analytics, starting with traditional BI and data warehousing, Kimball star schemas, the whole thing, and then moving into more advanced analytics. Dave worked at Microsoft leading a data and analytics team, then at a startup called Schedulicity as VP of Analytics, and at Data Science Dojo. He is a Microsoft Excel MVP, not for writing formulas, but for evangelizing Python inside Excel, which he got early NDA access to in 2023. David wrote a book on Python and Excel published this year, and his second book on SQL for Excel users is coming in 2027. These days Dave is an independent consultant and trainer. He runs a Substack called The DIY Data Scientist, which is exactly what it says: practical tutorials on data analysis for professionals who want to use data better, regardless of their background. We had a live conversation, and this is everything worth taking from it. The Value Ladder Is Not What You Think It Is Every organization has a value ladder. A rough hierarchy of what it perceives as worth paying for, promoting people for, and building strategy around. The problem is that your version of the value ladder and your organization’s version are often completely different things. When you are early in your career, this does not matter much. You are rewarded for technical output: * Write good code. * Ship clean pipelines. * Produce accurate models. That is the ladder, and being technically excellent gets you up it. But at some point the ladder changes. And nobody tells you. What the organization starts rewarding is perceived strategic value. That could mean designing systems instead of building them. It could mean being able to translate between the data team and the C-suite. It could mean understanding enough about the business to push back on a requirement intelligently, not just implement it. If you keep climbing the old ladder while the organization has already moved to a new one, you plateau. Only because you are solving for the wrong problem. The Outsourcing Lesson Think about what happened to a lot of senior engineers in the early 2000s. They had gone deep on C++ (Qt will stay in my heart forever), and read all the right books, so they could architect complex object-oriented systems. And then globalization happened, and suddenly all of that specialized knowledge became a commodity. You could hire it for a fraction of the cost from an outsourcing firm. The people who survived that shift asked: what is the value ladder actually rewarding right now? And the answer was architecture, system design, coordination, the things that required judgment and organizational context. Not just technical execution. The same question applies to you today. Not “how do I get better at this tool?“ but “what is my organization actually paying for?“ If you want a concrete way to map where you actually sit on your organization’s value ladder, that is exactly what the Career Progression Matrix (https://open.substack.com/pub/datagibberish/p/building-a-techincal-job-level-matrix?r=odlo3&utm_campaign=post-expanded-share&utm_medium=web) in the premium library does. Paid subscribers get access to it on day one. Upgrade here. (https://www.datagibberish.com/subscribe) Data Problems Are Not Technology Problems Here is what nobody told me early in my career: The hardest part of working in data is not the data itself, but people If you’ve been in data long enough, you’ve probably been in meetings about the definition of a customer for way too longs. And all of that, just because four departments each had a different answer, and each answer made a different executive look better or worse. This is what senior data professionals figure out. And it is what a lot of talented junior and mid-level people never fully internalize. If your goal is to do technically excellent work in a well-scoped problem, you can stay in your lane and deliver. That is a legitimate career. But if you want to actually drive decisions, if you want your work to change how an organization operates, you are going to spend a significant amount of your time as a mediator. * Between engineering and business. * Between what the data says and what someone wants the data to say. * Between this year’s urgent request and the foundational investment that would make next year’s requests 10x easier to answer. The people who succeed in that space are not always the most technically gifted. But they are always the ones who learned to sit in an uncomfortable call, name the real disagreement out loud, and not flinch when someone gets defensive. Why Teaching Is a Career Asset One of the underrated ways to build this skill is to teach. Not necessarily a course or YouTube tutorial. Just the act of explaining complex technical concepts to someone who does not share your context. It forces you to leave your own head and think from the other person’s perspective. You cannot fall back on jargon. You have to find the analogy that lands for this specific person, not the definition that would satisfy a technical reviewer. That skill transfers directly to stakeholder work. Every time you explain a data model to a VP, every time you scope a request with a product manager who is not sure what they are asking for, every time you push back on a dashboard request by asking “what decision are you trying to make?“ you are doing the same cognitive work. Data professionals who build that muscle early tend to accelerate later. The ones who skip it hit a ceiling. Show & Tell (https://www.datagibberish.com/t/playlist-show-and-tell) is where I work through exactly this kind of thing live. One paid subscriber brings a real situation, and we work through it together in front of the group. Every session is recorded, and included in a paid subscription. Join here. (https://www.datagibberish.com/subscribe) Executives Are Running the Same Hype Cycle Again A few years ago, the mandate was “we need to be data-driven“. Companies hired data teams, built dashboards, set up data warehouses. Most of them never actually became data-driven. But “data-driven“ was the thing, so they built it anyway. Now the mandate is “we need to be AI-first“. The structure is identical: * An executive reads something. * The pressure cascades down. * Someone, often the data team, gets handed the brief: implement AI. The business problem that AI is supposed to solve is treated as secondary. Sometimes it is not even identified. I have seen a company run a churn model comparison: a basic logistic regression built by a data scientist, versus an LLM-based approach. The logistic regression hit 80% accuracy. The LLM hit 50%, which is coin-flip territory. The traditional model also cost a fraction as much to build and run. And that is before you account for what happens when AI pricing moves from flat subscription to usage-based. When your CFO is looking at a bill where the token cost exceeds the salary of the team that could have built a simpler model, the conversation changes fast. Most organizations are not thinking about this right now. They are still in the “we need an AI use case“ phase. The ROI calculation comes later, usually painfully. The Hadoop Lesson Is Already Written During the Hadoop hype cycle, an executive asked Dave whether the company could move their SQL Server databases to run on top of Hadoop instead of fast disks. Because Hadoop storage was cheaper. The executive had read about it in a trade magazine. The answer was no. Obviously. But the fact that the question was asked at all tells you something about how technology hype filters through organizations. It’s all about the anxiety of not being part of the trend. * MongoDB was supposed to kill relational databases. * Excel has been declared dead every year for 20 years. * SQL was going to be replaced by query builders. None of that happened. Some things change. Programming languages come and go. Platforms rise and fall. But the underlying problems stay the same: organizations need to make better decisions using data. The data needs to be clean, structured, and understandable. The people consuming it need context. The Two Questions Worth Asking Here is what I would take from all of this. First, be honest about your organization’s value ladder. Not the one you wish existed, but the one that actually exists. * What gets people promoted here? * What gets people noticed by leadership? * Is it technical depth, or is it business impact, or is it visibility, or is it the ability to manage up Because the answer changes your strategy. Second, ask whether that ladder aligns with what you are actually trying to build. If it does, optimize hard for it. If it does not, that is useful information too. The organization where the ladder aligns with your goals exists. Sometimes you have to find it. The data professionals who stall out tend to do one of two things: they optimize for a ladder that their organization does not value, or they assume the ladder they are on right now is the one they will always be on. Neither is true. Find More From Dave Dave’s Substack is The DIY Data Scientist (https://thediydatascientist.substack.com/?r=odlo3&utm_campaign=pub&utm_medium=web). Every issue is a hands-on tutorial with workbooks, code, and data included, free. If you work with data in any capacity and want to actually understand what you are doing with it, it is worth subscribing. He is also active on LinkedIn (https://www.linkedin.com/in/davelanger/), where his content leans more toward the enterprise and organizational side of analytics. His book, Python for Excel, is available on Amazon (https://www.daveondata.com/) and in Barnes & Noble (https://www.barnesandnoble.com/w/python-in-excel-step-by-step-david-langer/1147563942?ean=9781394340767) stores. — Until next time, Yordan PS: Paid subscribers get the Career Progression Matrix, the full Show & Tell archive, and the entire premium resource library. Upgrade here. (https://www.datagibberish.com/subscribe) PPS: The next Show & Tell session is coming up. A paid subscriber and I will be working on a long on a long therm-career plan. Join here. (https://www.datagibberish.com/subscribe) Let’s Connect Connect on LinkedIn: https://www.linkedin.com/in/ivanovyordan (https://www.linkedin.com/in/ivanovyordan) Work with me: https://www.ivanovyordan.com/coaching (https://www.ivanovyordan.com/coaching) Start journaling: https://www.dearself.ai (https://www.dearself.ai) More on the Topic * The Other Half Of The Job (https://www.datagibberish.com/p/the-other-side-of-the-job) * Why Senior Data Engineers Lose Their Velocity (Even When Their Skills Improve) (https://www.datagibberish.com/p/the-senior-data-engineer-paradox) * Your Best Work Is Invisible Because You Describe It Wrong (https://www.datagibberish.com/p/you-describe-your-best-work-wrong) This is a public episode. If you'd like to discuss this with other subscribers or get access to bonus episodes, visit www.datagibberish.com/subscribe (https://www.datagibberish.com/subscribe?utm_medium=podcast&utm_campaign=CTA_2)

2. 

   17 Jun 2026

   👷 How to Use AI Like This World Class CDO

   I had a great chat with Nick Valiotti (https://substack.com/profile/170793541-nick-valiotti). Nick built his fractional CDO practice around one bet: growing companies need senior data leadership long before most of them can afford it full time. He wrote the playbook down in his book Your Fractional CDO, after watching the same failure pattern repeat across years of client work. A data team builds perfectly modeled tables, clean naming conventions, a finished warehouse, and still fails at the one job that matters. The failure starts in the hiring order, months before anyone touches SQL. The Pattern Behind Almost Every Broken Data Team A company grows, raises money or bootstraps itself, and builds product and marketing first. Data waits. By the time anyone notices, the gaps have already turned into blind spots in real decisions. The fix usually starts with a data analyst, hired to both analyze the data and build the warehouse underneath it. He patches things together with whatever is closest: ad hoc imports from spreadsheets, quick pipelines wired through whatever tool is available. It works until it doesn’t. So the company hires a data engineer to rebuild the plumbing properly. Pipelines get rebuilt, structure improves, the technical layer finally looks right. It still doesn’t work. Nobody ever agreed on what the numbers mean. A clean warehouse built on an unresolved disagreement only makes the disagreement faster. This is the gap a fractional Chief Data Officer gets hired to close. The job is the translation layer between what the business is trying to decide and what the data team is building. Head of Data, VP of Data, Chief Data Officer, the title changes. The job underneath stays the same: turn business priorities into a data roadmap, then close the distance between the two. Three People, Three Numbers, One Metric When the role gets done right, the first move rarely touches the warehouse. On one project, the opening round of conversations with C-level stakeholders surfaced a single metric, active subscriber, calculated three different ways by three different executives. Each one trusted their own version. Nobody had flagged it as a problem, because nobody had compared notes. The fix starts with a written catalog of every metric that matters: what it counts, what it excludes, who owns the definition. It lives somewhere simple, a Notion page, an Obsidian vault, plain markdown files, and every stakeholder signs off on a definition before a single pipeline gets touched. Skip that step and the technical work inherits the argument anyway. A warehouse with perfect naming conventions and a properly modeled transformation layer still produces three different numbers for active subscriber, because the disagreement never lived in the tables. It lived in the room full of people who never sat down to agree on what the word meant. Your career is not stuck because you lack technical skills. It is stuck because nobody taught you how to operate. Stakeholder management. Business translation. Career positioning. I write about all of it every week What AI Changed The Audit That Used To Take A Month When Nick onboarded onto a new client’s stack, he inherited a Metabase instance holding around 2,000 saved questions, each one a SQL query sitting on top of the warehouse. Reading through that by hand to figure out which tables and metrics mattered used to eat him three to four weeks. He connected an LLM to Metabase’s API and turned the same task into a question-asking exercise: which tables get used most, which metrics get calculated more than one way. The 2,000 saved queries referenced around 90 tables in the warehouse. Only 12 of them turned out to matter. The same pass produced a first list of conflicting metric definitions, the kind of list that used to take weeks of stakeholder interviews to assemble by hand. It became the opening line of the metric catalog conversation. The conversation with stakeholders still had to happen. A Personal Operating System Outside of any single audit, Nick’s daily workflow runs through a stack of connected tools: email, Slack, Telegram, WhatsApp, Jira, Google Calendar, a meeting note-taker, a task planner, a personal fitness tracker. Each one is wired in through its own API, feeding into folders organized by client, by teammate, by personal project, written up as markdown files an AI assistant reads for context. A new lead from the website used to mean reading an email and booking a call. Research on the prospect now happens automatically, the call transcript gets analyzed for next steps, and a draft proposal and CRM update follow without him typing either one by hand. He still types every prompt himself. Roughly 90 percent of his working day still happens inside an editor, reading something, asking a question about it, deciding what happens next. The Rules That Don’t Bend Speed doesn’t extend to trust. A short list of rules stays fixed regardless of how good the tools get: * Every SQL statement an AI writes gets verified by a human before it touches anything live or anything tied to budget. * Raw client data never goes into a public AI tool. Only metadata about the data does, table names and query structure, never the rows underneath. * Sensitive processing happens through local models inside the client’s own environment instead of commercial platforms. Delivery got faster. The job grew, because speed opens room to take on more work. Judgment Became The Scarce Skill As AI absorbs more of the execution, headcount on this kind of team is shrinking on purpose, driven by a bet: enable each remaining data analyst and engineer with AI rather than hiring more people to do routine work that AI now does faster, the documentation nobody wanted to write, the boilerplate code, the first draft of a pipeline. Not everyone takes that bet. Some experienced data engineers distrust the output outright or keep working the old way out of habit. That resistance is becoming the dividing line. Once anyone is able to write a working SQL query or stand up a dashboard with AI’s help, calculation stops being the skill that earns a senior title. Reasoning about why a stakeholder cares about a specific number takes its place. The valuable hire thinks strategically about the business and catches the cases where the fast answer is the wrong one. I built the resource library I wish existed when I was 25 years old. Career scripts. Business translation templates. Stakeholder playbooks. Meeting frameworks. Every single one came from real situations, real mistakes, and real results. Paid members get the whole thing. Reporting Lines Decide Whether The Job Works Where this role sits on the org chart changes what it’s able to do, regardless of the title on the business card. Put the data function inside engineering and it drifts toward whatever a chief technical officer recognizes as good work: pipelines, infrastructure, technical correctness, thinly connected to what the business is trying to decide. Put it inside finance and a different bias shows up. Finance’s own questions get solved first simply because of who the team reports to, while marketing or product priorities wait their turn even when they matter more to the business right now. Neither placement is wrong on paper. Both pick a winner without saying so. The function works best as a peer to product, marketing, and finance rather than a report inside any one of them, sitting at whatever level makes the final call on what the company builds next: a CEO in most structures, whoever arbitrates between general managers in flatter ones. The job stays the same either way. Listen across every department, then build the data foundation that unblocks all of them instead of only the one holding the budget. None of this requires the word “Chief” in the title. It requires someone willing to do the unglamorous work of getting people to agree on what a number means before anyone touches a pipeline, and the discipline to use AI as a way to do that work faster rather than as a reason to skip it. Find Nick Online You can find Nick on a number of places. I strongly recommend following Nick on LinkedIn and subscribing to his Substack. * Valiotti Data (https://valiotti.com/), the agency Nick runs as a fractional CDO for growing companies. * LinkedIn (https://www.linkedin.com/in/valiotti/), where most of this thinking shows up first. * Substack (https://nickvaliotti.substack.com/), where Nick writes long-form content. * Your Fractional CDO (https://www.amazon.com/Your-Fractional-CDO-Nick-Valiotti-ebook/dp/B0G3954N5S), the book written for executives building a data function for the first time. — Yordan More on the Topic * Where Your Data Team Sits Is a Strategic Decision (https://open.substack.com/pub/datagibberish/p/where-your-data-team-needs-to-sit?r=odlo3&utm_campaign=post-expanded-share&utm_medium=web) * Data Platforms Exist to Enforce Consistency, Not Enable Insight (https://open.substack.com/pub/datagibberish/p/data-platforms-exist-to-enforce-consistency?r=odlo3&utm_campaign=post-expanded-share&utm_medium=web) * The Operating System Every Data Engineering Leader Needs (https://open.substack.com/pub/datagibberish/p/the-data-engineering-manager-operating-system?r=odlo3&utm_campaign=post-expanded-share&utm_medium=web) Data Gibberish is a reader-supported publication. To receive new posts and support my work, consider becoming a free or paid subscriber. This is a public episode. If you'd like to discuss this with other subscribers or get access to bonus episodes, visit www.datagibberish.com/subscribe (https://www.datagibberish.com/subscribe?utm_medium=podcast&utm_campaign=CTA_2)

3. 

   15 May 2026

   👷 What Olympians, CEOs, and Lords Have in Common

   Presenting Peter Mukherjee Peter built a London business from scratch in 1992, grew it into an international franchise network with a public listing, and lost most of it to the 2008 crash. He reinvented himself as a professional architectural photographer and worked at it for fifteen years before retiring in 2023 to write full-time. I’ve known Peter Mukherjee (https://substack.com/profile/105005627-peter-mukherjee) for about an year now, and he’s one of the wisest people I’ve ever talked to. The whole time he was talking during our conversation, I kept hearing the same diagnosis for why most senior engineers hit a ceiling. You are managing your career like an employee. The people who break through manage it like a business. They use a different vocabulary, run a different operating system, and make different decisions. None of it requires another certification, and all of it requires a mindset shift most senior engineers never make. Forced Pivots Surface The Rest Of You The default for a generation was 30-40 years at one employer, a stable pension, and a CV that looked sensible. The world does not work that way anymore. Multiple careers across one working life is now the norm. The hardest version is the forced pivot. Income stops, status stops, and everything you built is on hold while you scramble to establish something new. Getting through it requires confidence in your own abilities, because most people are more capable than they give themselves credit for, and the work is digging deep, finding the talents you have, and pulling yourself through. Resilience is built mostly through failure. There is no shortcut. You learn the most during the times you fail, because failure forces you to dig in and recover. The worst response is going negative, looking backwards, sliding into “what have I done“. That posture stops the recovery before it starts. The deeper insight is that most people never find out what their real talents are. They pick the first thing they think they are good at and develop only that. There might be tens of thousands of people with that level of athletic talent who never find out they run, because they never explored their full range. When things go wrong, you are forced to ask “what else am I good at?“ That question, under pressure, surfaces the talents the comfortable version of you never bothered to look for. The Old Leadership Model Is Finished The safe pair of hands is done. Steady the ship, grow dividends 5-8% a year, stay around for ten years. That mindset takes the business backwards now, because the world moves too fast for it. Standing still is moving backwards. The replacement is the transformational leader. Transformation involves risk-taking, which only works if the culture supports it, which means giving your people permission to take risks too, without making them fear for their jobs when they get something wrong. Apple and Google run open plans where managers sit among their people. Senior managers might have an office, but it is glass-sided so people see them and they see their people. Any transformational leader has to be able to carry their people through change, and you only carry them properly if you are visibly involved with them. A successful US business leader who talked about being vulnerable in front of her people in the 90s was told “that’s because you’re a woman“. Now every leadership conversation centres on empathy and vulnerability. COVID accelerated it and AI will accelerate it further. Where Leaders Lose People The biggest source of failure is arrogance and ego, and the biggest organisational consequence is losing the people you invested time and money into developing. You will always be outbid on salary. There is always someone offering more money. But the one thing people put ahead of the bigger paycheque is enjoying where they work. The manager who is arrogant, ego-driven, and disconnected from their team creates an environment people are eager to leave, and that manager loses good people on a clock. Humility Is The Hardest Lesson The kind of humility forced on you by having to let go of people who built the business with you. Telling someone who has been with you for 15 years that the business is closing is one of the hardest things a leader does. There are two ways to handle it. The first is matter-of-fact, because that is what organisations do. The second is to treat the moment with the weight it carries for the person on the other side of the desk, with empathy and active care for what happens to them next, including helping them frame what they learned. The relationships survive the second version. The same principle runs through every other team interaction. Make people feel included, valued, recognised. A specific mechanic that works: team-level bonuses where the team itself decides who the top contributors are. Everyone shares in the reward, but the team picks the largest pieces. It does not have to be financial. A day out, a big dinner, share options. The point is structuring recognition so it incentivises working together instead of competing. The 51/100 Rule The mythology of the successful CEO making lots of right decisions is wrong. Every CEO is making decisions every day, and some they get wrong, sometimes catastrophically. The batting average, from Ursula Burns (former CEO of Xerox, started as an intern): out of every 100 decisions, you make 51 good ones and 49 bad ones. The job is making sure the 49 bad ones are not too bad. You afford one or two howlers, but the rest need to be recoverable. If you have an immaculate record of getting everything right, you are not taking enough risk, and your career is moving backwards while you congratulate yourself for being right. The mechanic underneath is reversibility. Good risk-taking is calculated, not suicidal. Sort every decision into reversible and irreversible. The reversible ones get volume. The irreversible ones get contingency planning. The downside in the reversible bucket is embarrassment and a week of recovery. The downside in the irreversible bucket is structural and measured in years. Most senior engineers treat every decision as if it were in the irreversible bucket. They spend two weeks deciding whether to submit a conference talk. They draft a LinkedIn post and never publish it. They workshop an internal proposal until the moment to make it has passed. The cost is invisible because nothing went wrong. Nothing happened at all. Stop collecting advice. Start operating differently. I share the exact playbooks that helped me become Head of Data, negotiate a 40% raise, and survive 4 M&A transactions. Paid subscribers use them to get promoted. Curiosity Is The Response To Uncertainty For individuals, the best response to uncertainty is curiosity. Nobody becomes successful without it. Learning does not stop when you finish university. Curious people are the ones who do something big. Invest in emotional skills. Degrees matter less. The capability to communicate, manage people, be visionary, be inspirational, and bring creativity is what employers will look for. Those are the skills that differentiate you in three years’ time, and they are the ones currently at risk from the AI-as-co-pilot trap. The AI Entropy Warning Entropy is a real thing. Systems decay toward their lowest energy state when nothing pushes back. Brains are a system. The muscle you stop using is the one that atrophies. People who used their brains for the work are now using AI for the work. The output looks fine. The brain underneath is going to sleep. The fix is using the tools while keeping the thinking. Let AI draft, then edit by hand, let it summarise, then read the source or let it suggest options, then make the decision yourself and write down why. The skills that cannot be outsourced are the ones the technical job market will pay for in three years, and right now the industry is volunteering for neglect. Load The Dice Yourself Every successful person credits luck. A specific phone call, a meeting, a door that opened at the right moment. A single phone call was the pivot for a multi-billion-dollar career, where the answer was 50-50 right up until it was given. The mistake is to hear that and conclude luck is random. Luck is a numbers game with a rigged distribution. Go to one networking event a year and talk to three people you already know, you have three lottery tickets. Go to five events and talk to ten new people each, you have fifty. Same person, same skills, sixteen times the surface area for a lucky break. For data engineers, the equivalent is volume of visible work. Internal documents that travel. Brown bags and lightning talks. External writing. Conference submissions. Every one of them is in the reversible bucket. The hit rate on any individual piece does not matter. The volume across all of them does. The wider pattern shows up in every successful career: luck plus passion. Everyone talks about their passion for what they do, and there is a direct correlation between success and finding it. “Follow your passion” only works if you have one. If you have not found one, the work is exploration. Keep looking until you find the thing you love. Until then, every step is a stepping stone. The cost of getting this wrong is what makes the rest of it urgent. The greatest risk is that you never find success and fulfilment because you stuck with something you did not love. Sir Clive Woodward, the England rugby head coach who won the 2003 World Cup, put it this way: The worst thing that happens in life is getting older and looking back thinking “I wish I’d taken a chance on that“ Treat Yourself As A Business Inside The Organisation Change your perception of your role. You are no longer “the programming manager.” Look at yourself like a one-person business inside the organisation you work for. Promote yourself. Acquire the skills. Develop yourself the way a business develops. The language change shows it: Saying “I am an admin manager, I have been doing this for seven years“ tells the listener nothing. Saying “in the last seven years I have organised X, I have done Y, these are the successes, these are my strengths, this is where I add value, these are the things I will carry forward to help your organisation“ is a different conversation. That is how you communicate inside the organisation. That is how you describe yourself outside it. Life is like snakes and ladders. You roll the dice, you move forward. Lucky, you climb a ladder. Unlucky, you slide down a snake. The mistake is to think your future is dependent on the roll of the dice. Most people are more in control of their destiny than they think. Too many expect someone else to design their career. The alternative is to go out, meet people, decide your own projects, decide your own career. I built the resource library I wish existed when I was 25 years old. Career scripts. Business translation templates. Stakeholder playbooks. Meeting frameworks. Every single one came from real situations, real mistakes, and real results. Paid members get the whole thing. Final Thoughts The senior engineer ceiling is not built out of skill gaps. It is built out of an operating model imported from the codebase: optimise for being right, ration the decisions, stay invisible until you are sure. That model breaks the moment the job stops being primarily technical, which is the moment the ceiling appears. The people on the other side run a different model. They aim for 51 out of 100, sort decisions before they spend time on them, and surround themselves with people better than they are. They take humility seriously and ego personally. They keep their brains on while the industry switches theirs off. They describe themselves like a business that knows what it sells. None of it requires a certification. All of it requires the mindset shift most senior engineers never make. Where To Find Peter Peter writes A Few Wise Words (https://open.substack.com/pub/afewwisewords) on Substack. The book is available in hardback, paperback, Kindle, and audiobook, the audiobook (https://afewwisewords.com/landing-page/) read with 12 different voices, one per contributor. — Yordan This is a public episode. If you'd like to discuss this with other subscribers or get access to bonus episodes, visit www.datagibberish.com/subscribe (https://www.datagibberish.com/subscribe?utm_medium=podcast&utm_campaign=CTA_2)

4. 

   26 Apr 2026

   The Identity Shift Nobody Warns You About When You Become a Team of One

   Presenting Yuki Kakegawa Yuki is a Staff Data Engineer, author of the Polars Cookbook, and the founder of Orem Data. He writes about data tools and independent consulting on Substack and LinkedIn. I asked Yuki (https://substack.com/profile/89127157-yuki), Staff Data Engineer and author of the Polars Cookbook, what the biggest adjustment was when he became a team of one. He skipped tooling. He skipped workload. He said this: It’s a shift in mindset. You’re not a data engineer anymore. You’re a data person helping the business with data and analytics That sentence landed harder than I expected, because most people assume the challenge is the technical breadth: wearing all the hats, being the analyst, the engineer, and the data scientist rolled into one. That part is visible. What nobody talks about is the identity part. You Were Hired as a Data Engineer. That Is the Problem. At a large company, your identity is your scope. You do pipeline work, pass it to the analyst, the analyst makes the report, the report goes to the business. You are one node in a chain, and that chain insulates you from the messiness of what the business needs. When you’re a team of one, that chain is you. Yuki described his current day-to-day: * talking to the business to understand what they care about * translating that into projects * building the pipelines * building the models, * building the reporting layer * delivering insights directly to stakeholders He skips the handoff entirely. That scope describes a different job, built around a different identity. The Selfishness That Kills You He used a word that surprised me: selfish. When I was first getting started, I wanted to work on pipelines and I didn’t want to work on reporting. That selfishness kills you in this role. You have to be flexible and you have to care about the business first. Most data engineers have strong opinions about which work is worth doing. Pipelines are interesting. Reporting is boring. Data modeling is craft. Dashboards are noise. Those opinions are how you survive in a large org where you can negotiate your scope. A team of one has no scope to negotiate. The business has no interest in which part of the stack you find meaningful. The work that needs doing is the work you do, and if you have not made peace with that before taking the role, the first six months will feel like a slow grind against a situation you agreed to. What Is Broken at Every Startup You Walk Into I asked Yuki what he finds broken almost every time he walks into a young company. Tooling is rarely the issue. It’s the processes around the processes that produce the data used for reporting and analytics downstream. And the alignment on what’s important, the definition of metrics, what we want to build. Two things. The upstream processes that generate data, and whether the business has agreed on what the numbers mean. The stack is almost never the problem. The Metric Definition Problem This is the one that is hardest to fix and most commonly ignored. Yuki described the ideal state: every metric the business cares about is written down, defined, and agreed on before the data team touches a model. When that is true, the data team’s job is implementation. The hard part is already done for you. The real state at most companies is three departments with three definitions of the same number. If you use one team’s definition, you put another team in a bad spot. If you try to reconcile them, you are suddenly in a political conversation nobody hired you to have. I’ve been in that position. That’s the part I hated the most. Defining core metrics early, before the company grows, before each department builds its own reporting layer, before everyone has opinions baked into their own numbers, is more valuable than any pipeline you will build. If you’re walking into a company where this work is undone, do it first. How to Handle the Stakeholder Who Thinks Your Work Takes Two Weeks Yuki described a pattern that every team-of-one data person will recognise. A stakeholder requests a report, thinks it can be done in two weeks, and the data behind it is messy enough that you know it will take four. I can try, but I can’t promise, because I think these things will be bottlenecks. Two things are happening in that exchange. Setting expectations is the obvious one. Making the complexity visible is the one that changes the relationship long-term. When you’re the only data person, the rest of the company defaults to assuming data work is fast. Pull the numbers, build the report, done. They genuinely have no frame of reference for what it takes to model messy source data into something accurate enough to make decisions with. Your job is to narrate the work before you do it, and skip the explanation after you miss the deadline. Data Gibberish is a reader-supported publication. To receive new posts and support my work, consider becoming a free or paid subscriber. The Transparency Stack Yuki added something that makes the whole prioritisation problem easier: making your priority stack visible to the entire business. Being transparent about what you’re working on and what the priorities are is important. Because if one stakeholder thinks his project is the top priority, but I’m working on a priority item requested by the CEO, then that stakeholder will understand that his project is not at the top. This works because it shifts who does the priority negotiation. When everyone can see the queue, the conversation moves from “why isn’t my thing done“ to “is my thing in the right place in the queue“. The second conversation is faster and involves fewer emotions. Accuracy vs. Speed Is a Trade-Off to Name, Not a Choice to Make Alone I pushed Yuki on a question that sounds simple: accuracy or speed? Definitely accuracy. But that’s where your skill comes in. How do you deliver projects fast while ensuring accuracy? The real answer lives in the communication around the trade-off, not the trade-off itself. If you can deliver in one week at 80% data quality, or in two weeks at 100%, the stakeholder should make that call. They can only make it if you put the options in front of them explicitly. If you wait two weeks, I can ensure 100% accuracy. If you want it in one week, there might be things that still need to be pinned down. Yuki’s underlying point is worth sitting with: making decisions on low-quality data defeats the entire point of data-driven decision making. Speed that produces bad numbers is a liability that takes three times longer to fix than the shortcut saved. On Using AI When You Have Nobody to Think With One thing Yuki said is worth pulling out directly, because it is the most honest framing of AI use I have heard from anyone working in the data space: I use AI especially when I want to bounce ideas around. I use it because I don’t have anybody else to talk to, because I’m the only data person. AI as a rubber duck rather than a replacement for judgment. At a startup where you’re the only data person, you have no peer to sanity check your modeling approach, your architecture choices, or whether your prioritisation call makes sense. AI fills a small part of that gap. But Yuki also admitted he is not sure AI is making him faster overall. The time he used to spend building the solution, he now spends validating what the AI built. The total may net to zero, with the shape of the work changed and the volume unchanged. That matches what I have seen. AI handles narrowly scoped, well-defined tasks well: understanding what a table column means by parsing the codebase, generating boilerplate inside a framework you have already defined, drafting initial SQL that you then refactor. For architectural decisions and anything that requires sustained judgment, the model is an input, and the judgment stays with you. Connect With Yuki Yuki is very active online. Here are some of the best ways to connect with Yuki: * Substack profile (https://substack.com/@yuki1) * The Data Toolbox (https://thedatatoolbox.substack.com/?utm_campaign=pub&utm_medium=web) * The Independent Insight (https://theindependentinsight.substack.com/?utm_campaign=pub&utm_medium=web) * LinkedIn profile (https://www.linkedin.com/in/yukikakegawa/) * The Polars Cookbook (https://www.amazon.com/Polars-Cookbook-practical-transform-manipulate/dp/1805121154) * Consultancy website (https://www.oremdata.com/) — Yordan Data Gibberish is a reader-supported publication. To receive new posts and support my work, consider becoming a free or paid subscriber. This is a public episode. If you'd like to discuss this with other subscribers or get access to bonus episodes, visit www.datagibberish.com/subscribe (https://www.datagibberish.com/subscribe?utm_medium=podcast&utm_campaign=CTA_2)

5. 

   19 Apr 2026

   How to Transition from Managing Pipelines to Managing People like Prajakta

   Presenting Prajakta Yerpude Prajakta spent a decade climbing every rung of the data engineering ladder, intern, engineer, senior, lead, manager, and somewhere along the way realized her biggest impact was no longer in the code she wrote but in the people she unblocked. Getting promoted into management felt like winning. I had the title, the 1:1s, the org chart with my name at the top. What nobody told me was that everything I had spent years getting good at had just become irrelevant. The skills that got me the promotion were the wrong ones for the job. Speed, ownership, technical control, those are IC superpowers. In management, they become liabilities. Prajakta figured this out the hard way too, after a decade climbing every rung of the data engineering ladder. What she learned on the other side is clearer than anything I've read on the topic, and it maps almost exactly to where most senior data engineers quietly stall You Are Already a Manager Before the Title Most people wait for the promotion to start operating differently. That is the wrong order. The data professionals who get promoted into leadership are not the ones who wanted the title. They are the ones who were already doing the work before anyone gave it to them. Clarifying requirements with stakeholders when nobody asked. Helping teammates get unblocked when they had their own deliverables to ship. Asking the why behind the problem instead of just solving the what. The Week Your Code Sits Untouched There is a specific moment that signals the shift. You get to the end of a week and realize you made almost no progress on your own work — but the team moved forward because of the conversations you had. That discomfort is the job changing underneath you. If you wait until the title to start operating at the next level, you are asking your manager to take a bet on future behavior. That is a harder sell than showing them behavior that is already there. Speaking Up Is a Skill Early in any leadership journey, the most uncomfortable moment is the same for almost everyone: being in a room of more experienced people, knowing something is wrong, and deciding whether to say it. The imposter syndrome is real. The difference is learning not to let it make the decision for you. Facts Remove the Politics In data, you have a specific advantage: you can ground a challenge in numbers and evidence. When you do that, you shift the conversation from opinion to information. The most experienced person in the room does not win by default anymore. Leadership is about stepping up when something needs to be said. That is available to you at any level. An intern can flag a bad assumption. A senior IC can challenge a decision made three levels above them. The cost of staying quiet is harder to measure than the cost of speaking up. But it compounds over time. Empathy Is Leverage. As engineers, we are trained to solve technical problems. The higher you go, the more you realize the hardest problems are people problems. Misalignment. Stress. Lack of clarity. Someone having an off day. These do not have a clean solution. Some of them do not need a solution at all. Instead, they need listening. The Problem-Solver Trap The instinct to fix things immediately is exactly what gets senior ICs into leadership. It is also the thing that makes early management hard. Not every situation calls for a solution. Sometimes the person in front of you just needs to feel heard. When you learn to read that distinction — when you can tell the difference between a problem that needs solving and a person who needs to know you are paying attention — the team responds differently. People who feel understood and supported perform better without you pushing harder. You do not manufacture that with a process or a framework. It is built through consistent, genuine attention to what is actually going on beneath the surface. Technical skills get you to the role. Empathy and emotional intelligence determine how far you go inside it. Your Impact Becomes Invisible. That Is the Whole Point. As an IC, your output is visible. Code you wrote. Pipelines you fixed. A cost number you moved. You can point to it directly. As a manager, your impact shows up through other people. Better decisions. Stronger execution. A team delivering consistently and growing in the process. None of that has your name on it. Unlearning the Need to Own the Outcome The hardest thing to unlearn is tying your personal value to what you directly produce. Andy Grove put it clearly in High Output Management: your output as a manager is your team’s output. That is the measure. You do not have a separate output anymore. The team speaks on your behalf. That means impact can look like: * Creating the right direction when things are ambiguous * Removing friction before it slows the team down * Helping someone succeed in a way they would not have without your support * Building the environment in which good work happens consistently You stop building systems. You start building the conditions in which good systems get built. That is more scalable than anything you could ship yourself. The Myth That Needs to Die The most persistent management myth: a good manager always has to be in control of everything. New managers fall into it. Experienced managers fall into it. They believe that effectiveness means knowing every detail, monitoring closely, and constantly stepping in. What that actually creates is dependency. It slows people down. It makes you a single point of failure. The Real Measure The actual measure of good leadership is when your team can collaborate, problem-solve, and resolve issues without you needing to be in the room. When something gets fixed before you even know it happened. That is the job done well. High standards work better when trust already exists. When people know you genuinely support them, they are more open to feedback, more willing to stretch, more willing to take on work that makes them uncomfortable. You can be kind and still be clear. You can be supportive and still hold people accountable. The balance is a more effective version of both. Final Thoughts The move from IC to manager is a step sideways into a completely different job that happens to sit inside the same organization. The data professionals who stall at senior are almost always technically strong. They can build. What they have not yet built is the capacity to make others better at building. If you are waiting until you feel ready to step into that, here is the honest version: you will never feel fully ready. Growth happens because you stepped forward before you did. — Yordan More on the Topic These are some of the articles Prajakta mentioned in our chat: * The Operating System Every Data Engineering Leader Needs (https://open.substack.com/pub/datagibberish/p/the-data-engineering-manager-operating-system?utm_campaign=post-expanded-share&utm_medium=web) * Business value mapping playbook: How to translate data work into executive language (https://open.substack.com/pub/datagibberish/p/translate-data-work-into-executive-language?utm_campaign=post-expanded-share&utm_medium=web) * How To Stop Waiting For Permission To Lead Data Engineering (https://open.substack.com/pub/datagibberish/p/how-to-stop-waiting-for-permission-to-lead-data-engineering?utm_campaign=post-expanded-share&utm_medium=web) * Why Senior Data Engineers Lose Their Velocity (Even When Their Skills Improve) (https://open.substack.com/pub/datagibberish/p/the-senior-data-engineer-paradox?utm_campaign=post-expanded-share&utm_medium=web) This is a public episode. If you'd like to discuss this with other subscribers or get access to bonus episodes, visit www.datagibberish.com/subscribe (https://www.datagibberish.com/subscribe?utm_medium=podcast&utm_campaign=CTA_2)

6. 

   10 Apr 2026

   University Doesn't Teach Data Engineering. Here's What You're Missing.

   I had a chat with Mihail (https://www.linkedin.com/in/mihail-petrov/), a software engineering lead who also lectures at Plovdiv University. He teaches data engineering as an elective because the core CS curriculum has zero room for it. That tells you everything about the state of data education. Universities produce graduates who know SQL syntax, basic normalization, and enough theory to pass an exam. Then those graduates walk into jobs where the theory is the easy part. The pipelines, the warehouses, the cloud platforms, the stakeholder conversations, the ambiguity of real problems. None of that shows up in a lecture hall. I got my databases grade in university and it was mediocre. I didn’t care because the course felt abstract and disconnected from anything real. Most students feel the same way. And the system does nothing to change that. The gap between what university teaches and what the job demands keeps growing. But the fix is simpler than most people think, and it starts long before graduation day. The Curriculum Stops at SQL University data education peaks at a single databases course in your second year. You learn what SQL is, what a database does, and some theory about normalization and data storage. The course is abstract. Students treat databases like glorified Excel files because nobody shows them why the syntactical overhead matters. Until you work on large-scale projects, the difference between a spreadsheet and a relational database feels like a bureaucratic formality. And that databases course is the baseline for everything data-related in the entire degree. Everything Beyond SQL Is “Too Specialized” From that point, data science branches into math and statistics. Data engineering branches into pipelines, warehouses, cloud platforms, ETL, governance. The university follows neither branch with any depth. The reason is structural. Introducing a new subject into a CS curriculum takes years of bureaucratic and administrative effort. Universities teach foundations because foundations are stable. Specific technologies move too fast for a system designed to change slowly. * SQL is foundational enough to make the cut * Snowflake, Databricks, dbt, Airflow are all “too specialized” * Anything resembling a real data engineering stack gets classified as professional training, outside the university’s scope Data Gibberish is a reader-supported publication. To receive new posts and support my work, consider becoming a free or paid subscriber. The 10-Year Lag Is Built Into the System Mihail put it bluntly. Universities are roughly a decade behind the industry. By the time a discipline earns a permanent spot in the curriculum, the profession has already moved on to the next generation of tooling. The workaround at Plovdiv University is elective courses. Mihail and his colleagues created an entire data engineering track outside the required curriculum. Students who are dedicated sign up semester after semester and piece together the big picture on their own initiative. A full data engineering discipline exists in the master’s program, but only because individual lecturers pushed for it. The core curriculum still treats data engineering as a niche profession. The students who figure out it matters do so despite the system, not because of it. Hard Skills Used to Be Enough. They Aren’t Anymore. A few years ago, knowing one programming language and one framework got you hired. The COVID-era hiring boom rewarded narrow skill sets. Companies needed seats filled. They needed people who could write code in a specific technology and ship tickets. Thousands of junior developers entered the industry every month on the back of a single concentrated skill. No curiosity required and no product understanding expected. Know React, get a job. That worked because the economics supported it. The Market Shifted and the Craftsmen Got Stuck The economics changed. Companies stopped hiring for volume. AI tools absorbed the foundational knowledge work. People who built their entire career around one framework or one language found themselves competing with a chatbot that explains object-oriented programming better than most university courses. Information is everywhere now. What separates a valuable engineer from a replaceable one is everything around the information. * Understanding the product and the customer * Adapting when the tooling changes underneath you * Operating with judgment in ambiguous situations * Communicating with stakeholders who speak a different language than you do Universities Still Train for the Old Game The university teaches you how to use tools. The job requires you to understand why you’re using them and what problem they solve for the business. Mihail made a sharp distinction. Universities produce IT people, not developers. The degree gives you logic, math, and a surface-level tour of programming concepts. But the industry needs people who solve problems related to communication, technology, and economics. Those are three different skill sets, and a CS curriculum addresses one of them on a good day. The people who stall are the ones who treat graduation as the finish line. The ones who keep going treat it as a starting point for a much longer education that happens inside the business, inside the community, and inside the messy reality of real projects. Your Network Is Your Actual Career Engine The cliche says your network is your net worth. It holds true even when you look for a job. Blasting CVs across LinkedIn is the path of least resistance. It feels productive because you’re doing something. But it’s a low-leverage move that puts you in a pile with hundreds of other applicants who look identical on paper. Mihail’s company has never posted a single job offer on a popular platform. They hand-pick students directly from the university. Every hire comes through relationships built during lectures, projects, and community events. That pattern repeats across the industry more often than people realize. Show Up Where the Decisions Happen Conferences and user groups are where project leads, hiring managers, and senior engineers gather to talk about the work they care about. These people are approachable in that setting. They want to talk shop. The move is to ask about their problems, not their openings. * What kind of scaling challenges are you dealing with? * Where does delivery break down on your projects? * What does your data stack look like and where does it hurt? These questions signal curiosity and understanding. “Do you have any open positions?“ signals desperation. One leads to a conversation. The other leads to a polite nod and a business card that goes nowhere. Make Yourself Visible Before You Need a Job If you’re early in your career and don’t have deep experience to share, you still have options. A GitHub project, a blog post about a technology you’re learning, a short tutorial, a LinkedIn thread documenting what you figured out this week. None of these need to be brilliant. They need to exist. Visibility compounds. The people who run conferences and user groups see the same faces year after year. They remember your questions, and when a role opens up on their team, they think of the person they’ve been talking to for the last six months before they think of the 200 CVs sitting in their inbox. I found my current company through conferences. Several people I’ve worked with came from user groups and community events. This is how the industry works when you look past the job boards. Find Misho Here’s how you can find more about Mihail and his initiatives for data newcomers. Everything he does at this point is in Bulgarian, but Mihail promised to start building educational content in English, too. * LinkedIn profile (https://www.linkedin.com/in/mihail-petrov/) * Snowflake user group (https://usergroups.snowflake.com/bulgaria/) * Free Snowflake course (https://discord.com/invite/hXzqRgBZ) Closing Words The university gives you a starting line. Logic, math, a community of confused peers who share your ambition. That matters more than the cynics admit. But the finish line is somewhere else entirely. The skills that make data engineers valuable are built in the space between academia and industry. Pipelines, product thinking, stakeholder conversations, judgment under ambiguity. No curriculum covers this. No lecture hall prepares you for the moment a stakeholder asks you to scope something that has never been done before and expects an answer by Thursday. The people who figure this out early have an unfair advantage. They show up at conferences while still in their second year. They build side projects that prove curiosity, not mastery. They surround themselves with people who are ahead of them and ask questions until the vocabulary clicks. The people who wait for a curriculum to teach them what the job demands graduate with a degree and a gap where their career momentum should be. University is a foundation. Treat it as one. Build everything else yourself. — Yordan More on the Topic * The Surprising Trait That Beats Experience (https://open.substack.com/pub/datagibberish/p/hiring-curious-data-engineers?utm_campaign=post-expanded-share&utm_medium=web) * Level-up Data Engineering (https://www.datagibberish.com/t/playlist-level-up-data-engineering) * Why the Hard Skills Obsession Is Misleading Every Aspiring Data Engineer (https://open.substack.com/pub/datagibberish/p/hard-data-engineering-skills-obsession-mistake?utm_campaign=post-expanded-share&utm_medium=web) This is a public episode. If you'd like to discuss this with other subscribers or get access to bonus episodes, visit www.datagibberish.com/subscribe (https://www.datagibberish.com/subscribe?utm_medium=podcast&utm_campaign=CTA_2)

7. 

   2 Apr 2026

   She Runs a $10k/Month Business Using Data and AI (and Her Title Says Marketing)

   I invited Yana G.Y. (https://substack.com/profile/136431837-yana-gy) to a live conversation because she does something rare. She has a director title and a Substack generating between $5K and $10K a month on the side of her full-time banking job. And she runs it entirely on data. Data-driven the way subscription businesses actually operate it. Numbers connected to decisions, decisions connected to outcomes. Below are the ideas she shared. The full conversation is in the video above. Stakeholders Make Emotional Decisions First (and They Have Good Reason To) The standard data professional complaint is that stakeholders ignore data and run on gut. Yana flips that framing. Her view: Most people are wired to make emotional decisions first and look for data that confirms them second. From her background in neurolinguistic programming, she puts the share of people who genuinely process the world through numbers at around 15%. Everyone else needs a different approach. Showing up with a dashboard and expecting it to land is wishful thinking. Data needs a story around it. A number without context gets interpreted differently by every person in the room. One sees growth, another sees underperformance, a third questions whether the metric tracks the right thing at all. Yana learned this early. Every conversation with engineering teams felt like friction. She was asking questions they thought she should already know. They were building things that missed what she actually needed. The gap cost both sides time. What closed it was her decision to learn enough about how systems work to ask better questions. To stop being helpless in technical conversations. The One Move That Ends Arguments in Any Meeting Yana has one technique she uses across every organization. It works in telecom. It works in banking. She has a perfect record with it. Before any contentious conversation, find the data that links your ask to what the organization actually cares about. Customers, revenue, profit. Those three. Then add competitive benchmarks if you can find them. In her current bank, she came in and asked how many successful app registrations they were getting. She pulled the internal rate, found competitor data, and discovered some competitors were achieving double or triple the registration conversion rate. She put that in front of the team. The conversation changed. People stop defending their position when the data shows the position is costing them. Go into the meeting with the numbers already pulled. Link them to something the people in the room care about. Then let the data do the work. This applies directly to data teams. When a project needs prioritization, funding, or unblocking, skip the technical justification. Show the business number it connects to, then show where a competitor is already ahead. Data Gibberish is a reader-supported publication. To receive new posts and support my work, consider becoming a free or paid subscriber. What Yana Actually Tracks on Substack Substack’s native analytics fall short. Yana built her own spreadsheet and tracks the following every month: * Total subscribers * New subscribers * Total paid subscribers * New paid subscribers * Churned paid subscribers * New revenue * Average revenue per subscriber per month * Average revenue per subscriber per year * Free-to-paid conversion rate * Net Promoter Score The benchmark Yana uses for revenue per subscriber is the email marketing industry average, ranging roughly from $1 to $12 per subscriber per year depending on niche. Above average means the business is healthy. Below average means something needs auditing. The NPS tracking is the piece most Substackers skip. She uses Substack’s survey feature to ask paid subscribers one question: on a scale from 1 to 10, how likely are you to recommend this publication to someone you know. That one question, run through the standard NPS formula, tells her whether her paid tier delivers real value. Her target is above 70. Yana’s reasoning: NPS is the only reliable signal for whether paid subscribers are satisfied or are simply on their way out. How She Runs a $10K/Month Business in the Hours Left Over From a Full-Time Job Yana works five days a week, eight hours a day, in an office. She can answer Substack comments during lunch or late after work. That’s the window she operates in. AI handles everything operational. Formatting, research, scheduling, the mechanical parts. For writing, she trained a system on her own content. She extracted all her published articles into a database, connected it to an MCP server, and built what she calls a second brain. She can query it for content gaps, understand what paid subscribers want more of, and run analysis on her own business data. She writes in her voice, informed by her own data, with AI executing the work that requires no judgment. Her warning about AI: It pulls you into rabbit holes when you let it. Every answer suggests the next step, and the next step, and an hour later you have built something with no clear business purpose. Use it to execute a decision. Know exactly what you want before you open it. Yana also made the point that the 9-to-5 built the Substack. The telecom career gave her subscription business knowledge, customer journey expertise, conversion rate benchmarks, and an understanding of which metrics actually predict business health. All of it went directly into how she runs the newsletter. The side business grew because of the day job. Final Thoughts Yana has 15 years of subscription business experience, a disciplined tracking system, and a clear rule: link your ask to numbers that matter, then find the benchmark that shows where you stand. That’s the part worth sitting with. Data professionals spend time arguing that stakeholders ignore data. Yana learned enough about systems to have real conversations with engineers. She built her own analytics because the platform’s fell short. She tracks NPS because her industry background taught her it mattered. The gap between business and data closes when people on both sides decide to move. Yana moved. The engineers still telling business people to figure it out on their own are the ones falling behind. Interested into growing your Substack? Subscribe to Yana’s publication (https://www.yana-g-y.com/). This newsletter is funded by paid subscriptions from readers like yourself. If you aren’t already, consider becoming a paid subscriber to receive the full experience! See what people say about working with me. (https://www.datagibberish.com/p/become-a-member) You are more than welcome to find whatever interests you here and try it out in your particular case. Let me know how it went! This is a public episode. If you'd like to discuss this with other subscribers or get access to bonus episodes, visit www.datagibberish.com/subscribe (https://www.datagibberish.com/subscribe?utm_medium=podcast&utm_campaign=CTA_2)

8. 

   19 Mar 2026

   How to Think Holistically About the Data Ecosystem with Dylan Anderson

   Most data professionals are really good at one thing. They know their domain, they know their tools, and they go deep. That depth is how you get hired. It is also how you get stuck. The further you go in your career, the more you run into problems that don’t live inside a single domain. A pipeline that nobody uses because the data model underneath it was wrong. A dashboard that answers the wrong question because nobody talked to the business before building it. A data strategy that looks good on paper and falls apart when it hits the actual architecture. I sat down with Dylan Anderson (https://substack.com/profile/14172622-dylan-anderson) , data strategist, consultant, and author of The Data Ecosystem (https://open.substack.com/pub/thedataecosystem) newsletter, to talk about what it actually means to think across the system. Dylan came from business consulting before moving into data, which means he sees this from both sides. The conversation covered how companies actually operate, what separates the people who get ahead from the ones who stay stuck, and one habit that changes how you work without requiring you to become an expert in everything. Here is what I took away. The Data Ecosystem Is Not Your Tech Stack What most people call the data ecosystem is really a landscape, a snapshot of tools at a point in time. It changes occasionally, but it’s static. The ecosystem is something different. Think of a pond. Everything inside it is connected: the soil, the water, the microorganisms, the plants, the animals. Remove one element and the whole system shifts. Data works the same way. Your data model affects your engineering. Your engineering affects your analytics. Your governance affects your ML. Your business model shapes all of it. These aren’t separate domains you visit when a ticket arrives, but a system, and if you only know your corner of it, you’re operating blind. The problem is that most people work reactively. They handle what’s in front of them. They talk to the governance team when there’s a compliance issue, not because they thought about how governance connects to what they’re building. They don’t think about the relationships between domains. They just navigate them when forced to. Dylan’s point is that the people who think proactively about those connections, who anticipate how one decision ripples into another domain, are the ones who produce better work and get trusted with bigger problems. That’s a systems skill. And most data training never touches it. Paid members consistently share they got promoted or praised because they apply my guides. Most Companies Are Still a Mess Dylan has worked with a lot of billion-dollar organisations. His read: mostly chaos. Data strategy documents exist. They talk about vision and use cases. They don’t connect to the architecture underneath, the governance layer, or the engineering reality on the ground. Nobody in the building knows how all the pieces fit together, not even the CDO, who spends most of their time managing upward. The result is piecemeal data. Companies ahead in one domain are five steps behind in another. They buy great BI tools on top of poor data models and wonder why the dashboards don’t deliver. They bolt AI onto existing business processes and get some ROI but miss the structural shift entirely. What’s almost always missing is the link between business strategy and how data actually enables the organisation. And the people who see that link, who say “we need to think about this before we build that,” are the ones who get trusted, get promoted, and get asked into the room where decisions happen. Dylan’s observation from client work: the best performers in every organisation he’s walked into are the ones thinking across domains. LinkedIn will have you believe most companies are running cutting-edge data stacks. The reality for 95% of them is legacy chaos, and that gap is an opportunity for anyone willing to think holistically about it. Data People Need Business Literacy We obsess over data literacy. Get the business stakeholders to understand data, read the dashboards, ask better questions. Dylan flips it. Data people need business literacy just as much, and most of them don’t have it. They don’t know how the business model works, what the real KPIs are, why the marketing team cares about a number that looks meaningless from an engineering seat. They build things nobody uses because they never asked what outcome was actually needed. The gap is generational too. Five or ten years ago, most people who moved into data migrated from somewhere else, finance, operations, product. They understood business from the inside. Now whole cohorts start their careers as data people. They’ve never sat on the other side of the table. Dylan’s framing is direct: if you want to influence the business, you have to speak its language. That starts with understanding the business model, the KPIs, what each stakeholder is actually measured on. Once you have that, you stop presenting data and start presenting decisions. Stakeholders notice. They start saying you’re different from the engineers who only think about the technical problem. That’s when trust builds and trust is what gets you the work that matters. The “So What” Frame Dylan had a consulting partner early in his career who rejected every slide that didn’t answer one question: so what? Not “is this technically correct“, or “did you finish it“ So what. What changes because of this? What’s the action out of it? Dylan hated it at the time. It’s second nature to him now. It’s the fastest way to pull yourself out of ticket mode and into strategic thinking. You don’t need to study the whole data ecosystem to start thinking more holistically. You need one habit applied every time you deliver something: * Does this matter? * To whom? * What do they do next? If you can’t answer that, you’re producing output. The business is paying for impact. That question also protects you from the trap Dylan sees in most data teams, the reactive, firefighting, ticket-based mode that makes it almost impossible to step back. When every day is about closing tickets, you never ask whether the tickets matter. The “so what“ frame forces that pause. Fifteen minutes of strategic thinking before you build something is worth more than three days of building the wrong thing fast. What AI Changes and What It Doesn’t AI is taking over individual technical tasks faster than most people are comfortable admitting. Routine work, boilerplate code and first-draft outputs are largely handled. What’s left is context. AI doesn’t know your organisation. It doesn’t know why a specific stakeholder cares about a specific number, or whether a proposed solution fits your actual business model, or what you’ve already tried and why it failed. That’s your job. Domain expertise plus the ability to connect domains, to say “this decision over here affects that system over there“, is what makes AI output useful rather than generic. The people who will matter in the next five years are the ones who can think across the system. AI handles the execution. You handle the judgement. Dylan is also working on the next layer of the problem. How business models fundamentally change in an AI-first world. Most companies are bolting AI onto existing processes and getting some ROI. The shift is rethinking how the organisation operates at the root. It has implications for data modelling, governance, architecture, strategy. Nobody has solved that yet. It’s the open problem, and it’s where the real opportunity sits for anyone thinking holistically right now. Where to Find Dylan Dylan writes the Data Ecosystem newsletter (https://thedataecosystem.substack.com/) on Substack. Weekly deep dives on every domain in the data space and how they connect. If you want to build the holistic view we talked about, start there. He also posts daily on LinkedIn (https://www.linkedin.com/in/dylansjanderson/). If you want to connect, include a note. He reads them and responds. And this summer he’s releasing a LinkedIn Learning course on insights-led thinking in the age of AI. Worth watching for. Final Thoughts The data industry has spent years rewarding depth. Know your tool, know your domain, go deep. That got a lot of people to senior. It stops working somewhere around there. The problems that matter at the senior level and beyond don’t live inside a single domain. They live in the connections between domains. Between the data model and the engineering. Between the engineering and the business outcome. Between what the team is building and what the organisation actually needs. The people who see those connections are the ones who get trusted with the hard problems. Business literacy, holistic thinking, asking “so what“ before you ship anything. None of this is complicated. It’s just not what most data training covers, so most people never build it deliberately. You can wait until your career stalls to figure that out. Or you can start now, while the gap between you and everyone else who only knows their lane is still wide enough to matter. Until next time, Yordan PS: Many paid members tell me they got promoted after working through the resources inside. If that sounds relevant to where you are right now, here’s what you get with a paid membership (https://www.datagibberish.com/p/premium-content-library). This is a public episode. If you'd like to discuss this with other subscribers or get access to bonus episodes, visit www.datagibberish.com/subscribe (https://www.datagibberish.com/subscribe?utm_medium=podcast&utm_campaign=CTA_2)

9. 

   10 Mar 2026

   How to Think like a Senior Engnieer with Erfan Hesami

   Seniority is a quiet death of the ego that thinks a perfect pull request solves the business problem. In this conversation, Erfan Hesami and I dismantle the myth that technical depth is the only path to the top. You spend years mastering Python and SQL only to reach a level where pipelines fail because requirements were wrong or stakeholders changed their minds. This is the ceiling where most data careers stall. Erfan, drawing from his experience in fintech and manufacturing, confirms that the jump to senior is not about a tenth tool. It is about shifting focus from the immediate task to the broader system. You must stop being a ticket-taker and start being an operator who designs for long-term reliability. Erfan highlights that the senior mindset requires moving beyond the IDE to master the non-code half of the job. This involves making hard calls on “good enough“ solutions and building trust through translation. We discuss how to bridge the gap between technical skill and leadership so your career does not stall. This session covers the specific mindset shifts and operational boundaries Erfan uses to cross the senior threshold. The Senior Operator Writes Less Code Erfan notes that mid-level engineers often measure value by the complexity of the systems they build. You want the newest framework because it feels like progress. Senior engineers realize every line of code is a liability. You provide more value by preventing a project than by building it poorly. When you operate at senior level, your primary job is making technical decisions aligned with business problems. You prioritize projects based on impact rather than technical interest. If a simple SQL view solves the problem, you do not build a custom microservice. The consequence of over-engineering is a maintenance debt that eventually prevents you from shipping anything new. Reframe your role from a builder to a decision-maker. You are there to ensure data flows reliably, not just to move bytes. Erfan suggests that a good week is not one where you closed the most tickets, but where you simplified an architecture or spent time upskilling to prevent future technical debt. Data Gibberish is a reader-supported publication. To receive new posts and support my work, consider becoming a free or paid subscriber. Ownership Is Moving Without Permission Waiting for a manager to tell you what to do is a junior behavior. Erfan observes that many competent engineers stay mid-level because they wait for a formal promotion before acting like a leader. They expect the title to grant them the right to speak up. In reality, the title follows the behavior. You must take ownership of the end-to-end lifecycle before anyone asks. Erfan emphasizes raising your hand when you see a flaw in database design or a better way to handle upstream sources. If you wait for permission, you are a resource. If you propose solutions and arrange meetings with stakeholders, you are a leader. The tradeoff is that ownership comes with accountability. When a project fails, you cannot blame the requirements. Erfan argues that unclear requirements are an engineering problem. You bridge this gap by networking across departments like CRM or accounting to understand pain points before you ever open your IDE. Zoom Out to See the System Juniors focus on the feature in front of them to move a ticket from left to right. This narrow focus leads to local optimizations that break the global system. Erfan warns against building a fast pipeline that produces garbage data because you did not check the upstream quality. As a senior, you must zoom out to see the broader system. Erfan explains that you must ask why a feature was requested and how it affects downstream consumers. You focus on the foundation that makes the platform scalable and easier for others to use over time. This shift in perspective allows you to catch errors in assumptions before they become code. This systemic thinking is your true differentiator. Erfan points out that AI can write boilerplate code, but it cannot navigate the politics of conflicting requirements. Your value lies in your ability to communicate and think through these nuances. The Resources Here are the links to all the resources we mentioned: * Pipeline To Insights (https://pipeline2insights.substack.com/?utm_campaign=pub&utm_medium=web): Erfan’s Substack newsletter where he shares his learning experiences and data engineering insights. * Erfan’s on LinkedIn (https://www.linkedin.com/in/erfanhesami/): Here you can connect with Erfan and read his new * The GitHub Portfolio Article (https://open.substack.com/pub/pipeline2insights/p/how-to-create-data-engineering-data-engineers-github-portfolio-in-2026?utm_campaign=post-expanded-share&utm_medium=web): A specific article mentioned that was written for Pipeline 2 Insights regarding how to build a GitHub portfolio. * Article on Certifications (https://open.substack.com/pub/datagibberish/p/the-certifications-scam?utm_campaign=post-expanded-share&utm_medium=web): A “very nice” article written by Jordan discussing the role and value of certifications in a data career. Final Thoughts The shift Erfan describes is a move from the certain world of syntax to the ambiguous world of people and systems. You must be willing to ask the questions that feel stupid but reveal deep flaws in a plan. You must be comfortable sharing opinions even when they are not explicitly requested. True seniority is not a reward for time served. It is a status earned by those who take responsibility for outcomes, not just outputs. Erfan’s approach shows that you stop being a person who writes code and start being a person who solves business problems using data. The code is just a tool, and often it is the most expensive one you have. Focus on building trust through consistency and ownership. Become the expert who can navigate different areas and adapt to new challenges. When you master the non-code half of the job, your career will stop stalling. Until next time, Yordan Data Gibberish is a reader-supported publication. To receive new posts and support my work, consider becoming a free or paid subscriber. This is a public episode. If you'd like to discuss this with other subscribers or get access to bonus episodes, visit www.datagibberish.com/subscribe (https://www.datagibberish.com/subscribe?utm_medium=podcast&utm_campaign=CTA_2)

10. 

    5 Mar 2026

    Intro to MetadataOps with Alejandro Aboy

    Alejandro Aboy (https://substack.com/profile/22949723-alejandro-aboy) and I sat down to talk about the mess of modern AI. He told me he feels like an octopus lately. He spent years mastering dbt and Airflow. Now his day involves managing agent protocols and context windows. The problem is that AI agents are the most demanding stakeholders you have ever had. They have zero intuition. They do not understand your tribal knowledge or your hidden business logic. If you give them a table without a deep layer of metadata, they will guess. When they guess, they hallucinate. When they hallucinate on your watch, you lose your seat at the table. This conversation with Ale highlighted that the job has changed. You are no longer just shipping rows, but shipping the instructions that keep the machines from lying. The Death Of The Static Catalog Traditional data catalogs are where documentation goes to die. You spend a month tagging columns and then nobody looks at them. Ale calls the new approach MetadataOps. In this model, your agents provide data back to the system. They help you understand how they use the information. If an agent struggles to identify a primary key, that is a production bug. Documentation is now the fuel for your production AI. If you treat metadata as an afterthought, your AI solutions will stay in the playground. Real operators build systems that document themselves through use. Data Gibberish is a reader-supported publication. To receive new posts and support my work, consider becoming a free or paid subscriber. Managing The Unstructured Mess Unstructured, human generated data like images, audio or markdown documentation is a real mess. You must build guardrails that expect the mess. This means using regular expressions and specific skills to pull structure out of chaos. You are acting as a bridge between human habits and machine requirements. This requires deciding when a data source is “good enough” to ship. You have to weigh the risk of a hallucination against the speed of the business. These are leadership calls, not technical ones. The AI Stakeholder Shift Your stakeholders think everything is possible now because they saw a demo on Twitter. This creates a massive gap in expectations. People expect you to ship features ten times faster. They do not see the infrastructure required to make those features reliable. You must translate the technical risk of AI into business terms. If you fail to manage the context, you fail to manage the trust. You are a translator now. You explain why a simple prompt is not a production strategy. You show them that the quality of the output depends on the quality of the metadata you have been screaming about for years. Links We mentioned a few resources. Here are the links: * Alejandro’s publication (https://thepipeandtheline.substack.com/): Make sure you subscribe. * Substack Recapped (https://substackrecapped.com/): A must try if you write on Substack. Final Thoughts The gap between a senior individual contributor and a data leader is the ability to manage ambiguity. Ale’s shift from dbt to agent protocols is a map for your own career. The code is becoming a commodity. The ability to structure the world for a machine is the new high-value skill. You cannot hide in the IDE and hope the data stays clean. You have to lean into the mess of unstructured files and vague stakeholder requests. Metadata is the only tool that bridges that gap. You need to start thinking about it as managing the context of your entire company. If you do not own the metadata, you do not own the outcome. Seniority is about taking ownership of the results, not just the scripts. Use your metadata to build a system that thinks. Until next time, Yordan from Data Gibberish PS: We live stream these conversations. Join and chat with us next time. Data Gibberish is a reader-supported publication. To receive new posts and support my work, consider becoming a free or paid subscriber. This is a public episode. If you'd like to discuss this with other subscribers or get access to bonus episodes, visit www.datagibberish.com/subscribe (https://www.datagibberish.com/subscribe?utm_medium=podcast&utm_campaign=CTA_2)

11. 

    20 Jan 2026

    This Engineer Teaches Their Audience How To Think The Right Way

    The session centers on a fundamental problem: You and I are trained as engineers to use design patterns for code, but we’re often left winging it when it comes to people and organizational complexity. Michał Poczwardowski (https://substack.com/profile/141222242-micha-poczwardowski) argues that we need to treat our thinking process with the same level of structural integrity we give our architecture. Mental Models are Just Design Patterns for Your Brain Michal defines mental models as “design patterns for solving problems“ rather than just writing code. They are thinking protocols pulled from disciplines like physics and chemistry that help you ask the right questions before you commit to a path. The goal is to have a meta-observation of your own brain so you don’t default to lazy or reactive thinking. The Logic of “First Principles” and “Inversion” * First Principles: Instead of following “best practices“ blindly, you break a problem down to its fundamental truths. If the math doesn’t work at the foundation, the whole project is a house of cards. * Inversion: Instead of asking “How do I make this project succeed?“, you ask “What are all the ways we could make our people miserable and the project fail?“. Then, you systematically avoid those things. It’s much easier to avoid stupidity than to seek brilliance. The “Process vs. Outcome” Fallacy This is where most engineers get tripped up. Michal pointed out that a good decision can lead to a bad outcome because of luck or unexpected variables. Conversely, you can make a “stupid“ decision, like betting the company’s runway on a random crypto coin, and get lucky. You cannot judge the quality of your decision-making based solely on the result. You have to judge it based on the structure of the process you used at the time. If the process was solid but the result was bad, you didn’t fail; you just hit an outlier. Practical Protocol: Don’t Estimate on the Fly One of the best “thinking protocols“ mentioned was the rule of never providing estimates during a live call. The pressure to look smart or accommodate a client usually leads to “one-week“ promises for “two-month“ problems. A structured thinker pauses, analyzes, and responds in a separate thread. Data Gibberish is a reader-supported publication. To receive new posts and support my work, consider becoming a free or paid subscriber. Thanks for reading, Yordan PS: Want to learn more about structured decision making and mental models? Subscribe to Perspectiveship (https://open.substack.com/pub/poczwardowski) today. Let’s connect LinkedIn (https://www.linkedin.com/in/ivanovyordan/) | Threads (https://www.threads.com/@heyivanovyordan) | Facebook (https://www.facebook.com/heyivanovyordan) | X (https://x.com/heyivanovyordan) | Bluesky (https://bsky.app/profile/ivanovyordan.com) This is a public episode. If you'd like to discuss this with other subscribers or get access to bonus episodes, visit www.datagibberish.com/subscribe (https://www.datagibberish.com/subscribe?utm_medium=podcast&utm_campaign=CTA_2)